From jpv@cisco.com Wed Feb 2 00:42:52 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EB043A6B9F for ; Wed, 2 Feb 2011 00:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.45 X-Spam-Level: X-Spam-Status: No, score=-110.45 tagged_above=-999 required=5 tests=[AWL=0.148, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnbA+8OcUkvm for ; Wed, 2 Feb 2011 00:42:51 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 850423A6B75 for ; Wed, 2 Feb 2011 00:42:51 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMEACKpSE2Q/khNgWdsb2JhbAClGBUBARYiJKE9mxeFUwSLX4Mv Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 02 Feb 2011 08:46:10 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p128kAqE020966 for ; Wed, 2 Feb 2011 08:46:10 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 09:46:10 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 09:46:06 +0100 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-137-501586074 Date: Wed, 2 Feb 2011 09:46:05 +0100 Message-Id: <90B88918-D3B5-4A2F-88EF-95F26E1B5FB8@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 02 Feb 2011 08:46:06.0462 (UTC) FILETIME=[A18099E0:01CBC2B5] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17930.003 X-TM-AS-Result: No--6.828400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] draft-tripathi-roll-rpl-simulation-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 08:42:52 -0000 --Apple-Mail-137-501586074 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, Since draft-tripathi-roll-rpl-simulation-06 has been discussed for quite = some time and is now fully stable, the authors intend to request the = independent publication of the document. Do not hesitate to chime in if = you are opposed to it. Thanks. JP.= --Apple-Mail-137-501586074 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear all,

Since draft-tripathi-roll-rpl-simulation-06 has been discussed = for quite some time and is now fully stable, the authors intend to request = the independent publication of the document. Do not hesitate to chime in if you are = opposed to it.

Thanks.

JP.
= --Apple-Mail-137-501586074-- From jpv@cisco.com Wed Feb 2 01:01:21 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF6203A7125 for ; Wed, 2 Feb 2011 01:01:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.453 X-Spam-Level: X-Spam-Status: No, score=-110.453 tagged_above=-999 required=5 tests=[AWL=0.145, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSzJ52qn+734 for ; Wed, 2 Feb 2011 01:01:20 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id E72F53A6965 for ; Wed, 2 Feb 2011 01:01:13 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AigEAJOsSE2Q/khLgWdsb2JhbACCRaJTFQEBFiIkoUSbG4VTBItfgy8 Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 02 Feb 2011 09:04:32 +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 p1294Wjv010756 for ; Wed, 2 Feb 2011 09:04:32 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 10:04:32 +0100 Received: from ams-jvasseur-8711.cisco.com ([10.55.201.130]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 2 Feb 2011 10:04:29 +0100 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-146-502690002 Date: Wed, 2 Feb 2011 10:04:29 +0100 Message-Id: <7DF6740A-1630-4229-96DC-F7FF4E7B64AE@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 02 Feb 2011 09:04:29.0878 (UTC) FILETIME=[33308560:01CBC2B8] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17930.003 X-TM-AS-Result: No--38.058100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Important Dates for IETF-80 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 09:01:21 -0000 --Apple-Mail-146-502690002 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii IETF 80: March 27-April 1, 2011, Prague, Czech Republic Download important dates for IETF 80 to your calendar: .ICS 2010-12-27 (Week of): IETF Online Registration opens. 2010-12-27 (Monday): Working Group and BOF scheduling begins. To request = a Working Group session, use the IETF Meeting Session Request Tool. 2011- 01-31 (Monday): Cutoff date for BOF proposal requests to Area = Directors at 17:00 PT (01:00 Tuesday, February 1 UTC). To request a BOF, = please see instructions on Requesting a BOF. 2011-02-14 (Monday): Cutoff date for requests to schedule Working Group = meetings at 17:00 PT (01:00 Tuesday, February 15 UTC). To request a = Working Group session, use the IETF Meeting Session Request Tool. 2011-02-14 (Monday): Cutoff date for Area Directors to approve BOFs at = 17:00 PT (01:00 Tuesday, February 15 UTC). 2011-02-24 (Thursday): Preliminary agenda published for comment. 2011-02-28 (Monday): Cutoff date for requests to reschedule Working = Group and BOF meetings 17:00 PT (01:00 Tuesday, March 1 UTC). 2011-02-28 (Monday): Working Group Chair approval for initial document = (Version -00) submissions appreciated by 17:00 PT (01:00 Tuesday, March = 1 UTC). 2011-03-04 (Friday): Final agenda to be published. 2011-03-07 (Monday): Internet Draft Cut-off for initial document (-00) = submission by 17:00 PT (01:00 Tuesday, March 8 UTC), upload using IETF = ID Submission Tool. 2011-03-14 (Monday): Internet Draft final submission cut-off by 17:00 PT = (01:00 Tuesday, March 15 UTC), upload using IETF ID Submission Tool. 2011-03-16 (Wednesday): Draft Working Group agendas due by 17:00 PT = (01:00 Thursday, March 17 UTC), upload using IETF Meeting Materials = Management Tool. 2011-03-18 (Friday): Early Bird registration and payment cut-off at = 17:00 PT (01:00 Saturday, March 19 UTC). 2011-03-21 (Monday): Revised Working Group agendas due by 17:00 PT = (01:00 Tuesday, March 22 UTC), upload using IETF Meeting Materials = Management Tool. 2011-03-21 (Monday): Registration cancellation cut-off at 17:00 PT = (01:00 Tuesday, March 22 UTC). 2011-03-25 (Friday): Final Pre-Registration and Pre-Payment cut-off at = 17:00 local meeting time. 2011-03-27 - 2011-04-01: 80th IETF Meeting in Prague, Czech Republic. 2011-04-29 (Friday): Proceedings submission cutoff date by 17:00 PT = (01:00 Saturday, April 30 UTC), upload using IETF Meeting Materials = Management Tool. 2011-05-18 (Wednesday): Proceedings submission corrections cutoff date = by 17:00 PT (01:00 Thursday, May 19 UTC), upload using IETF Meeting = Materials Management Tool. --Apple-Mail-146-502690002 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

IETF 80: March 27-April 1, = 2011, Prague, Czech Republic

Downlo= ad important dates for IETF 80 to your = calendar: .ICS


= --Apple-Mail-146-502690002-- From prvs=0070b9695=mukul@uwm.edu Wed Feb 2 03:14:34 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CED13A6C69 for ; Wed, 2 Feb 2011 03:14:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.438 X-Spam-Level: X-Spam-Status: No, score=-3.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LswEFB5-VYEY for ; Wed, 2 Feb 2011 03:14:33 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 7A5CD3A6BB3 for ; Wed, 2 Feb 2011 03:14:33 -0800 (PST) Received: from mta03.pantherlink.uwm.edu ([129.89.7.134]) by ip1mta.uwm.edu with ESMTP; 02 Feb 2011 05:17:52 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id AE5291FD030; Wed, 2 Feb 2011 05:17:52 -0600 (CST) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8s2AaqZB2fn; Wed, 2 Feb 2011 05:17:52 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 696071FD02F; Wed, 2 Feb 2011 05:17:52 -0600 (CST) Date: Wed, 2 Feb 2011 05:17:52 -0600 (CST) From: Mukul Goyal To: roll Message-ID: <775174602.2214695.1296645472351.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <1585852420.2214596.1296643088260.JavaMail.root@mail02.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 Cc: Adrian.Farrel@huawei.com Subject: [Roll] Is a routing constraint mutable? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Feb 2011 11:14:34 -0000 Hi JP So far I had the impression that the routing constraints are not mutable. A Routing constraint specifies a constraint on the corresponding routing metric value. This means that whenever a routing constraint object is included, the corresponding routing metric object must also be included. Adrian pointed this out in his AD review of the metrics draft. I quote below the relevant text: ">> Section 3.3 >> >> It looks to me that if the object is used as a constraint, it MUST >> also be present as a metric. This seems to be different from the >>burble at the top of the section. > > JP> Not sure why ... you could use it as a constraint (say to avoid > too much of delays if you know that the number of traversed hop > may be an issue) and still want to optimize against another metric > such as the bandwidth ? Well, the text says... The HP object may be used as a constraint or a metric. When used as a constraint, the DAG root indicates the maximum number of hops that a path may traverse. When that number is reached, no other node can join that path. But, if the object states how many hops are allowed (i.e. is a constraint) then how will you know how many hops have actually been traversed? For that you need the metric. Actually, this would apply to the use of all metric-based constraints. E.g., if you set a constraint that the path cost must not be greater than x, you can include this in a constraint variant of the object, but you also need to record the metric as you go. See my comment on Section 4.2... " In response, version 14 of the metrics draft included the following text in the beginning of Section 3: "In the presence of a constraint and a metric (which may or may not be of the same type), a node MUST update the constraint before advertising the updated metric and constraints. For example, if the constraint is the number of hops (e.g. the maximum number of hops is n) and the path is optimized against the delay: if a node selects a parent advertising a maximum number of hops of n (constraint), it must advertises DIO messages containing a hop count metrics constraint with a field value equal of (n-1) and the newly computed path metric. This applies to the following constraints defined below: hop-count, latency and path ETX." This text vaguely implies that a routing constraint is mutable or that a routing constraint involving hop-count/latency/ETX is mutable. First, the text quoted above conflicts with the following text from Hop-count section (3.3): "The HP object may be used as a constraint or a metric. When used as a constraint, the DAG root indicates the maximum number of hops that a path may traverse. When that number is reached, no other node can join that path. " The text above implies that DAG root sets the hop-count constraint value and no one should touch it. In my view, the routing constraints should be immutable. When required, the constraint should be accompanied by a corresponding metric object. Breaking the semantic purity of the constraint (some constraint mutable; some not) is inelegant. This also raises questions about the meaning of the O flag inside a routing constraint. Consider a hop-count constraint with O flag set. If the meaning associated with the hop-count constraint is that it indicates the remaining number of hops that the DIO can further travel, the hop-count constraint must be updated at each hop and hence can not have O flag set. For P2P extension, the implication is that the mutable constraints (that necessarily need to be processed at each hop) can not be considered as route constraints (only the target is required to enforce route constraints). Please consider modifying the metrics draft to clearly specify that routing constraints are not mutable and, when required, a routing constraint object must be accompanied by a corresponding routing metric object. Thanks Mukul From Internet-Drafts@ietf.org Fri Feb 4 03:45:03 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D83C3A6BA8; Fri, 4 Feb 2011 03:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UUZF2jVdvd+6; Fri, 4 Feb 2011 03:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C6FE3A68F6; Fri, 4 Feb 2011 03:45:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110204114502.26652.71352.idtracker@localhost> Date: Fri, 04 Feb 2011 03:45:02 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-rpl-18.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 11:45:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks Author(s) : T. Winter, et al. Filename : draft-ietf-roll-rpl-18.txt Pages : 159 Date : 2011-02-04 Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen and up to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point, as well as point-to- multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-18.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-rpl-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-04033055.I-D@ietf.org> --NextPart-- From pthubert@cisco.com Fri Feb 4 07:21:20 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB41A3A69B6 for ; Fri, 4 Feb 2011 07:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.394 X-Spam-Level: X-Spam-Status: No, score=-10.394 tagged_above=-999 required=5 tests=[AWL=0.204, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hbCHFkznMwAj for ; Fri, 4 Feb 2011 07:21:15 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id AE7E23A69A4 for ; Fri, 4 Feb 2011 07:21:14 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4DAK6oS02Q/khNgWdsb2JhbACCRJQLhkIBiBsVAQEWIiSeMpsFhVoEjxqIMw Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 04 Feb 2011 15:24:39 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p14FOd6G007868; Fri, 4 Feb 2011 15:24:39 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 16:24:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC47F.A31B86DF" Date: Fri, 4 Feb 2011 16:24:33 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03C1F973@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Local repair Thread-Index: Acu/EmkjtMFcZbwwS6asI20M/v1/FgFa2okQ References: <13A9A72D-36B2-453C-B5B4-D93F69C14BAE@cs.stanford.edu><37DC74FB-1E2A-41C7-AD1B-07B8D4294E55@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Ulrich Herberg" , "Philip Levis" X-OriginalArrivalTime: 04 Feb 2011 15:24:39.0314 (UTC) FILETIME=[A37FBF20:01CBC47F] Cc: roll WG Subject: Re: [Roll] Local repair X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 15:21:20 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC47F.A31B86DF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Ulrich: =20 This is probably too late to change that text. I think it will be useful to write informational docs describing some proposed behaviors, and produce best practices. =20 With RPL, though, and as Phil explained, you have liberty to take risks to recover faster, since the risk is later alleviated by the datapath detection.=20 =20 Poisoning and waiting as you proposed is a good recommendation in classical networks and that's how (E)IGRP operate. So your suggestion was certainly not irrelevant. =20 Cheers, =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Ulrich Herberg Sent: Friday, January 28, 2011 6:40 PM To: Philip Levis Cc: roll WG Subject: Re: [Roll] Local repair =20 Phil, On Fri, Jan 28, 2011 at 6:21 PM, Philip Levis wrote: =20 Could you please send me a reference? =20 http://sing.stanford.edu/gnawali/ctp/ and the paper: http://sing.stanford.edu/gnawali/ctp/sensys09-ctp.pdf Thanks. =20 =20 Yes, I assumed that. I had spoken with a colleague who is working with the ContikiRPL implementation. They are throwing away the information about all parents, if a loop between a router and one of its parents is detected. That's why I asked, but I assume it would be better to just throw away the one parent where the loop has been detected. =20 This is a terrible idea -- you should instead just mark the parent's new Rank/Metrics etc. Whether or not the parent is evicted from the neighbor table should be independent of whether its change is due to a possible loop. E.g., it could be that the parent is currently looping through this node, but after loops are repaired this node will need to route through that neighbor (which chooses a different route). I agree with you. What I wonder is whether this shouldn't be a bit explained in the RPL spec (e.g. in sections like "Local Repair Mechanism" / "Poisoning a sub-DODAG", that explain what an implementation should do, and what it should not do) . The fact that implementations do the local repair wrongly, may indicate that it is not always clear for implementers.=20 Ulrich=20 ------_=_NextPart_001_01CBC47F.A31B86DF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Ulrich:

 

This is probably too late to change that text. I think it will be = useful to write informational docs describing some proposed behaviors, = and produce best practices.

 

With RPL, though, and as Phil explained, you have liberty to take = risks to recover faster, since the risk is later alleviated by the = datapath detection.

 

Poisoning and waiting as you proposed is a good recommendation in = classical networks and that’s how (E)IGRP operate. So your = suggestion was certainly not irrelevant.

 

Cheers,

 

Pascal

http://www.xtranormal.c= om/watch/7011357/

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Ulrich Herberg
Sent: Friday, January 28, 2011 6:40 = PM
To: Philip Levis
Cc: roll WG
Subject: = Re: [Roll] Local repair

 

Phil,

On Fri, Jan 28, 2011 at 6:21 PM, Philip Levis <pal@cs.stanford.edu> = wrote:

 

Could you please send me a = reference?

 

http://sing.stanford.edu/gnawali/ctp/

and = the paper:

http://sing.stanford.edu/gnawali/ctp/sensys09-ctp.pdf

 

Yes, I = assumed that. I had spoken with a colleague who is working with the = ContikiRPL implementation. They are throwing away the information about = all parents, if a loop between a router and one of its parents is = detected. That's why I asked, but I assume it would be better to just = throw away the one parent where the loop has been = detected.

 

This = is a terrible idea -- you should instead just mark the parent's new = Rank/Metrics etc. Whether or not the parent is evicted from the neighbor = table should be independent of whether its change is due to a possible = loop. E.g., it could be that the parent is currently looping through = this node, but after loops are repaired this node will need to route = through that neighbor (which chooses a different = route).



I = agree with you. What I wonder is whether this shouldn't be a bit = explained in the RPL spec (e.g. in sections like "Local Repair = Mechanism" / "Poisoning a sub-DODAG", that explain what = an implementation should do, and what it should not do) . The fact that = implementations do the local repair wrongly, may indicate that it is not = always clear for implementers.

Ulrich =

------_=_NextPart_001_01CBC47F.A31B86DF-- From pthubert@cisco.com Fri Feb 4 08:08:49 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74F553A697E for ; Fri, 4 Feb 2011 08:08:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.398 X-Spam-Level: X-Spam-Status: No, score=-10.398 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-0ReM3222ju for ; Fri, 4 Feb 2011 08:08:44 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 36E053A67F7 for ; Fri, 4 Feb 2011 08:08:44 -0800 (PST) Authentication-Results: ams-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AroDAF20S02Q/khNgWdsb2JhbACCRJQLjl4VAQEWIiSeXJsShVoEjxo Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 04 Feb 2011 16:12:08 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p14GC8uw018367; Fri, 4 Feb 2011 16:12:08 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Feb 2011 17:12:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBC486.4575A971" Date: Fri, 4 Feb 2011 17:07:30 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03C1F99A@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Question about RPL and multicast Thread-Index: AcvEhZ6Kn1uJLk0XRAGrWlc9OQk+Gw== From: "Pascal Thubert (pthubert)" To: "KELLIL Mounir" , "roll WG" X-OriginalArrivalTime: 04 Feb 2011 16:12:08.0853 (UTC) FILETIME=[45F4E450:01CBC486] Subject: Re: [Roll] Question about RPL and multicast X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 16:08:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBC486.4575A971 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mounir, =20 RPL supports a multicast service for storing mode only. So there is no tunnel. And the multicasted packets are copied at L3, not L2. =20 A node that wishes to listen to a group will send a DAO to (at least and usually) one selected parent. Recursively, the DAO reaches the root, and a RPF path is created for that listener. As a result a router has DAO entries for all children that are ancestors listening to a mcast group. It copies the mcast packet to all its children, as opposed to unicast where it copies to only one child. And it copies to the selected parent as well. It should refrain from copying to the node that passed the packet, which should be a waste. =20 Do you have a specific issue with this?) =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of KELLIL Mounir Sent: Thursday, January 27, 2011 5:30 PM To: roll WG Subject: [Roll] Question about RPL and multicast =20 Dear all, =20 In the last version of RPL draft, it is mentioned that an RPL node (a router) forwards multicast data to the preferred parents and to the children that have subscribed to the multicast group. Yet, it is not clear whether this packet forwarding is achieved through IP tunnelling (multicast-in-unicast) or using L2 (unicast) relaying? (I'd say the second is right, but I'm not sure). And, the same question arises for the case of the multicast source within the DODAG.. =20 Best regards =20 Mounir ------_=_NextPart_001_01CBC486.4575A971 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mounir,

 

RPL supports a multicast service for storing mode only. So there is = no tunnel. And the multicasted packets are copied at L3, not = L2.

 

A node that wishes to listen to a group will send a DAO to (at least = and usually) one selected parent. Recursively, the DAO reaches the root, = and a RPF path is created for that listener.

As a result a router has DAO entries for all children that are = ancestors listening to a mcast group. It copies the mcast packet to all = its children, as opposed to unicast where it copies to only one child. = And it copies to the selected parent as well. It should refrain from = copying to the node that passed the packet, which should be a = waste.

 

Do you have a specific issue with this?)

 

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = KELLIL Mounir
Sent: Thursday, January 27, 2011 5:30 = PM
To: roll WG
Subject: [Roll] Question about RPL = and multicast

 

De= ar all,

 

In= the last version of RPL draft, it is mentioned that an RPL node (a = router) forwards multicast data to the preferred parents and to the = children that have subscribed to the multicast group. Yet, it is not = clear whether this packet forwarding is achieved through IP tunnelling = (multicast-in-unicast) or using L2 (unicast) relaying? (I’d say = the second is right, but I’m not sure). And, the same question = arises for the case of the multicast source within the = DODAG..

&n= bsp;

Be= st regards

 

Mo= unir

------_=_NextPart_001_01CBC486.4575A971-- From wintert@acm.org Fri Feb 4 11:59:45 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C4853A68AF for ; Fri, 4 Feb 2011 11:59:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQ0g-w5kQOI7 for ; Fri, 4 Feb 2011 11:59:44 -0800 (PST) Received: from smtp102.prem.mail.ac4.yahoo.com (smtp102.prem.mail.ac4.yahoo.com [76.13.13.41]) by core3.amsl.com (Postfix) with SMTP id B96203A692E for ; Fri, 4 Feb 2011 11:59:43 -0800 (PST) Received: (qmail 39623 invoked from network); 4 Feb 2011 20:03:03 -0000 Received: from [10.56.17.111] (wintert@71.178.253.216 with plain) by smtp102.prem.mail.ac4.yahoo.com with SMTP; 04 Feb 2011 12:03:03 -0800 PST X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: L6hnsOkVM1mUhcRwymA3LotpoYdyLLjSOiwAKNMYpWLqdoV s6al7wBtHAiavsXtMIEbF5.yg04KVg64X1dX9mYYDJvo4oCW3hFxdUf.9HUE g4bG_99yX8lvSKW6KhDASMJzgNWGeQJQBthQNtimRh_cKAUTsmXXL3FynnTZ _YOGFIB8KQSwj08pDbW8ynSAOc0KOfSUACfN1.wD2fzeAghlAS1Xzy4hE4w5 h7DdUBU.QMSx5AO7RxC75AFtGWsSsPmw4LgiGmxqmO2hYMQVff3n1Rxrvi5n _UURj3u2Ql5g2w5mZSUhXNq4frmPuJkkkE3Og02hNqZ82cs7gKWmDKlg9Kl0 bSloVAupsrDm3RTCkVOK7OUht1kxrsD7tMkoE X-Yahoo-Newman-Property: ymail-3 Message-ID: <4D4C5B77.30108@acm.org> Date: Fri, 04 Feb 2011 15:03:03 -0500 From: Tim Winter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: roll@ietf.org References: <20110204114502.26652.71352.idtracker@localhost> In-Reply-To: <20110204114502.26652.71352.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-18.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 19:59:45 -0000 WG, With RPL-18 we are still working to close out the remaining concerns brought up in IESG evaluation (https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/). Regards, -Tim On 02/04/2011 06:45 AM, Internet-Drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > > Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks > Author(s) : T. Winter, et al. > Filename : draft-ietf-roll-rpl-18.txt > Pages : 159 > Date : 2011-02-04 > > Low power and Lossy Networks (LLNs) are a class of network in which > both the routers and their interconnect are constrained. LLN routers > typically operate with constraints on processing power, memory, and > energy (battery power). Their interconnects are characterized by > high loss rates, low data rates, and instability. LLNs are comprised > of anything from a few dozen and up to thousands of routers. > Supported traffic flows include point-to-point (between devices > inside the LLN), point-to-multipoint (from a central control point to > a subset of devices inside the LLN), and multipoint-to-point (from > devices inside the LLN towards a central control point). This > document specifies the IPv6 Routing Protocol for LLNs (RPL), which > provides a mechanism whereby multipoint-to-point traffic from devices > inside the LLN towards a central control point, as well as point-to- > multipoint traffic from the central control point to the devices > inside the LLN, is supported. Support for point-to-point traffic is > also available. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-18.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From joakime@sics.se Fri Feb 4 12:35:45 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE5673A69D3 for ; Fri, 4 Feb 2011 12:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5niZb+gO9kY2 for ; Fri, 4 Feb 2011 12:35:44 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id C2DB93A67F5 for ; Fri, 4 Feb 2011 12:35:44 -0800 (PST) Received: from [192.168.1.6] (c-cc13e455.013-276-73746f7.cust.bredbandsbolaget.se [85.228.19.204]) (Authenticated sender: joakime@sics.se) by letter.sics.se (Postfix) with ESMTPSA id DB88640296; Fri, 4 Feb 2011 21:39:09 +0100 (CET) Message-ID: <4D4C63EE.9000207@sics.se> Date: Fri, 04 Feb 2011 21:39:10 +0100 From: Joakim Eriksson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: roll@ietf.org References: <20110130120001.31126.77239.idtracker@localhost> In-Reply-To: <20110130120001.31126.77239.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-routing-metrics-17.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 20:35:45 -0000 I had a quick read of the metrics draft and there is an inconsistency in the ETX section (8 vs 16 bits). Early in the section it is specified: "Each ETX sub-object has a fixed length of 8 bits" But just below there is a figure and a text explaining that it is 16 bits: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ETX | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: ETX sub-object format ETX: 16 bits. The ETX * 128 is encoded using 16 bits in unsigned integer format, rounded off to the nearest whole number. Best regards, -- Joakim Eriksson, SICS Internet-Drafts@ietf.org skrev 2011-01-30 13:00: > 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 : Routing Metrics used for Path Calculation in Low Power and Lossy Networks > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-roll-routing-metrics-17.txt > Pages : 30 > Date : 2011-01-30 > > Low power and Lossy Networks (LLNs) have unique characteristics > compared with traditional wired and ad-hoc networks that require the > specification of new routing metrics and constraints. By contrast > with typical Interior Gateway Protocol (IGP) routing metrics using > hop counts or link metrics, this document specifies a set of link and > node routing metrics and constraints suitable to LLNs to be used by > the Routing for Low Power and lossy networks (RPL) routing protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-17.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Fri Feb 4 12:36:35 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA31C3A6A3E for ; Fri, 4 Feb 2011 12:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iYY9gkuCteMR for ; Fri, 4 Feb 2011 12:36:34 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 8EE293A692E for ; Fri, 4 Feb 2011 12:36:34 -0800 (PST) Received: from dn0a21036e.sunet ([10.33.3.110]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PlSRk-00015j-11; Fri, 04 Feb 2011 12:40:00 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03C1F973@XMB-AMS-107.cisco.com> Date: Fri, 4 Feb 2011 12:39:59 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <0AA783B9-6F0D-4436-8AAF-E75D9CCB1C6F@cs.stanford.edu> References: <13A9A72D-36B2-453C-B5B4-D93F69C14BAE@cs.stanford.edu><37DC74FB-1E2A-41C7-AD1B-07B8D4294E55@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03C1F973@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: b64bce576883819501cf77c9371f4538 Cc: roll WG Subject: Re: [Roll] Local repair X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 20:36:35 -0000 On Feb 4, 2011, at 7:24 AM, Pascal Thubert (pthubert) wrote: > Hi Ulrich: > =20 > This is probably too late to change that text. I think it will be = useful to write informational docs describing some proposed behaviors, = and produce best practices. > =20 > With RPL, though, and as Phil explained, you have liberty to take = risks to recover faster, since the risk is later alleviated by the = datapath detection. > =20 > Poisoning and waiting as you proposed is a good recommendation in = classical networks and that=92s how (E)IGRP operate. So your suggestion = was certainly not irrelevant. > =20 > Cheers, > =20 > Pascal > http://www.xtranormal.com/watch/7011357/ I agree -- I think it's better to keep a specification, well, a = specification. It might make sense to have an Informational document = giving such advice as a follow-up, but it's important to separate = correctness from performance. Phil= From jeonggil.ko@gmail.com Fri Feb 4 12:42:57 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 031E23A6955 for ; Fri, 4 Feb 2011 12:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tRA3D24ZSJhz for ; Fri, 4 Feb 2011 12:42:55 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 772F73A67F5 for ; Fri, 4 Feb 2011 12:42:55 -0800 (PST) Received: by vxi40 with SMTP id 40so909633vxi.31 for ; Fri, 04 Feb 2011 12:46:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer; bh=wnFwUcH3fFjprrCFMn8jymLQGyWQxMEhv/RSlL2a6v4=; b=KyzMgpmZ89rAFtBu66Hmq0gbNrQun+QncF4xHkF5iZN/DjIIiBWHvP6R+J4mgasOgt fzPfxRZS3ilTtYU1GOgmqBF9MVszF9/qQHVLXGksNjeKYSap2YwiCwHSRU1IEZF5TGOA oBtnqoL/ofTrl3YVhbWPs39LLPM3JGTS0TlXE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=UCPOuRW/M9EKOmQBZfDKQK0yUzuWyLyz4ryAawZw75zsaLK2ppeLk41czN4gQ32UdT h3QDcbJMQ4raRmSLbHEyPZda4mxSvxeTTrYMmHoOi3fW2k+qZkIKL1yn4iJgkLHFiw2+ am5he8/5yj/0q8e3jV4E9EZiryTW6R66Rw/0k= Received: by 10.220.65.193 with SMTP id k1mr3144231vci.173.1296852380096; Fri, 04 Feb 2011 12:46:20 -0800 (PST) Received: from jgko.cs.jhu.edu (jgko.cs.jhu.edu [128.220.71.105]) by mx.google.com with ESMTPS id r7sm842049vbx.19.2011.02.04.12.46.18 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 04 Feb 2011 12:46:18 -0800 (PST) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=windows-1252 From: "JeongGil Ko (John)" In-Reply-To: <0AA783B9-6F0D-4436-8AAF-E75D9CCB1C6F@cs.stanford.edu> Date: Fri, 4 Feb 2011 15:46:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <467682D6-E244-48D6-8A72-067E380F1DCF@cs.jhu.edu> References: <13A9A72D-36B2-453C-B5B4-D93F69C14BAE@cs.stanford.edu><37DC74FB-1E2A-41C7-AD1B-07B8D4294E55@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03C1F973@XMB-AMS-107.cisco.com> <0AA783B9-6F0D-4436-8AAF-E75D9CCB1C6F@cs.stanford.edu> To: Philip Levis X-Mailer: Apple Mail (2.1082) Cc: roll WG Subject: Re: [Roll] Local repair X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 20:42:57 -0000 On Feb 4, 2011, at 3:39 PM, Philip Levis wrote: >=20 > On Feb 4, 2011, at 7:24 AM, Pascal Thubert (pthubert) wrote: >=20 >> Hi Ulrich: >>=20 >> This is probably too late to change that text. I think it will be = useful to write informational docs describing some proposed behaviors, = and produce best practices. >>=20 >> With RPL, though, and as Phil explained, you have liberty to take = risks to recover faster, since the risk is later alleviated by the = datapath detection. >>=20 >> Poisoning and waiting as you proposed is a good recommendation in = classical networks and that=92s how (E)IGRP operate. So your suggestion = was certainly not irrelevant. >>=20 >> Cheers, >>=20 >> Pascal >> http://www.xtranormal.com/watch/7011357/ >=20 > I agree -- I think it's better to keep a specification, well, a = specification. It might make sense to have an Informational document = giving such advice as a follow-up, but it's important to separate = correctness from performance. >=20 I agree with Phil about having an informational document that deals with = implementation or performance improvement related issues as a follow-up = document. John > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From ulrich@herberg.name Fri Feb 4 15:02:09 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CFE93A69FA for ; Fri, 4 Feb 2011 15:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnlQrTwAVAKr for ; Fri, 4 Feb 2011 15:02:08 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 590C43A69CD for ; Fri, 4 Feb 2011 15:02:08 -0800 (PST) Received: by vws7 with SMTP id 7so1940274vws.31 for ; Fri, 04 Feb 2011 15:05:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.181.69 with SMTP id bx5mr3131910vcb.171.1296860733984; Fri, 04 Feb 2011 15:05:33 -0800 (PST) Received: by 10.220.117.12 with HTTP; Fri, 4 Feb 2011 15:05:33 -0800 (PST) In-Reply-To: <467682D6-E244-48D6-8A72-067E380F1DCF@cs.jhu.edu> References: <13A9A72D-36B2-453C-B5B4-D93F69C14BAE@cs.stanford.edu> <37DC74FB-1E2A-41C7-AD1B-07B8D4294E55@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03C1F973@XMB-AMS-107.cisco.com> <0AA783B9-6F0D-4436-8AAF-E75D9CCB1C6F@cs.stanford.edu> <467682D6-E244-48D6-8A72-067E380F1DCF@cs.jhu.edu> Date: Sat, 5 Feb 2011 00:05:33 +0100 Message-ID: From: Ulrich Herberg To: "JeongGil Ko (John)" Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG Subject: Re: [Roll] Local repair X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Feb 2011 23:02:09 -0000 On Fri, Feb 4, 2011 at 9:46 PM, JeongGil Ko (John) wrote: > > On Feb 4, 2011, at 3:39 PM, Philip Levis wrote: [...] > > > > I agree -- I think it's better to keep a specification, well, a specification. It might make sense to have an Informational document giving such advice as a follow-up, but it's important to separate correctness from performance. > > > > I agree with Phil about having an informational document that deals with implementation or performance improvement related issues as a follow-up document. Yes, I think that we should document such issues; since the RPL draft is already very long, I am not opposed to having an additional informal document. Ulrich From azdvir@gmail.com Mon Feb 7 02:31:59 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9037D3A6ABD for ; Mon, 7 Feb 2011 02:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id USNBI8RJSVNq for ; Mon, 7 Feb 2011 02:31:53 -0800 (PST) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 27F293A6929 for ; Mon, 7 Feb 2011 02:31:52 -0800 (PST) Received: by fxm9 with SMTP id 9so5009370fxm.31 for ; Mon, 07 Feb 2011 02:31:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=qCfpkUGhd4lbL6yNMuKuwSFz+PNqgEBVSjpSOv/gwqs=; b=SIi64odn4qptwRO5VhuQP9jZbYiHwkuNN6kYTGtUrrV3yoUQv+9h0LKuqaFmEPr2fR gTIbtTHK+easU9/6QyaumPpzXWUPjb8KLa6484bW0ETe0wrkgLRU/eeGfRdyVD8IrbS0 A1UsUOmg6LzoSuL+gnNbSy6VwuWHKxuh893iE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; b=oGIxgyrvZS3Gk/0YLQx2CTpaXd4q2VG/6feZWmw6f0KmvokUFmWDRFHLLy6c2qANdz YvRBfE1M6+pxO64OTMN1SzAdDoQbNc8DAcr2+dLYyVfTaIaI5rNjPUePVzrhFB9KdyzI Qxb/GPsR13xLiz1pTAM3h5/V2K8yIb/B6tPsc= Received: by 10.223.101.131 with SMTP id c3mr650767fao.5.1297074716350; Mon, 07 Feb 2011 02:31:56 -0800 (PST) Received: from amitPC (ip146.crysys.hit.bme.hu [152.66.249.146]) by mx.google.com with ESMTPS id 5sm1096081fak.47.2011.02.07.02.31.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 07 Feb 2011 02:31:53 -0800 (PST) From: "amit dvir" To: "'Yoav Ben-Yehezkel'" , References: <028501cbb646$af727170$0e575450$@com> <6f8c73a9b8328b369d7c0b1d88770f9d@mail.gmail.com> In-Reply-To: <6f8c73a9b8328b369d7c0b1d88770f9d@mail.gmail.com> Date: Mon, 7 Feb 2011 11:31:53 +0100 Message-ID: <100d01cbc6b2$3d630910$b8291b30$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_100E_01CBC6BA.9F277110" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acu2RqnjKD+I/WciSHWTnRV3JfvieQFvoSAgAqr6X3A= Content-Language: he Subject: Re: [Roll] Security extensions to RPL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 10:31:59 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_100E_01CBC6BA.9F277110 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Yoav and WG, Thanks for your comments. We will consider your suggestion. Moreover, we will be happy to know the opinion of WG. Regards, Dr. Amit Dvir Post Doc Laboratory of Cryptography and System Security (CrySyS) Budapest University of Technology and Economics (BME) URL: http://www.amitdvir.com From: Yoav Ben-Yehezkel [mailto:yoav@yitran.com] Sent: Monday, January 24, 2011 9:36 PM To: amit dvir; roll@ietf.org Subject: RE: [Roll] Security extensions to RPL Hi Amit and WG, Thanks for the work you've put into this ID and for sharing this draft with the group. I would like to probe the WG opinion on splitting this draft into two separate IDs, one about DIO Message Authentication and the other about Local Key Agreement. As it stands, a draft called "security extensions to RPL" seems too general to understand what this draft is trying to accomplish (as there can be many more security extensions to RPL than the ones mentioned in this draft). Also, I have a feeling that the two extensions that are detailed in the draft are not so related, which one might expect from a single document describing two (out of N possible) extensions. Any thoughts from other members? Best regards, Yoav From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of amit dvir Sent: Monday, January 17, 2011 3:02 PM To: roll@ietf.org Subject: [Roll] Security extensions to RPL Hello, Let me kindly inform you that in an EU funded research project on dependable sensor networks (www.wsan4cip.eu), we adopted RPL as the routing protocol in our protocol stack for demonstrators, and we designed some security extensions to RPL (not yet covered by the current RPL security features). Our intention is to submit these extensions as an Internet Draft to the ROLL Working Group. The New Internet-Draft is available from the on-line Internet-Drafts directories: https://datatracker.ietf.org/doc/draft-dvir-roll-security-extensions/ We would be happy to receive comments related to this work. We also would like to mention that we are developing an implementation of RPL both in a TinyOS and in a Linux environment. We plan to make our implementation including the security extensions we specified in the New Internet-Draft available to the community later this year. Best regards, Dr. Amit Dvir Crypto and System Security Lab (CrySyS) Budapest University of Technology www.crysys.hu ------=_NextPart_000_100E_01CBC6BA.9F277110 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yoav and = WG,

 

Thanks for = your comments.

We will = consider your suggestion.

Moreover, we = will be happy to know the opinion of WG.

Regards,<= /o:p>

 

Dr. Amit = Dvir

Post = Doc

Laboratory of = Cryptography and System Security (CrySyS)

Budapest = University of Technology and Economics (BME)

URL: http://www.amitdvir.com

 

 

From:= = Yoav Ben-Yehezkel [mailto:yoav@yitran.com]
Sent: Monday, = January 24, 2011 9:36 PM
To: amit dvir; = roll@ietf.org
Subject: RE: [Roll] Security extensions to = RPL

 

Hi Amit and = WG,

 

Thanks for =
the work you’ve put into this ID and for sharing this draft with =
the group.
 <=
o:p>
I would like =
to probe the WG opinion on splitting this draft into two separate IDs, =
one about DIO Message Authentication and the other about Local Key =
Agreement.

 

As it stands, a draft called = “security extensions to RPL” seems too general to understand = what this draft is trying to accomplish (as there can be many more = security extensions to RPL than the ones mentioned in this draft). Also, = I have a feeling that the two extensions that are detailed in the draft = are not so related, which one might expect from a single document = describing two (out of N possible) extensions.

 

Any thoughts from other = members?

 

Best = regards,

Yoav

 

 

From:= = roll-bounces@ietf.org = [mailto:roll-bounces@ietf.org] On = Behalf Of amit dvir
Sent: Monday, January 17, 2011 3:02 = PM
To: roll@ietf.org
Subject: = [Roll] Security extensions to RPL

 

Hello,<= /p>

 =

Let me kindly inform you = that in an EU funded research project on dependable sensor networks (www.wsan4cip.eu), we adopted RPL as = the routing protocol in our protocol stack for demonstrators, and we = designed some security extensions to RPL (not yet covered by the = current RPL security features).

 <= /p>

Our intention is to = submit these extensions as an Internet Draft to the ROLL Working Group. = The New Internet-Draft is available from the on-line = Internet-Drafts directories:

 <= /p>

https://datatracker.ietf.org/doc/draft-dvir-roll-security-extension= s/

 <= /p>

 <= /p>

We would be happy to = receive comments related to this work.

 =

We also would like to = mention that we are developing an implementation of RPL both in a TinyOS = and in a Linux environment. We plan to make our implementation including = the security extensions we specified in the New Internet-Draft = available to the community later this year.

 <= /p>

 =

Best = regards,

 <= /p>

Dr. Amit = Dvir

Crypto and System = Security Lab (CrySyS)

Budapest University of = Technology

www.crysys.hu

 

------=_NextPart_000_100E_01CBC6BA.9F277110-- From c.chauvenet@watteco.com Mon Feb 7 02:50:07 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C7B93A6D9A for ; Mon, 7 Feb 2011 02:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFm5kM+jG+57 for ; Mon, 7 Feb 2011 02:50:05 -0800 (PST) Received: from TX2EHSOBE001.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by core3.amsl.com (Postfix) with ESMTP id 670F13A6D8E for ; Mon, 7 Feb 2011 02:50:05 -0800 (PST) Received: from mail196-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.8; Mon, 7 Feb 2011 10:50:08 +0000 Received: from mail196-tx2 (localhost.localdomain [127.0.0.1]) by mail196-tx2-R.bigfish.com (Postfix) with ESMTP id CA0ABA2817C; Mon, 7 Feb 2011 10:50:08 +0000 (UTC) X-SpamScore: -95 X-BigFish: VPS-95(zz1418M1432N15caKJ98dN9371Pzz1202hzz8275dh1033ILz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB012.red002.local; RD:none; EFVD:NLI X-FB-SS: 0, Received: from mail196-tx2 (localhost.localdomain [127.0.0.1]) by mail196-tx2 (MessageSwitch) id 1297075808408378_12245; Mon, 7 Feb 2011 10:50:08 +0000 (UTC) Received: from TX2EHSMHS029.bigfish.com (unknown [10.9.14.254]) by mail196-tx2.bigfish.com (Postfix) with ESMTP id 5F24612F804C; Mon, 7 Feb 2011 10:50:08 +0000 (UTC) Received: from IE2RD2HUB012.red002.local (213.199.187.153) by TX2EHSMHS029.bigfish.com (10.9.99.129) with Microsoft SMTP Server (TLS) id 14.1.225.8; Mon, 7 Feb 2011 10:50:01 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB012.red002.local ([10.33.16.251]) with mapi; Mon, 7 Feb 2011 02:49:56 -0800 From: C Chauvenet To: Ulrich Herberg , "JeongGil Ko (John)" Date: Mon, 7 Feb 2011 02:50:16 -0800 Thread-Topic: [Roll] Local repair Thread-Index: AQLYvlCWv/SxZ7m9vIoVTOyxXZlSqgGIlE5sAX1gQbUBwKRDMQKsGNQ6Aj0zOu0BbQubCQLJtjHyAWH9g+GRYad+gA== Message-ID: References: <13A9A72D-36B2-453C-B5B4-D93F69C14BAE@cs.stanford.edu> <37DC74FB-1E2A-41C7-AD1B-07B8D4294E55@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03C1F973@XMB-AMS-107.cisco.com> <0AA783B9-6F0D-4436-8AAF-E75D9CCB1C6F@cs.stanford.edu> <467682D6-E244-48D6-8A72-067E380F1DCF@cs.jhu.edu> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR 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 WG Subject: Re: [Roll] Local repair X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 10:50:07 -0000 +1 for the value of an informal document. C=E9dric -----Message d'origine----- De=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de U= lrich Herberg Envoy=E9=A0: samedi 5 f=E9vrier 2011 00:06 =C0=A0: JeongGil Ko (John) Cc=A0: roll WG Objet=A0: Re: [Roll] Local repair On Fri, Feb 4, 2011 at 9:46 PM, JeongGil Ko (John) wrote: > > On Feb 4, 2011, at 3:39 PM, Philip Levis wrote: [...] > > > > I agree -- I think it's better to keep a specification, well, a specifi= cation. It might make sense to have an Informational document giving such a= dvice as a follow-up, but it's important to separate correctness from perfo= rmance. > > > > I agree with Phil about having an informational document that deals with = implementation or performance improvement related issues as a follow-up doc= ument. Yes, I think that we should document such issues; since the RPL draft is al= ready very long, I am not opposed to having an additional informal document= . Ulrich _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From Internet-Drafts@ietf.org Mon Feb 7 05:30:02 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58E193A6E00; Mon, 7 Feb 2011 05:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.349 X-Spam-Level: X-Spam-Status: No, score=-102.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jMQLOt0tCxhn; Mon, 7 Feb 2011 05:30:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D8F43A6DFF; Mon, 7 Feb 2011 05:30:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110207133001.29286.20650.idtracker@localhost> Date: Mon, 07 Feb 2011 05:30:01 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-p2p-rpl-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 13:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Author(s) : M. Goyal, et al. Filename : draft-ietf-roll-p2p-rpl-02.txt Pages : 23 Date : 2011-02-07 Point to point (P2P) communication between arbitrary IPv6 routers and hosts 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 RPL-aware IPv6 router or host to discover and establish, on demand, one or more routes to another RPL-aware IPv6 router or host in the LLN such that the discovered routes meet a specified cost criteria. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-p2p-rpl-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-07052456.I-D@ietf.org> --NextPart-- From prvs=0123ff3bf=mukul@uwm.edu Mon Feb 7 05:37:37 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C935F3A6E08 for ; Mon, 7 Feb 2011 05:37:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zFhYcgL1iMDx for ; Mon, 7 Feb 2011 05:37:36 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id C72E43A6E06 for ; Mon, 7 Feb 2011 05:37:36 -0800 (PST) Received: from mta01.pantherlink.uwm.edu ([129.89.7.132]) by ip2mta.uwm.edu with ESMTP; 07 Feb 2011 07:37:40 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id C662AE6A72 for ; Mon, 7 Feb 2011 07:37:40 -0600 (CST) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SFxOnvV5yHr7 for ; Mon, 7 Feb 2011 07:37:40 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 444E3E6A80 for ; Mon, 7 Feb 2011 07:37:40 -0600 (CST) Date: Mon, 7 Feb 2011 07:37:40 -0600 (CST) From: Mukul Goyal To: roll Message-ID: <639318539.2361953.1297085860205.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <20110207132456.955263A6DFA@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Fwd: New Version Notification for draft-ietf-roll-p2p-rpl-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 13:37:38 -0000 Hi all A new version of the p2p-rpl draft is available for your reading pleasure. Apart from a large number of editorial changes, the main changes are as follows: 1) Link metrics to be calculated based on the direction of the routes being discovered: This issue needs to be resolved at the RPL level. I am working on a new ID on this issue. 2) Moved route constraints inside RDO. Now that the metrics draft allows/requires the constraints to be modified enroute (it is not clear what the case is and I am still waiting for the metrics draft authors to respond to my query of few days back), the processing of route constraints would need further modifications in the next version of the draft. 3) minimum life time of the temporary DAG is now specified as an exponent of 2. 4) No discarding of the DIO if a metric cant be calculated. We let the metrics be processed as in base RPL. A DIO is discarded only if the propagation/route constraint can be evaluated/enforced. There is additional issue of garbage collection for defunct DAGs. This issue again needs to be resolved at the RPL level. I will be sending out a new ID on this issue too. The security and IANA sections are still empty in the new P2P draft version. Thanks Mukul ----- Forwarded Message ----- From: "IETF I-D Submission Tool" To: mukul@uwm.edu Cc: "Emmanuel Baccelli" , abr@sdesigns.dk, "robert cragie" , "jerald p martocci" , charliep@computer.org Sent: Monday, February 7, 2011 7:24:56 AM Subject: New Version Notification for draft-ietf-roll-p2p-rpl-02 A new version of I-D, draft-ietf-roll-p2p-rpl-02.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository. Filename: draft-ietf-roll-p2p-rpl Revision: 02 Title: Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Creation_date: 2011-02-07 WG ID: roll Number_of_pages: 23 Abstract: Point to point (P2P) communication between arbitrary IPv6 routers and hosts 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 RPL-aware IPv6 router or host to discover and establish, on demand, one or more routes to another RPL-aware IPv6 router or host in the LLN such that the discovered routes meet a specified cost criteria. The IETF Secretariat. From gnawali@cs.stanford.edu Fri Feb 11 15:13:39 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2C0C3A6A04 for ; Fri, 11 Feb 2011 15:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YOTH8yDNh04h for ; Fri, 11 Feb 2011 15:13:38 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id EE9783A69FD for ; Fri, 11 Feb 2011 15:13:38 -0800 (PST) Received: from mail-iw0-f172.google.com ([209.85.214.172]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Po2BW-00089U-UL for roll@ietf.org; Fri, 11 Feb 2011 15:13:55 -0800 Received: by iwc10 with SMTP id 10so3097634iwc.31 for ; Fri, 11 Feb 2011 15:13:54 -0800 (PST) Received: by 10.42.218.6 with SMTP id ho6mr1412483icb.1.1297466034110; Fri, 11 Feb 2011 15:13:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.59.15 with HTTP; Fri, 11 Feb 2011 15:13:34 -0800 (PST) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D037A6D27@XMB-AMS-107.cisco.com> References: <20101208110001.23189.39421.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D035E7722@XMB-AMS-107.cisco.com> <4195CC18-FAD9-4394-A323-3437F628D5E0@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03670773@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03671377@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D03704658@XMB-AMS-107.cisco.com> <45702464-26A4-4E63-85B6-30A577157875@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D037A6D27@XMB-AMS-107.cisco.com> From: Omprakash Gnawali Date: Fri, 11 Feb 2011 15:13:34 -0800 Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 764eb63bb4c91aa8ddbf2de6f9e489d2 Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Feb 2011 23:13:39 -0000 On Wed, Dec 22, 2010 at 4:39 AM, Pascal Thubert (pthubert) wrote: .... > [Pascal] > OF 0 is not the default OF (there none). But is it the last resort, when > nothing else is either available or needed. > The 0 indicates the absolute minimalistic aspect of that OF. Like a 0 in > a soda name as opposed to =A0a default. > I'll glad to add words from this discussion and be very specific about > this. > > Now, people have been used to that name and changing might increase the > confusion, wouldn't you think? > Let's see what other people say. If we decide to change, I tend to favor > LROF (Last Resort OF). Last resort describes a policy rather than a property. What one network decides to do as a last resort might not be what a different network might do as a last resort. I suggest No/null metric OF. - om_p From gnawali@cs.stanford.edu Sun Feb 13 11:17:20 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B7FC3A6AC4 for ; Sun, 13 Feb 2011 11:17:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GQdEnTEnSvzq for ; Sun, 13 Feb 2011 11:17:19 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 6859E3A69A7 for ; Sun, 13 Feb 2011 11:17:19 -0800 (PST) Received: from mail-iy0-f172.google.com ([209.85.210.172]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1PohS0-00050z-4p for roll@ietf.org; Sun, 13 Feb 2011 11:17:40 -0800 Received: by iym1 with SMTP id 1so4437728iym.31 for ; Sun, 13 Feb 2011 11:17:39 -0800 (PST) Received: by 10.231.36.199 with SMTP id u7mr2323866ibd.16.1297624659159; Sun, 13 Feb 2011 11:17:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.59.15 with HTTP; Sun, 13 Feb 2011 11:17:19 -0800 (PST) In-Reply-To: <90B88918-D3B5-4A2F-88EF-95F26E1B5FB8@cisco.com> References: <90B88918-D3B5-4A2F-88EF-95F26E1B5FB8@cisco.com> From: Omprakash Gnawali Date: Sun, 13 Feb 2011 11:17:19 -0800 Message-ID: To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 4c7a780eb20f40a19c8376fd8d8b00d5 Cc: ROLL WG Subject: Re: [Roll] draft-tripathi-roll-rpl-simulation-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Feb 2011 19:17:20 -0000 On Wed, Feb 2, 2011 at 12:46 AM, JP Vasseur wrote: > Dear all, > Since=A0draft-tripathi-roll-rpl-simulation-06 has been discussed for quit= e > some time and is now fully stable, the authors intend to request the > independent publication of the document. Do not hesitate to chime in if y= ou > are opposed to it. I thought there were some serious questions raised about the methodology etc. Not sure if they have been addressed. Also not sure if they need to be addressed if this is an independent publication. - om_p From jau@ece.drexel.edu Mon Feb 14 11:28:45 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1CEC3A6DA4 for ; Mon, 14 Feb 2011 11:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t8xDtVcKA5al for ; Mon, 14 Feb 2011 11:28:42 -0800 (PST) Received: from mail.ece.drexel.edu (mail.ece.drexel.edu [129.25.60.32]) by core3.amsl.com (Postfix) with ESMTP id 1BF853A6DA3 for ; Mon, 14 Feb 2011 11:28:42 -0800 (PST) Received: from [129.25.14.14] (n1-14-14.dhcp.drexel.edu [129.25.14.14]) by mail.ece.drexel.edu (Postfix) with ESMTP id 63E1B33B20; Mon, 14 Feb 2011 14:29:05 -0500 (EST) In-Reply-To: References: <90B88918-D3B5-4A2F-88EF-95F26E1B5FB8@cisco.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: multipart/alternative; boundary=Apple-Mail-107--570435002 Message-Id: <1B43B188-2AC4-43DF-B61C-7ACDDEC512B0@ece.drexel.edu> From: Jaudelice de Oliveira Date: Mon, 14 Feb 2011 14:30:28 -0500 To: Omprakash Gnawali X-Mailer: Apple Mail (2.753.1) Cc: ROLL WG Subject: Re: [Roll] draft-tripathi-roll-rpl-simulation-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Feb 2011 19:28:45 -0000 --Apple-Mail-107--570435002 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Hello Omprakash, On Feb 13, 2011, at 2:17 PM, Omprakash Gnawali wrote: > On Wed, Feb 2, 2011 at 12:46 AM, JP Vasseur wrote: >> Dear all, >> Since draft-tripathi-roll-rpl-simulation-06 has been discussed for >> quite >> some time and is now fully stable, the authors intend to request the >> independent publication of the document. Do not hesitate to chime >> in if you >> are opposed to it. > > I thought there were some serious questions raised about the > methodology etc. Not sure if they have been addressed. Can you elaborate a bit on your comment above so I can tell you how the document was revised accordingly. We did address all comments we were given, including yours. BTW: thanks again for your feedback. Jau. Jaudelice C. de Oliveira Associate Professor ECE Dept., Drexel University http://www.ece.drexel.edu/faculty/deoliveira/ > Also not sure > if they need to be addressed if this is an independent publication. > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-107--570435002 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=US-ASCII Hello Omprakash,

On = Feb 13, 2011, at 2:17 PM, Omprakash Gnawali = wrote:

On Wed, Feb 2, 2011 at 12:46 AM, JP Vasseur <jpv@cisco.com> wrote:
=
Dear all,
Since draft-tripathi-roll-rpl-simulation-06 has = been discussed for quite
some time and = is now fully stable, the authors intend to request the
independent publication of the document. Do not = hesitate to chime in if you
are opposed = to it.
I thought there were some = serious questions raised about the
methodology = etc. Not sure if they have been addressed. =

Can you elaborate a bit on your = comment above so I can tell you how the document
was revised = accordingly. We did address all comments we were given, including = yours. 
BTW: thanks again for your = feedback.

Jau.



Jaudelice C. de = Oliveira
Associate = Professor
ECE Dept., Drexel = University


Also not sure
if they need to be addressed if this is an = independent = publication.


- om_p
Roll mailing list
=

= --Apple-Mail-107--570435002-- From gnawali@cs.stanford.edu Wed Feb 16 15:31:38 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9FE583A6D98 for ; Wed, 16 Feb 2011 15:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6O6yB40CU8cC for ; Wed, 16 Feb 2011 15:31:37 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id C363F3A6CE4 for ; Wed, 16 Feb 2011 15:31:37 -0800 (PST) Received: from mail-iw0-f172.google.com ([209.85.214.172]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Ppqqt-00058d-34 for roll@ietf.org; Wed, 16 Feb 2011 15:32:07 -0800 Received: by iwc10 with SMTP id 10so1997216iwc.31 for ; Wed, 16 Feb 2011 15:32:06 -0800 (PST) Received: by 10.42.225.133 with SMTP id is5mr1746285icb.135.1297899126213; Wed, 16 Feb 2011 15:32:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.59.15 with HTTP; Wed, 16 Feb 2011 15:31:46 -0800 (PST) In-Reply-To: <1B43B188-2AC4-43DF-B61C-7ACDDEC512B0@ece.drexel.edu> References: <90B88918-D3B5-4A2F-88EF-95F26E1B5FB8@cisco.com> <1B43B188-2AC4-43DF-B61C-7ACDDEC512B0@ece.drexel.edu> From: Omprakash Gnawali Date: Wed, 16 Feb 2011 15:31:46 -0800 Message-ID: To: Jaudelice de Oliveira Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 26b8f8cb9d50f38c95a96ded60a4c5d6 Cc: ROLL WG Subject: Re: [Roll] draft-tripathi-roll-rpl-simulation-06 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2011 23:31:38 -0000 On Mon, Feb 14, 2011 at 11:30 AM, Jaudelice de Oliveira wrote: > Hello Omprakash, > On Feb 13, 2011, at 2:17 PM, Omprakash Gnawali wrote: > > On Wed, Feb 2, 2011 at 12:46 AM, JP Vasseur wrote: > > Dear all, > Since=A0draft-tripathi-roll-rpl-simulation-06 has been discussed for quit= e > some time and is now fully stable, the authors intend to request the > independent publication of the document. Do not hesitate to chime in if y= ou > are opposed to it. > > I thought there were some serious questions raised about the > methodology etc. Not sure if they have been addressed. > > Can you elaborate a bit on your comment above so I can tell you how the > document > was revised accordingly. We did address all comments we were given, > including yours. > BTW: thanks again for your feedback. >From ROLL Virtual Working Group Minutes - June 2010: " ... David C.: Can I respond to that? It's wonderful to be driving these decisio= ns from data. Great to see these results and this process going. To me, the question isn't whether we should have a simulation working group document, but in what form. The issue is that the conclusions we reach are so based on a set of assumptions. Underlying topology, churn, traffic pattern, etc. What I'd like to see is to build up an understanding of what needs to be in the WG document to be useful. We should set out what the simulation methodology is, this is more important than any particular study. David C.: That's my biggest concern, going from the individual draft into a document that the working group could benefit from. There should be a WG document on anaylsis and how to do this going forward, and I'd want to hear from the WG an understanding of what is important. ... " On this mailing list on 14 Jun 2010 14:04:01 -0700: " ... 1) My concerns with the methodology remain; assuming independent packet losses over 10-minute intervals can have significant effects on how a protocol reacts (e.g., NUD). It makes me unable to make strong conclusions from any of the rest of the results. 2) "To simulate a more realistic scenario, 20% of the generated packets by each node are destined to the root, and the remaining 80% of the packets are uniformly assigned as destined to nodes other than the root." Can you provide some insight into why this is more "realistic?" Networks rarely follow uniform distributions, and using one can make you reach the wrong conclusion (e.g., algorithm X scales when it doesn't in real patterns). Note that these are basic concerns with the methodology to obtain the resul= ts. Phil " - om_p From gnawali@cs.stanford.edu Wed Feb 16 21:43:22 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E5D23A6CDC for ; Wed, 16 Feb 2011 21:43:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id moArkoguwTv2 for ; Wed, 16 Feb 2011 21:43:21 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 964D13A6CD1 for ; Wed, 16 Feb 2011 21:43:21 -0800 (PST) Received: from mail-iw0-f172.google.com ([209.85.214.172]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Ppwed-0003Vk-9N for roll@ietf.org; Wed, 16 Feb 2011 21:43:51 -0800 Received: by iwc10 with SMTP id 10so2252521iwc.31 for ; Wed, 16 Feb 2011 21:43:50 -0800 (PST) Received: by 10.231.30.75 with SMTP id t11mr1255176ibc.91.1297921430484; Wed, 16 Feb 2011 21:43:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.59.15 with HTTP; Wed, 16 Feb 2011 21:43:30 -0800 (PST) From: Omprakash Gnawali Date: Wed, 16 Feb 2011 21:43:30 -0800 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 9dddbef7dbf47a29383c7a3c8e5dce6e Subject: [Roll] comments on mrhof draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 05:43:22 -0000 Dear ROLL WG, I am in the process of updating the minimum rank with hysteresis objective function draft. We had discussions related to needing to bolster of0 (null metric of) with link qualities and the suggestion was to just use mrhof(etx). It also turns out some people thought they were implementing null metric OF but they were implementing mrhof(etx). Here is a link to the draft: http://tools.ietf.org/html/draft-gnawali-roll-minrank-hysteresis-of-02 This OF converts the metrics into rank using hard coded constants to scale. If people got a chance to work on metric implementations and use something like mrhof, it will be good to incorporate those suggestions to improve the draft. I will appreciate your comments. Thanks. - om_p From alexandru.petrescu@gmail.com Fri Feb 18 06:53:28 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DE98C3A6CF2 for ; Fri, 18 Feb 2011 06:53:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdLgoW7AlHf3 for ; Fri, 18 Feb 2011 06:53:27 -0800 (PST) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id BEA073A6B6C for ; Fri, 18 Feb 2011 06:53:26 -0800 (PST) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id p1IErxlj016823 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 18 Feb 2011 15:53:59 +0100 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id p1IErxVx031750 for ; Fri, 18 Feb 2011 15:53:59 +0100 (envelope-from alexandru.petrescu@gmail.com) Received: from [132.166.133.173] (is010173.intra.cea.fr [132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id p1IErx8o027721 for ; Fri, 18 Feb 2011 15:53:59 +0100 Message-ID: <4D5E8806.7090300@gmail.com> Date: Fri, 18 Feb 2011 15:53:58 +0100 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: roll@ietf.org References: <20110204114502.26652.71352.idtracker@localhost> <4D4C5B77.30108@acm.org> In-Reply-To: <4D4C5B77.30108@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-rpl-18.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Feb 2011 14:53:28 -0000 Thanks for the new version. I can't seem to understand the example in new A.5 at least because it seems to say Root has two interfaces but one RPL::Root address - this seems wrong because it's hard to put a same (non-link-local) address on two different interfaces. Also it seems to say Root has an interface in the EXT_1 prefix yet Root does not have an address in that prefix. A picture like this would be more clear to me: RPL Network +-------------------+ RPL::/64 | | fe80::Root| External | (Root)----------+ Prefix | | | EXT_1::/64 | RPL::Root | | | | +-------------------+ instead of this: RPL Network +-------------------+ RPL::/64 | | | External | [RPL::Root] (Root)----------+ Prefix | | | EXT_1::/64 | | | | | +-------------------+ Also, when building these kinds of networks (RPL::/64 connected to both EXT_1::/64 and EXT_2::/64) it is important to tell which path the packets take to make sure no loops. Text doesn't seem to say so. > The DODAG Root may have learned of connectivity to this prefix, for > example, via explicit configuration or IPv6 ND on a non-RPL > interface. It is important for Root to know how to route packets src'ed from RPL:: to EXT_1 _and_ beyond it, and ND can help to route to EXT_1 but not beyond it. Is this RPL Network connected to the Internet? Is there a default route? Is the default routing more towards EXT_1 or more EXT_2? Are nodes in EXT_1 reaching nodes in EXT_2 via RPL? Alex Le 04/02/2011 21:03, Tim Winter a écrit : > WG, > > With RPL-18 we are still working to close out the remaining concerns > brought up in IESG evaluation > (https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/). > > Regards, > > -Tim > > > On 02/04/2011 06:45 AM, Internet-Drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Routing Over Low >> power and Lossy networks Working Group of the IETF. >> >> >> Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks >> Author(s) : T. Winter, et al. Filename : draft-ietf-roll-rpl-18.txt >> Pages : 159 Date : 2011-02-04 >> >> Low power and Lossy Networks (LLNs) are a class of network in which >> both the routers and their interconnect are constrained. LLN >> routers typically operate with constraints on processing power, >> memory, and energy (battery power). Their interconnects are >> characterized by high loss rates, low data rates, and instability. >> LLNs are comprised of anything from a few dozen and up to >> thousands of routers. Supported traffic flows include >> point-to-point (between devices inside the LLN), >> point-to-multipoint (from a central control point to a subset of >> devices inside the LLN), and multipoint-to-point (from devices >> inside the LLN towards a central control point). This document >> specifies the IPv6 Routing Protocol for LLNs (RPL), which provides >> a mechanism whereby multipoint-to-point traffic from devices inside >> the LLN towards a central control point, as well as point-to- >> multipoint traffic from the central control point to the devices >> inside the LLN, is supported. Support for point-to-point traffic is >> also available. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-18.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> >> _______________________________________________ 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 gnawali@cs.stanford.edu Sat Feb 19 08:35:45 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8E03A6F64 for ; Sat, 19 Feb 2011 08:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KB1h-4-RLoMC for ; Sat, 19 Feb 2011 08:35:44 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 50F2B3A6F5B for ; Sat, 19 Feb 2011 08:35:44 -0800 (PST) Received: from mail-iw0-f172.google.com ([209.85.214.172]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1PqpnA-0003kH-SW for roll@ietf.org; Sat, 19 Feb 2011 08:36:21 -0800 Received: by iwl42 with SMTP id 42so1466971iwl.31 for ; Sat, 19 Feb 2011 08:36:20 -0800 (PST) Received: by 10.42.19.131 with SMTP id c3mr2410794icb.68.1298133380139; Sat, 19 Feb 2011 08:36:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.59.15 with HTTP; Sat, 19 Feb 2011 08:36:00 -0800 (PST) From: Omprakash Gnawali Date: Sat, 19 Feb 2011 08:36:00 -0800 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 4c7a780eb20f40a19c8376fd8d8b00d5 Subject: [Roll] what link/routing metrics are people using with RPL? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 16:35:45 -0000 Working on MRHOF, I would like to know if people are using metrics other than ETX. In the implementations I am familiar with, ETX or something similar to ETX is being used. If people are using any other metric, it will be great to know how they are computing the rank based on those metrics. Are they converting them into rank with the way suggested in MRHOF draft? If there are better ways to do that conversion, it will be great to incorporate those ideas into MRHOF. If people who are building real networks have not found other metrics useful in their implementations, that is useful to know as well. - om_p From malvira@devl.org Sat Feb 19 11:03:13 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89A443A6FB2 for ; Sat, 19 Feb 2011 11:03:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.537 X-Spam-Level: X-Spam-Status: No, score=-1.537 tagged_above=-999 required=5 tests=[AWL=0.141, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ns1iRhbuL+m6 for ; Sat, 19 Feb 2011 11:03:12 -0800 (PST) Received: from devl.org (a.redwirellc.com [75.150.83.154]) by core3.amsl.com (Postfix) with ESMTP id 81C1A3A6FB0 for ; Sat, 19 Feb 2011 11:03:12 -0800 (PST) Received: from malvira by devl.org with local (Exim 4.69) (envelope-from ) id 1Pqs5t-00021d-9L; Sat, 19 Feb 2011 14:03:49 -0500 Date: Sat, 19 Feb 2011 14:03:49 -0500 From: Mariano Alvira To: Omprakash Gnawali Message-ID: <20110219190349.GA7777@devl.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ROLL WG Subject: Re: [Roll] what link/routing metrics are people using with RPL? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 19:03:13 -0000 On Sat, Feb 19, 2011 at 08:36:00AM -0800, Omprakash Gnawali wrote: > Working on MRHOF, I would like to know if people are using metrics > other than ETX. In the implementations I am familiar with, ETX or > something similar to ETX is being used. > > If people are using any other metric, it will be great to know how > they are computing the rank based on those metrics. Are they > converting them into rank with the way suggested in MRHOF draft? If > there are better ways to do that conversion, it will be great to > incorporate those ideas into MRHOF. > > If people who are building real networks have not found other metrics > useful in their implementations, that is useful to know as well. > > - om_p I've done testing with PATHDR which is an LQI based method. I've detailed my tests here: http://devl.org/pipermail/mc1322x/2010-October/000548.html My tests are with Econotags running Contiki arranged in a 23-node test-grid with attenuated antennas; this lets me do multi-hop testing in a compact space. I converted to rank by mapping the path probability of delivery to rank (high probability equals low rank). I can point out the relevant lines in my patches if you want more information. I find LQI based metrics interesting as they do not need link level probing. I've since implemented 802.15.4 acknowledgements and can now start testing with ETX. -Mar. From pal@cs.stanford.edu Sat Feb 19 11:11:00 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 683CD3A6DDA for ; Sat, 19 Feb 2011 11:11:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4c-TJdWdhIIR for ; Sat, 19 Feb 2011 11:10:56 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id D148C3A6F98 for ; Sat, 19 Feb 2011 11:10:56 -0800 (PST) Received: from [76.14.66.110] (helo=[192.168.0.101]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PqsDN-0003lw-Ou; Sat, 19 Feb 2011 11:11:33 -0800 In-Reply-To: <20110219190349.GA7777@devl.org> References: <20110219190349.GA7777@devl.org> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Levis Date: Sat, 19 Feb 2011 11:11:32 -0800 To: Mariano Alvira X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: f033b90f7cba6c0793427b12797f2d01 Cc: ROLL WG Subject: Re: [Roll] what link/routing metrics are people using with RPL? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 19:11:00 -0000 On Feb 19, 2011, at 11:03 AM, Mariano Alvira wrote: > > > I find LQI based metrics interesting as they do not need link level > probing. Not true in the presence of external interference. Phil From malvira@devl.org Sat Feb 19 11:24:00 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC4AD3A6D6A for ; Sat, 19 Feb 2011 11:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.583 X-Spam-Level: X-Spam-Status: No, score=-1.583 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xxjTiro2Nawp for ; Sat, 19 Feb 2011 11:24:00 -0800 (PST) Received: from devl.org (a.redwirellc.com [75.150.83.154]) by core3.amsl.com (Postfix) with ESMTP id 0B9DF3A6D36 for ; Sat, 19 Feb 2011 11:24:00 -0800 (PST) Received: from malvira by devl.org with local (Exim 4.69) (envelope-from ) id 1PqsQ0-00025u-J7; Sat, 19 Feb 2011 14:24:36 -0500 Date: Sat, 19 Feb 2011 14:24:36 -0500 From: Mariano Alvira To: Philip Levis Message-ID: <20110219192436.GA7956@devl.org> References: <20110219190349.GA7777@devl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ROLL WG Subject: Re: [Roll] what link/routing metrics are people using with RPL? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 19:24:01 -0000 On Sat, Feb 19, 2011 at 11:11:32AM -0800, Philip Levis wrote: > > On Feb 19, 2011, at 11:03 AM, Mariano Alvira wrote: >> >> >> I find LQI based metrics interesting as they do not need link level >> probing. > > Not true in the presence of external interference. I should clarify that my main interest at the time was that it was much easier to implement an LQI based metric rather that to get the 802.15.4 autoacks working on the mc13224v. But now that I have that working, I suppose it doesn't make much difference to me. -Mar. From pal@cs.stanford.edu Sat Feb 19 11:45:52 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B6783A6D6A for ; Sat, 19 Feb 2011 11:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DKUpyqStKcm for ; Sat, 19 Feb 2011 11:45:51 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id DD1EC3A6F30 for ; Sat, 19 Feb 2011 11:45:51 -0800 (PST) Received: from [76.14.66.110] (helo=[192.168.0.104]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PqslA-0004zP-HV; Sat, 19 Feb 2011 11:46:28 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <20110219192436.GA7956@devl.org> Date: Sat, 19 Feb 2011 11:46:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110219190349.GA7777@devl.org> <20110219192436.GA7956@devl.org> To: Mariano Alvira X-Mailer: Apple Mail (2.1082) X-Scan-Signature: a11a15d02c0ec4233875b3872b0caebb Cc: ROLL WG Subject: Re: [Roll] what link/routing metrics are people using with RPL? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 19:45:52 -0000 On Feb 19, 2011, at 11:24 AM, Mariano Alvira wrote: > On Sat, Feb 19, 2011 at 11:11:32AM -0800, Philip Levis wrote: >>=20 >> On Feb 19, 2011, at 11:03 AM, Mariano Alvira wrote: >>>=20 >>>=20 >>> I find LQI based metrics interesting as they do not need link level >>> probing. >>=20 >> Not true in the presence of external interference. >=20 > I should clarify that my main interest at the time was that it was > much easier to implement an LQI based metric rather that to get the > 802.15.4 autoacks working on the mc13224v. But now that I have that > working, I suppose it doesn't make much difference to me. Sure -- physical layer information on chip error rates is a very quick = and easy way to obtain not terrible link estimates that mostly work. But = generally you want a protocol to do better than "not terrible" and be = more dependable than "mostly." Phil= From malvira@devl.org Sat Feb 19 12:04:48 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 386DD3A6FB6 for ; Sat, 19 Feb 2011 12:04:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qPq5JENPpead for ; Sat, 19 Feb 2011 12:04:47 -0800 (PST) Received: from devl.org (a.redwirellc.com [75.150.83.154]) by core3.amsl.com (Postfix) with ESMTP id 74DD43A6FB5 for ; Sat, 19 Feb 2011 12:04:47 -0800 (PST) Received: from malvira by devl.org with local (Exim 4.69) (envelope-from ) id 1Pqt3T-0002G7-Qu; Sat, 19 Feb 2011 15:05:23 -0500 Date: Sat, 19 Feb 2011 15:05:23 -0500 From: Mariano Alvira To: Philip Levis Message-ID: <20110219200523.GA8481@devl.org> References: <20110219190349.GA7777@devl.org> <20110219192436.GA7956@devl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) Cc: ROLL WG Subject: Re: [Roll] what link/routing metrics are people using with RPL? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 20:04:48 -0000 On Sat, Feb 19, 2011 at 11:46:29AM -0800, Philip Levis wrote: > > > But generally you want a protocol to do better than "not terrible" and be more dependable than "mostly." > Yes definitely! Although part of that is to also make these radios work better than "not terrible" and more dependable than "mostly" --- which can take quite an effort. But I'm glad; from what you are saying it sounds like the time I'm investing now in autoacking will lead to major benefits from all the layers. -Mar. From gnawali@cs.stanford.edu Sat Feb 19 12:55:35 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E1A473A6FAA for ; Sat, 19 Feb 2011 12:55:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGKiFPgFWhxe for ; Sat, 19 Feb 2011 12:55:35 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 26C173A6CF4 for ; Sat, 19 Feb 2011 12:55:35 -0800 (PST) Received: from mail-iy0-f172.google.com ([209.85.210.172]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Pqtqd-0007uz-Uf for roll@ietf.org; Sat, 19 Feb 2011 12:56:12 -0800 Received: by iym1 with SMTP id 1so5008411iym.31 for ; Sat, 19 Feb 2011 12:56:11 -0800 (PST) Received: by 10.231.30.75 with SMTP id t11mr1657060ibc.91.1298148971112; Sat, 19 Feb 2011 12:56:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.59.15 with HTTP; Sat, 19 Feb 2011 12:55:51 -0800 (PST) In-Reply-To: <20110219200523.GA8481@devl.org> References: <20110219190349.GA7777@devl.org> <20110219192436.GA7956@devl.org> <20110219200523.GA8481@devl.org> From: Omprakash Gnawali Date: Sat, 19 Feb 2011 12:55:51 -0800 Message-ID: To: Mariano Alvira Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 2c238adc2661b13b123d68c6db09dced Cc: ROLL WG Subject: Re: [Roll] what link/routing metrics are people using with RPL? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 20:55:36 -0000 On Sat, Feb 19, 2011 at 12:05 PM, Mariano Alvira wrote: > On Sat, Feb 19, 2011 at 11:46:29AM -0800, Philip Levis wrote: >> >> >> But generally you want a protocol to do better than "not terrible" and be more dependable than "mostly." >> > > Yes definitely! Although part of that is to also make these radios > work better than "not terrible" and more dependable than "mostly" --- > which can take quite an effort. But I'm glad; from what you are saying > it sounds like the time I'm investing now in autoacking will lead to > major benefits from all the layers. Good to hear you are considering implementing RPL based on ETX metric. It will be great if you could read the MRHOF draft and let me know if there is something confusing from an implementer's perspective. Also, if you would implement ETX routing differently, that is a good feedback as well. Here is the link to the current draft: http://tools.ietf.org/html/draft-gnawali-roll-minrank-hysteresis-of-02 Thanks. - om_p From gnawali@cs.stanford.edu Sat Feb 19 15:14:19 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35FA3A6F4B for ; Sat, 19 Feb 2011 15:14:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WiU8riHaScnL for ; Sat, 19 Feb 2011 15:14:18 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id E21F93A6CFD for ; Sat, 19 Feb 2011 15:14:18 -0800 (PST) Received: from mail-iy0-f172.google.com ([209.85.210.172]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Pqw0u-0002SO-07 for roll@ietf.org; Sat, 19 Feb 2011 15:14:56 -0800 Received: by iym1 with SMTP id 1so5074667iym.31 for ; Sat, 19 Feb 2011 15:14:55 -0800 (PST) Received: by 10.231.16.67 with SMTP id n3mr1735799iba.66.1298157295175; Sat, 19 Feb 2011 15:14:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.59.15 with HTTP; Sat, 19 Feb 2011 15:14:35 -0800 (PST) In-Reply-To: References: <20110219190349.GA7777@devl.org> <20110219192436.GA7956@devl.org> <20110219200523.GA8481@devl.org> From: Omprakash Gnawali Date: Sat, 19 Feb 2011 15:14:35 -0800 Message-ID: To: Mariano Alvira Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: f219e97bb238ccbb8ed40879dafdba3c Cc: ROLL WG Subject: Re: [Roll] what link/routing metrics are people using with RPL? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Feb 2011 23:14:19 -0000 On Sat, Feb 19, 2011 at 12:55 PM, Omprakash Gnawali wrote: > On Sat, Feb 19, 2011 at 12:05 PM, Mariano Alvira wrote: >> On Sat, Feb 19, 2011 at 11:46:29AM -0800, Philip Levis wrote: >>> >>> >>> But generally you want a protocol to do better than "not terrible" and be more dependable than "mostly." >>> >> >> Yes definitely! Although part of that is to also make these radios >> work better than "not terrible" and more dependable than "mostly" --- >> which can take quite an effort. But I'm glad; from what you are saying >> it sounds like the time I'm investing now in autoacking will lead to >> major benefits from all the layers. > > Good to hear you are considering implementing RPL based on ETX metric. > It will be great if you could read the MRHOF draft and let me know if > there is something confusing from an implementer's perspective. Also, > if you would implement ETX routing differently, that is a good > feedback as well. > > Here is the link to the current draft: > http://tools.ietf.org/html/draft-gnawali-roll-minrank-hysteresis-of-02 The correct link is this one: http://tools.ietf.org/id/draft-ietf-roll-minrank-hysteresis-of-00.txt Sorry about that. - om_p From richard.kelsey@ember.com Mon Feb 21 07:01:28 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC6653A7122 for ; Mon, 21 Feb 2011 07:01:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFNITt-uFuDd for ; Mon, 21 Feb 2011 07:01:27 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 00AD93A711D for ; Mon, 21 Feb 2011 07:01:26 -0800 (PST) Received: from kelsey-ws.hq.ember.com ([192.168.81.93]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Feb 2011 10:02:02 -0500 Date: Mon, 21 Feb 2011 10:00:05 -0500 Message-Id: <87oc65qvpm.fsf@kelsey-ws.hq.ember.com> To: mar@devl.org In-reply-to: (message from Philip Levis on Sat, 19 Feb 2011 11:46:29 -0800) From: Richard Kelsey References: <20110219190349.GA7777@devl.org> <20110219192436.GA7956@devl.org> X-OriginalArrivalTime: 21 Feb 2011 15:02:03.0207 (UTC) FILETIME=[4C37FD70:01CBD1D8] Cc: roll@ietf.org Subject: Re: [Roll] what link/routing metrics are people using with RPL? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 15:01:28 -0000 On Feb 19, 2011, at 11:24 AM, Mariano Alvira wrote: > I should clarify that my main interest at the time was that it was > much easier to implement an LQI based metric rather that to get the > 802.15.4 autoacks working on the mc13224v. But now that I have that > working, I suppose it doesn't make much difference to me. Which metric you use and how you determine the values are two different things. There's nothing wrong with using LQI values to estimate ETX. For example, you may need a a value for a link which hasn't seen much traffic. Or you may not have 802.15.4 autoacks working :-). -Richard Kelsey From gnawali@cs.stanford.edu Mon Feb 21 14:16:06 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 46C193A717E for ; Mon, 21 Feb 2011 14:16:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gZDBn8A4p-y3 for ; Mon, 21 Feb 2011 14:16:05 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id A8FDD3A717A for ; Mon, 21 Feb 2011 14:16:03 -0800 (PST) Received: from mail-iy0-f172.google.com ([209.85.210.172]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Pre3i-00012S-1H for roll@ietf.org; Mon, 21 Feb 2011 14:16:46 -0800 Received: by iyj8 with SMTP id 8so1150615iyj.31 for ; Mon, 21 Feb 2011 14:16:45 -0800 (PST) Received: by 10.42.218.6 with SMTP id ho6mr2647734icb.1.1298326605106; Mon, 21 Feb 2011 14:16:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.59.15 with HTTP; Mon, 21 Feb 2011 14:16:25 -0800 (PST) In-Reply-To: <20110221221135.082AE3A7153@core3.amsl.com> References: <20110221221135.082AE3A7153@core3.amsl.com> From: Omprakash Gnawali Date: Mon, 21 Feb 2011 14:16:25 -0800 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: f9929892efd47015c544d6ca2fb551e9 Subject: [Roll] Fwd: New Version Notification for draft-gnawali-roll-rpl-recommendations-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Feb 2011 22:16:06 -0000 In the discussion just a few days ago on route poisoning, we felt the need for a draft that discusses various guidelines for efficient implementation of RPL. I just posted a beginning of a draft. Here is the link: http://www.ietf.org/id/draft-gnawali-roll-rpl-recommendations-00.txt Comments, discussions, and contributions welcome. - om_p ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Mon, Feb 21, 2011 at 2:11 PM Subject: New Version Notification for draft-gnawali-roll-rpl-recommendations-00 To: gnawali@cs.stanford.edu Cc: pal@cs.stanford.edu A new version of I-D, draft-gnawali-roll-rpl-recommendations-00.txt has been successfully submitted by Omprakash Gnawali and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-gnawali-roll-rpl-recommendations Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 Recommendations for Efficient Implementation of = RPL Creation_date: =A0 2011-02-21 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 6 Abstract: RPL is a flexible routing protocol applicable to a wide range of Low Power and Lossy Networks. =A0To enable this wide applicability, RPL provides many configuration options and gives implementers choices on how to implement various components of RPL. =A0Drawing on our experiences, we distill the design choices and configuration parameters that lead to efficient RPL implementations and operations. The IETF Secretariat. From Internet-Drafts@ietf.org Mon Feb 21 22:30:07 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 002CC3A67E5; Mon, 21 Feb 2011 22:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.627 X-Spam-Level: X-Spam-Status: No, score=-102.627 tagged_above=-999 required=5 tests=[AWL=-0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LERG01X+9Z44; Mon, 21 Feb 2011 22:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4229A3A67A4; Mon, 21 Feb 2011 22:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110222063002.23947.43231.idtracker@localhost> Date: Mon, 21 Feb 2011 22:30:02 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-18.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 06:30:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, et al. Filename : draft-ietf-roll-routing-metrics-18.txt Pages : 30 Date : 2011-02-21 Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing for Low Power and lossy networks (RPL) routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-18.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-routing-metrics-18.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-21221800.I-D@ietf.org> --NextPart-- From joakime@sics.se Mon Feb 21 23:39:29 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7585D3A6840 for ; Mon, 21 Feb 2011 23:39:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H1eaBX+S9PHg for ; Mon, 21 Feb 2011 23:39:28 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 302873A6811 for ; Mon, 21 Feb 2011 23:39:28 -0800 (PST) Received: from [192.168.1.6] (c-8215e455.013-276-73746f7.cust.bredbandsbolaget.se [85.228.21.130]) (Authenticated sender: joakime@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 9A18E40ADE; Tue, 22 Feb 2011 08:40:10 +0100 (CET) Message-ID: <4D63685C.5050003@sics.se> Date: Tue, 22 Feb 2011 08:40:12 +0100 From: Joakim Eriksson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: roll@ietf.org References: <20110222063002.23947.43231.idtracker@localhost> In-Reply-To: <20110222063002.23947.43231.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action:draft-ietf-roll-routing-metrics-18.txt - ETX inconsitency! X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 07:39:29 -0000 Ok - sorry for spamming but the same ETX inconsistency is here in this version also (8 vs 16 bits). Early in the section it is specified: "Each ETX sub-object has a fixed length of 8 bits" But just below there is a figure and a text explaining that it is 16 bits: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ETX | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: ETX sub-object format ETX: 16 bits. The ETX * 128 is encoded using 16 bits in unsigned integer format, rounded off to the nearest whole number. Best regards, -- Joakim Eriksson, SICS Internet-Drafts@ietf.org skrev 2011-02-22 07:30: > 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 : Routing Metrics used for Path Calculation in Low Power and Lossy Networks > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-roll-routing-metrics-18.txt > Pages : 30 > Date : 2011-02-21 > > Low power and Lossy Networks (LLNs) have unique characteristics > compared with traditional wired and ad-hoc networks that require the > specification of new routing metrics and constraints. By contrast > with typical Interior Gateway Protocol (IGP) routing metrics using > hop counts or link metrics, this document specifies a set of link and > node routing metrics and constraints suitable to LLNs to be used by > the Routing for Low Power and lossy networks (RPL) routing protocol. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-18.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Tue Feb 22 00:03:36 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 361553A6811 for ; Tue, 22 Feb 2011 00:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.366 X-Spam-Level: X-Spam-Status: No, score=-110.366 tagged_above=-999 required=5 tests=[AWL=0.232, 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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lO2GrKyiu0r6 for ; Tue, 22 Feb 2011 00:03:35 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3CA473A6809 for ; Tue, 22 Feb 2011 00:03:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=1289; q=dns/txt; s=iport; t=1298361859; x=1299571459; h=from:subject:date:message-id:to:mime-version; bh=hdEz4Fb0+cKO/7ZWEDFC2FDJ0ezo8p+TcWMsfyaYWmw=; b=e6o/NM0KukbR/fRzwlPDvr4yzxr8M0tW/Wc+JMhE0owTm/ncfhoarADm z8EvVxdp0lSP+/0Gv7wijpD7mNuqimlV3EYY62+UvnXInTEA19iPqfIpB p67WLnnN6fYm6ZncLbSYBk78/ACtuTVZb3O4exdyPsoxnfSnHndqoAgQ0 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIX8Yk1AaMHG/2dsb2JhbACmQ3Ofb5tdhV4EjBODOwY X-IronPort-AV: E=Sophos;i="4.62,206,1297036800"; d="scan'208,217";a="663637312" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 22 Feb 2011 08:04:18 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1M84D5v014145 for ; Tue, 22 Feb 2011 08:04:17 GMT Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Feb 2011 16:03:17 +0800 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Feb 2011 16:03:15 +0800 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-639-79528811 Date: Tue, 22 Feb 2011 09:03:12 +0100 Message-Id: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 22 Feb 2011 08:03:15.0626 (UTC) FILETIME=[F56D28A0:01CBD266] Subject: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 08:03:36 -0000 --Apple-Mail-639-79528811 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, This document has been stable for quite some time and the latest = revision has addressed all comments received so far. This starts a = 2-week Working Group Last call on draft-ietf-roll-of0-05, that will end = on March 8 at noon ET. Please send your comments to the authors and copy the mailing list. Thanks. JP. --Apple-Mail-639-79528811 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Dear all,

This document has been stable for quite some time and the latest revision has addressed all comments received so far. This starts a 2-week Working Group Last call on draft-ietf-roll-of0-05, that will end on March 8 at noon ET.

Please send your comments to the authors and copy the mailing list.

Thanks.

JP.

--Apple-Mail-639-79528811-- From ulrich@herberg.name Tue Feb 22 01:16:13 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA89C3A67AF for ; Tue, 22 Feb 2011 01:16:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.477 X-Spam-Level: X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVxAs4mBqb8H for ; Tue, 22 Feb 2011 01:16:12 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 4FDDC3A65A6 for ; Tue, 22 Feb 2011 01:16:12 -0800 (PST) Received: by vxa40 with SMTP id 40so1054922vxa.31 for ; Tue, 22 Feb 2011 01:16:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=XuSegHpwK3kCW4qj4x7Bf5qqk38QUgO2hFw315wtocY=; b=qv9Z51LBfHT5erb1Pvh/DTX0Zz8kSLg0ubVN8hNhe3VJwXOQwhOltgsO5mLKC+3B+Y h0Bt+k8mrdI1kxUQ9micMFeEYKbMQUCf/zzMXQeL+KbdDd0eTZnq8XEEKytHk1+MtHGW SuseiqT268W6rMeYMQrY2ny9gIjAayHpPTrw4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JL8sUXgQR5Ba7DHhAUeYLn/YOdIO0OotOXt9C+9hwPs/IzXRDeFD4X3S4TVV8bfg0L xaPoa9FcM8TbY8rEZiDeIU2nNAuNXPBbaUWgSDne9aNBq8IU2MRXJXZzJ5H2+0ySjoOC 7DRN+Q8it5DuCEiGe9seezH6dgvXuryQj7MLM= MIME-Version: 1.0 Received: by 10.220.62.69 with SMTP id w5mr219189vch.64.1298366215276; Tue, 22 Feb 2011 01:16:55 -0800 (PST) Received: by 10.220.188.68 with HTTP; Tue, 22 Feb 2011 01:16:55 -0800 (PST) In-Reply-To: References: <20110221221135.082AE3A7153@core3.amsl.com> Date: Tue, 22 Feb 2011 10:16:55 +0100 Message-ID: From: Ulrich Herberg To: Omprakash Gnawali Content-Type: multipart/alternative; boundary=e0cb4e8878e50cca59049cdb7141 Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-gnawali-roll-rpl-recommendations-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 09:16:13 -0000 --e0cb4e8878e50cca59049cdb7141 Content-Type: text/plain; charset=ISO-8859-1 Thanks for that draft. I think that these are useful indications; still, I think that some of the recommendations are actually fixing missing specifications in the RPL draft, and should be part of RPL, not of an additional draft. About item 5 and 7, one might add the caveat that they may lead to (i) a higher delay, which may not be acceptable in all applications (e.g. home automation, light switch!) and (ii) possible loss of data if the node has not enough capacity to buffer the data packets. Since RPL is supposed to run on extremely constrained devices, the latter seems possible. In item 5, it could be worth explaining why poisoning does not avoid loops, maybe with an example. Moreover, one could add a section explaining how to reduce the probability of loops when poisoning (e.g. by waiting some time before processing any DIO messages). I also think it could be worth giving some recommendations on how (or better *when*) to send DAO and DAOACK messages (see my previous emails on that matter). Ulrich On Mon, Feb 21, 2011 at 11:16 PM, Omprakash Gnawali wrote: > In the discussion just a few days ago on route poisoning, we felt the > need for a draft that discusses various guidelines for efficient > implementation of RPL. I just posted a beginning of a draft. Here is > the link: > > http://www.ietf.org/id/draft-gnawali-roll-rpl-recommendations-00.txt > > Comments, discussions, and contributions welcome. > > - om_p > > ---------- Forwarded message ---------- > From: IETF I-D Submission Tool > Date: Mon, Feb 21, 2011 at 2:11 PM > Subject: New Version Notification for > draft-gnawali-roll-rpl-recommendations-00 > To: gnawali@cs.stanford.edu > Cc: pal@cs.stanford.edu > > > > A new version of I-D, draft-gnawali-roll-rpl-recommendations-00.txt > has been successfully submitted by Omprakash Gnawali and posted to the > IETF repository. > > Filename: draft-gnawali-roll-rpl-recommendations > Revision: 00 > Title: Recommendations for Efficient Implementation of RPL > Creation_date: 2011-02-21 > WG ID: Independent Submission > Number_of_pages: 6 > > Abstract: > RPL is a flexible routing protocol applicable to a wide range of Low > Power and Lossy Networks. To enable this wide applicability, RPL > provides many configuration options and gives implementers choices on > how to implement various components of RPL. Drawing on our > experiences, we distill the design choices and configuration > parameters that lead to efficient RPL implementations and operations. > > > > The IETF Secretariat. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --e0cb4e8878e50cca59049cdb7141 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks for that draft. I think that these are useful indications; still, I = think that some of the recommendations are actually fixing missing specific= ations in the RPL draft, and should be part of RPL, not of an additional dr= aft.

About item 5 and 7, one might add the caveat that they may lead to (i) = a higher delay, which may not be acceptable in all applications (e.g. home = automation, light switch!) and (ii) possible loss of data if the node has n= ot enough capacity to buffer the data packets. Since RPL is supposed to run= on extremely constrained devices, the latter seems possible.

In item 5, it could be worth explaining why poisoning does not avoid lo= ops, maybe with an example. Moreover, one could add a section explaining ho= w to reduce the probability of loops when poisoning (e.g. by waiting some t= ime before processing any DIO messages).

I also think it could be worth giving some recommendations on how (or b= etter *when*) to send DAO and DAOACK messages (see my previous emails on th= at matter).

Ulrich

On Mon, Feb 21,= 2011 at 11:16 PM, Omprakash Gnawali <gnawali@cs.stanford.edu> wrote:
In the discussion= just a few days ago on route poisoning, we felt the
need for a draft that discusses various guidelines for efficient
implementation of RPL. I just posted a beginning of a draft. Here is
the link:

http://www.ietf.org/id/draft-gnawali-roll-rpl-recom= mendations-00.txt

Comments, discussions, and contributions welcome.

- om_p

---------- Forwarded message ----------
From: IETF I-D Submission Tool <idsubmission@ietf.org>
Date: Mon, Feb 21, 2011 at 2:11 PM
Subject: New Version Notification for
draft-gnawali-roll-rpl-recommendations-00
To: gnawali@cs.stanford.edu<= br> Cc: pal@cs.stanford.edu



A new version of I-D, draft-gnawali-roll-rpl-recommendations-00.txt
has been successfully submitted by Omprakash Gnawali and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-gnawali-roll-rpl-recommendations
Revision: =A0 =A0 =A0 =A000
Title: =A0 =A0 =A0 =A0 =A0 Recommendations for Efficient Implementation of = RPL
Creation_date: =A0 2011-02-21
WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission
Number_of_pages: 6

Abstract:
RPL is a flexible routing protocol applicable to a wide range of Low
Power and Lossy Networks. =A0To enable this wide applicability, RPL
provides many configuration options and gives implementers choices on
how to implement various components of RPL. =A0Drawing on our
experiences, we distill the design choices and configuration
parameters that lead to efficient RPL implementations and operations.



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

--e0cb4e8878e50cca59049cdb7141-- From pal@cs.stanford.edu Tue Feb 22 09:04:59 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19F193A6924 for ; Tue, 22 Feb 2011 09:04:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id usIloX4SYi6G for ; Tue, 22 Feb 2011 09:04:58 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 430023A68DC for ; Tue, 22 Feb 2011 09:04:58 -0800 (PST) Received: from [50.12.161.7] (helo=50-12-161-7.sfo.clearwire-wmx.net) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PrvgE-0001nH-5G; Tue, 22 Feb 2011 09:05:43 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> Date: Tue, 22 Feb 2011 09:05:09 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7E5FAC28-5607-4C5B-BD81-602E9C4F29DF@cs.stanford.edu> References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> To: JP Vasseur , "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 06ac0f501ed97ee7d2a3c5af22b79f06 Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 17:04:59 -0000 On Feb 22, 2011, at 12:03 AM, JP Vasseur wrote: > Dear all, >=20 > This document has been stable for quite some time and the latest = revision has addressed all comments received so far. This starts a = 2-week Working Group Last call on draft-ietf-roll-of0-05, that will end = on March 8 at noon ET. >=20 > Please send your comments to the authors and copy the mailing list. 5 comments (some just grammatical, some significant) 1. "the Objective Function selects the DODAG" -> "An Objective Function = selects the DODAG" 2. "OF0 uses a MinHopRankIncrease of 0x100 so that Rank value can be = stored in one octet. This allows up to at least 16 hops when each hop = has the worst Rank Increment of 16." - This worries me. It means that networks with incompatible OFs, or = which have to go to the last resort OF, have a maximum hopcount of 16. = I'd recommend that instead the worst Rank increment be made smaller, in = order to support more hops. E.g., 4/64. When we built CTP we made sure = it could support more than 16 hops because there were established = deployments which were > 32 hops (e.g., the network measuring the Golden = Gate Bridge). Is there any basis for this particular breakdown? Are we = really going to go back to RIP? Putting the reasoning in the document = isn't a good idea, but I'd like to know what it is so I can feel = comfortable with it. 3. "It MAY stretch its step of Rank " -> "A node MAY stretch its step of = Rank" 4. " o The preferred parent MUST be ignored. o A Router that is not in the same DODAG as the preferred parent, either in the current or a subsequent iteration, MUST be ignored." - I'd suggest writing these as "The backup next_hop MUST NOT be the = preferred parent" and "The backup next_hop MUST be in the same DODAG = iteration as the preferred parent." It's not 100% clear what "ignores" = means in this context. 5. " Trigger The OF0 support may trigger the RPL core to inform it = that a change occurred. This indicates whether the change requires a new DIO to be fired, trickle timers to be reset, etc..." - You probably don't want an ellipsis here. Phil From pthubert@cisco.com Tue Feb 22 10:05:49 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6C03A6957 for ; Tue, 22 Feb 2011 10:05:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZlkmqmSzJ3N3 for ; Tue, 22 Feb 2011 10:05:48 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B09BB3A6950 for ; Tue, 22 Feb 2011 10:05:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2923; q=dns/txt; s=iport; t=1298397993; x=1299607593; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ANzzhypDu3zYZe5iJoKJxLP0acXlSlZ70eydZ4urQDs=; b=gge4gjHJri74BGMQB/lxMYStZVTs32dyKKTnNajQ27Onp802xQQ7kGVp GlzBXXA4cBA/pJOurU2Bdj9LQy7UoQd6LWz+gf15Xjn1ssI2TPUlCfOVo 85dfzk6h+Xw4VZLlCVNF5/hYhl9LzeItY6xUI0UESEi2Kjo4cxp8Jqqi4 U=; X-IronPort-AV: E=Sophos;i="4.62,207,1297036800"; d="scan'208";a="77015426" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 22 Feb 2011 18:06:32 +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 p1MI6WPk005523; Tue, 22 Feb 2011 18:06:32 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Feb 2011 19:06:31 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 22 Feb 2011 19:06:28 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D03F02A07@XMB-AMS-107.cisco.com> In-Reply-To: <7E5FAC28-5607-4C5B-BD81-602E9C4F29DF@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working Last Call on draft-ietf-roll-of0-05 Thread-Index: AcvSssSdtGCnR0gbTxWUwmroFGswqAACC4hw References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> <7E5FAC28-5607-4C5B-BD81-602E9C4F29DF@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "JP Vasseur" X-OriginalArrivalTime: 22 Feb 2011 18:06:31.0986 (UTC) FILETIME=[3C236120:01CBD2BB] Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 18:05:49 -0000 Hi Phil: I'm clearly fine with the grammatical ones, thanks for this. For 2) I am also fine with your proposal, if no one present opposition, I'll do the change. For 5) I am not sure I understand you. Could you please rephrase? Thanks a bunch, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Tuesday, February 22, 2011 6:05 PM > To: JP Vasseur; Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 >=20 >=20 > On Feb 22, 2011, at 12:03 AM, JP Vasseur wrote: >=20 > > Dear all, > > > > This document has been stable for quite some time and the latest revision > has addressed all comments received so far. This starts a 2-week Working > Group Last call on draft-ietf-roll-of0-05, that will end on March 8 at noon ET. > > > > Please send your comments to the authors and copy the mailing list. >=20 > 5 comments (some just grammatical, some significant) >=20 > 1. "the Objective Function selects the DODAG" -> "An Objective Function > selects the DODAG" >=20 > 2. "OF0 uses a MinHopRankIncrease of 0x100 so that Rank value can be > stored in one octet. This allows up to at least 16 hops when each hop has the > worst Rank Increment of 16." >=20 > - This worries me. It means that networks with incompatible OFs, or which > have to go to the last resort OF, have a maximum hopcount of 16. I'd > recommend that instead the worst Rank increment be made smaller, in > order to support more hops. E.g., 4/64. When we built CTP we made sure it > could support more than 16 hops because there were established > deployments which were > 32 hops (e.g., the network measuring the Golden > Gate Bridge). Is there any basis for this particular breakdown? Are we really > going to go back to RIP? Putting the reasoning in the document isn't a good > idea, but I'd like to know what it is so I can feel comfortable with it. >=20 > 3. "It MAY stretch its step of Rank " -> "A node MAY stretch its step of Rank" >=20 > 4. " o The preferred parent MUST be ignored. >=20 > o A Router that is not in the same DODAG as the preferred parent, > either in the current or a subsequent iteration, MUST be ignored." >=20 > - I'd suggest writing these as "The backup next_hop MUST NOT be the > preferred parent" and "The backup next_hop MUST be in the same DODAG > iteration as the preferred parent." It's not 100% clear what "ignores" means > in this context. >=20 >=20 >=20 > 5. " Trigger The OF0 support may trigger the RPL core to inform it that > a change occurred. This indicates whether the change > requires a new DIO to be fired, trickle timers to be > reset, etc..." >=20 > - You probably don't want an ellipsis here. >=20 >=20 > Phil >=20 From pal@cs.stanford.edu Tue Feb 22 10:30:43 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4684D3A6974 for ; Tue, 22 Feb 2011 10:30:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iuh95TRdqkXK for ; Tue, 22 Feb 2011 10:30:42 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id B8F973A6973 for ; Tue, 22 Feb 2011 10:30:41 -0800 (PST) Received: from [50.12.161.7] (helo=50-12-161-7.sfo.clearwire-wmx.net) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Prx1B-00064a-AK; Tue, 22 Feb 2011 10:31:26 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D03F02A07@XMB-AMS-107.cisco.com> Date: Tue, 22 Feb 2011 10:31:23 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <305621B8-77DD-4D48-B4A8-20400060AC63@cs.stanford.edu> References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> <7E5FAC28-5607-4C5B-BD81-602E9C4F29DF@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D03F02A07@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: b64bce576883819501cf77c9371f4538 Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2011 18:30:43 -0000 On Feb 22, 2011, at 10:06 AM, Pascal Thubert (pthubert) wrote: > Hi Phil: >=20 > I'm clearly fine with the grammatical ones, thanks for this. >=20 > For 2) I am also fine with your proposal, if no one present = opposition, > I'll do the change. >=20 > For 5) I am not sure I understand you. Could you please rephrase? >>=20 >> 5. " Trigger The OF0 support may trigger the RPL core to inform > it that >> a change occurred. This indicates whether the change >> requires a new DIO to be fired, trickle timers to be >> reset, etc..." >>=20 >> - You probably don't want an ellipsis here. The ... is an ellipsis. An ellipsis is "the omission from speech or = writing of a word or words that are superfluous or able to be understood = from contextual clues." (OED) It's not really suitable to have in a = technical document. You should state exactly what should happen, not = leave it ambiguous to contextual clues. Phil= From prvs=0288fdd38=mukul@uwm.edu Tue Feb 22 20:57:00 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E03993A6814 for ; Tue, 22 Feb 2011 20:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmQgRlbqkMHC for ; Tue, 22 Feb 2011 20:57:00 -0800 (PST) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id D6C3D3A69E9 for ; Tue, 22 Feb 2011 20:56:59 -0800 (PST) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 22 Feb 2011 22:57:45 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 710E72B3EF5 for ; Tue, 22 Feb 2011 22:55:17 -0600 (CST) 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 Ox5kLwSeOy7l for ; Tue, 22 Feb 2011 22:55:17 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 1A3592B3EF3 for ; Tue, 22 Feb 2011 22:55:17 -0600 (CST) Date: Tue, 22 Feb 2011 22:57:45 -0600 (CST) From: Mukul Goyal To: roll Message-ID: <1238433981.133136.1298437065298.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <20110223045423.D56A53A69E9@core3.amsl.com> 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] Fwd: New Version Notification for draft-goyal-roll-defunct-dags-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 04:57:01 -0000 Hi all This draft describes a mechanism for an RPL node to identify defunct DAGs so that it can free up the memory being consumed by the state for such DAGs. Comments welcome. Regards Mukul ----- Forwarded Message ----- From: "IETF I-D Submission Tool" To: mukul@uwm.edu Cc: "Emmanuel Baccelli" , "jerald p martocci" Sent: Tuesday, February 22, 2011 10:54:23 PM Subject: New Version Notification for draft-goyal-roll-defunct-dags-00 A new version of I-D, draft-goyal-roll-defunct-dags-00.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository. Filename: draft-goyal-roll-defunct-dags Revision: 00 Title: Identifying Defunct DAGs in RPL Creation_date: 2011-02-23 WG ID: Independent Submission Number_of_pages: 9 Abstract: This document specifies a mechanism for an RPL node to identify defunct directed acyclic graphs. The IETF Secretariat. From prvs=0288fdd38=mukul@uwm.edu Tue Feb 22 21:42:43 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F70F3A6822 for ; Tue, 22 Feb 2011 21:42:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ZnJ-uXdmSHP for ; Tue, 22 Feb 2011 21:42:42 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 4E5D63A6804 for ; Tue, 22 Feb 2011 21:42:42 -0800 (PST) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 22 Feb 2011 23:43:27 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 7282C2B3F01 for ; Tue, 22 Feb 2011 23:40:59 -0600 (CST) 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 lioxHGUXVc7o for ; Tue, 22 Feb 2011 23:40:59 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 26B092B3EF3 for ; Tue, 22 Feb 2011 23:40:59 -0600 (CST) Date: Tue, 22 Feb 2011 23:43:27 -0600 (CST) From: Mukul Goyal To: roll Message-ID: <1544256582.134005.1298439807429.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <20110223053432.538F03A6997@core3.amsl.com> 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] Fwd: New Version Notification for draft-goyal-roll-metrics-direction-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 05:42:43 -0000 Hi all Some time back Richard Kelsey had suggested including a direction field inside the routing metric/constraint object headers (ticket #32). This issue was dropped at that time due to lack of interest: http://www.ietf.org/mail-archive/web/roll/current/msg04175.html The submitted draft revives the issue. A new draft is necessary since no more changes are possible in draft-ietf-roll-metrics itself. Comments welcome. Regards Mukul ----- Forwarded Message ----- From: "IETF I-D Submission Tool" To: mukul@uwm.edu Cc: "Emmanuel Baccelli" , "jerald p martocci" Sent: Tuesday, February 22, 2011 11:34:32 PM Subject: New Version Notification for draft-goyal-roll-metrics-direction-00 A new version of I-D, draft-goyal-roll-metrics-direction-00.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository. Filename: draft-goyal-roll-metrics-direction Revision: 00 Title: The Direction Field in Routing Metric/Constraint Objects Used in RPL Creation_date: 2011-02-23 WG ID: Independent Submission Number_of_pages: 6 Abstract: This document specifies a Direction field in the Routing Metric/ Constraint objects used in RPL operation in low power and lossy networks. The IETF Secretariat. From jpv@cisco.com Tue Feb 22 22:12:08 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 544BF3A6983 for ; Tue, 22 Feb 2011 22:12:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sju+zGcL-7lV for ; Tue, 22 Feb 2011 22:12:07 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 25C803A6862 for ; Tue, 22 Feb 2011 22:12:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=237; q=dns/txt; s=iport; t=1298441573; x=1299651173; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=zRzn4nRWLaWHqkkDuI07xaRwqWcselAvC9qnimjqTu8=; b=El0mpZRqgV3442WSXZ1T3hBySZhnuWdYptEPYBVqWRihVecRudokEm9a cRbKH934xdmjtt9WVIQe/BF+udJNyFZG2IL08SmKR7xFiet5KFFBShJFv 3xKKBmgFF0Bx429BlcAnT/N5jpIHyO7PLRzXpV27xAd1MF2DvNjzWfFqR U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADs0ZE2rRN+K/2dsb2JhbACmJnOhMptihV4EjBSDOwY X-IronPort-AV: E=Sophos;i="4.62,210,1297036800"; d="scan'208";a="264129884" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 23 Feb 2011 06:12:53 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p1N6Crra007348 for ; Wed, 23 Feb 2011 06:12:53 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); Tue, 22 Feb 2011 22:12:53 -0800 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Feb 2011 22:12:52 -0800 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 23 Feb 2011 07:12:51 +0100 Message-Id: To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 23 Feb 2011 06:12:52.0740 (UTC) FILETIME=[B44AB440:01CBD320] Subject: [Roll] ROLL WG Meeting in Pragues X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 06:12:08 -0000 Dear all, We'll start working on the agenda for our ROLL WG meeting in Prague. If = you would like to get a slot, please send me an email with the name of = the draft, requested slot duration and presenter name. Thanks. JP.= From nvt@sics.se Wed Feb 23 06:26:42 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A94983A68ED for ; Wed, 23 Feb 2011 06:26:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fs3iPfKcS3ym for ; Wed, 23 Feb 2011 06:26:41 -0800 (PST) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by core3.amsl.com (Postfix) with ESMTP id 7468E3A6A0D for ; Wed, 23 Feb 2011 06:26:41 -0800 (PST) Received: from [193.10.67.9] (conjecture.sics.se [193.10.67.9]) by letter.sics.se (Postfix) with ESMTP id 5D30B40C68 for ; Wed, 23 Feb 2011 15:27:27 +0100 (CET) Message-ID: <4D65194E.9070504@sics.se> Date: Wed, 23 Feb 2011 15:27:26 +0100 From: Nicolas Tsiftes User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; sv-SE; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: roll@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] comments on mrhof draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 14:26:42 -0000 Hello, I have a few comments after having implemented most of the functionality in this draft. In general, I think that this document would benefit from having some discussion regarding the choice of parameter values -- in particular the hysteresis threshold. Currently, the document just states that "The parameter values are assigned depending on the selected metric.". But it is unclear how these values should be assigned once we have selected a metric. It seems that selecting a suitable PARENT_SWITCH_THRESHOLD requires intricate knowledge of lower layers; e.g., how the link cost is calculated (if using an EWMA, what alpha value is used?) or what the physical layer is of the interface through which the parent is reachable. In addition, perhaps it should be recommended that these parameters be made configurable by the network administrator, who may be able to make a better decision for a particular network deployment. Section 1: "MRHOF can be used with additive metric" I think that stronger wording would be appropriate if additive metrics is the only metric type in consideration for this OF. Section 3.1: "However, long intervals between periodic computation or deferring the computation for too long after new metric advertisements or updates to the selected link metric prevents results in node making parent selection based on stale link and path information." Drop "prevents". The sentence is also somewhat complex. Would the following slightly shorter sentence preserve the meaning? "However, deferring the path cost computation for too long after new metric advertisements or updates to the selected link metric results in parent selection based on stale link and path information." Section 3.3: The conversion table does not apply to the node with ROOT_RANK, but this is not specified. It would be good if the initial path cost set by the root could be specified for each metric. Section 4 gives an example of the ETX MIN_PATH_COST where it is set to 0. Instead, I think that this would be more appropriate to have in the specification of the metrics themselves, i.e., draft-ietf-roll-routing-metrics. Node fanout: This element stands out in the list, because I haven't seen it specified in draft-ietf-roll-routing-metrics-17, which the others have been. Section 4: "Switch to a new path only if it is requires at least one fewer transmission than the current path." Drop "is". Nicolas Omprakash Gnawali skrev 2011-02-17 06:43: > Dear ROLL WG, > > I am in the process of updating the minimum rank with hysteresis > objective function draft. We had discussions related to needing to > bolster of0 (null metric of) with link qualities and the suggestion > was to just use mrhof(etx). It also turns out some people thought they > were implementing null metric OF but they were implementing > mrhof(etx). > > Here is a link to the draft: > http://tools.ietf.org/html/draft-gnawali-roll-minrank-hysteresis-of-02 > > This OF converts the metrics into rank using hard coded constants to > scale. If people got a chance to work on metric implementations and > use something like mrhof, it will be good to incorporate those > suggestions to improve the draft. > > I will appreciate your comments. > > Thanks. > > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Matteo.Paris@ember.com Wed Feb 23 13:33:23 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF723A6916 for ; Wed, 23 Feb 2011 13:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZMDT73n0BAow for ; Wed, 23 Feb 2011 13:33:22 -0800 (PST) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 0D22E3A68F6 for ; Wed, 23 Feb 2011 13:33:21 -0800 (PST) Received: from [192.168.81.46] ([192.168.81.46]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Feb 2011 16:34:08 -0500 Mime-Version: 1.0 Message-Id: Date: Wed, 23 Feb 2011 16:34:07 -0500 To: Omprakash Gnawali , ROLL WG From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 23 Feb 2011 21:34:08.0920 (UTC) FILETIME=[67766980:01CBD3A1] Subject: Re: [Roll] comments on mrhof draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2011 21:33:23 -0000 Hi Omprakash, thanks for your work on the mrhof draft. I have a few comments: In Parent Selection (3.2), what happens when the path cost corresponding to the new candidate preferred parent is greater than cur_min_path_cost? My reading is that it is selected as the new preferred parent, and cur_min_path_cost is increased accordingly. Is that correct? When I tested that strategy I ran into a frequent counting to infinity problem. I addressed the problem by adding a hysteresis factor in the upward direction, and always sending a DIS before increasing rank. I'd be happy to elaborate if you'd like. The draft does not discuss the parent set other than the preferred parent. Does it assume any neighbor with rank less than our rank (cur_min_path_cost in the case of ETX) is a parent? Perhaps it should mention this explicitly. When is parent selection re-computed? Section 3.2 says "After computing the path cost for all the candidate neighbors ... a node selects the preferred parent." I think a statement similar to the one in section 3.1 for re-computing path costs would be clearer, for example: "Parent selection should be re-computed each time (1) the path cost of an existing parent changes (2) a neighbor is added to or removed from the parent set." I think the draft would benefit from a discussion of ETX. There are many ways of actually measuring (estimating) ETX, each with tradeoffs. There are parameter settings such as window size, and averaging methodologies to consider. Implementers need to be aware of these issues. The roll-routing-metrics draft does not discuss them, so the OF draft seems like a good place. Thanks, Matteo At 9:43 PM -0800 2/16/11, Omprakash Gnawali wrote: >Dear ROLL WG, > >I am in the process of updating the minimum rank with hysteresis >objective function draft. We had discussions related to needing to >bolster of0 (null metric of) with link qualities and the suggestion >was to just use mrhof(etx). It also turns out some people thought they >were implementing null metric OF but they were implementing >mrhof(etx). > >Here is a link to the draft: >http://tools.ietf.org/html/draft-gnawali-roll-minrank-hysteresis-of-02 > >This OF converts the metrics into rank using hard coded constants to >scale. If people got a chance to work on metric implementations and >use something like mrhof, it will be good to incorporate those >suggestions to improve the draft. > >I will appreciate your comments. > >Thanks. > >- om_p >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From cabo@tzi.org Thu Feb 24 22:27:59 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8919A3A6821; Thu, 24 Feb 2011 22:27:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GlSJKZra2f0; Thu, 24 Feb 2011 22:27:50 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by core3.amsl.com (Postfix) with ESMTP id 2DC9B3A692F; Thu, 24 Feb 2011 22:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id p1P6STco020683; Fri, 25 Feb 2011 07:28:29 +0100 (CET) Received: from [192.168.217.101] (p5489EAE5.dip.t-dialin.net [84.137.234.229]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B769E22D; Fri, 25 Feb 2011 07:28:28 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Feb 2011 07:29:28 +0100 To: 6lowpan 6lowpan <6lowpan@ietf.org>, "core@ietf.org WG" , roll WG , lwip@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [Roll] IETF 80: Constrained Node/Network cluster in Prague X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 06:27:59 -0000 The DRAFT agenda is out, and so far the WG meetings in the Constrained Node/Network cluster have been scheduled in a very US/jetlag friendly way :-) Note that these dates and times are subject to change -- don't plan travel relying on them. And, if you are registered, remember to plan for the tutorial day on "Interconnecting Smart Objects with the Internet" we have scheduled for the Saturday leading up to IETF 80. Gruesse, Carsten Saturday, March 26, 2011: 0830-1900 http://www.iab.org/about/workshops/smartobjects/tutorial.html MONDAY, March 28, 2011 1300-1500 Afternoon Session I Congress Hall II APP core Constrained RESTful Environments WG 1510-1610 Afternoon Session II Barcelona INT lwig Light-Weight Implementation Guidance TUESDAY, March 29, 2011 1520-1700 Afternoon Session II Congress Hall I INT 6lowpan IPv6 over Low power WPAN WG WEDNESDAY, March 30, 2011 1510-1610 Afternoon Session II Roma APP core Constrained RESTful Environments WG THURSDAY, March 31, 2011 1520-1720 Afternoon Session II Congress Hall III RTG roll Routing Over Low power and Lossy = networks WG From gnawali@cs.stanford.edu Fri Feb 25 01:14:31 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E585B3A67B4 for ; Fri, 25 Feb 2011 01:14:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R-wVCZHPciRZ for ; Fri, 25 Feb 2011 01:14:31 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 2205D3A67A7 for ; Fri, 25 Feb 2011 01:14:31 -0800 (PST) Received: from mail-iw0-f172.google.com ([209.85.214.172]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Pstli-0008PE-U6 for roll@ietf.org; Fri, 25 Feb 2011 01:15:23 -0800 Received: by iwl42 with SMTP id 42so1044365iwl.31 for ; Fri, 25 Feb 2011 01:15:22 -0800 (PST) Received: by 10.43.48.7 with SMTP id uu7mr509256icb.68.1298625322108; Fri, 25 Feb 2011 01:15:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.59.15 with HTTP; Fri, 25 Feb 2011 01:15:02 -0800 (PST) In-Reply-To: <4D65194E.9070504@sics.se> References: <4D65194E.9070504@sics.se> From: Omprakash Gnawali Date: Fri, 25 Feb 2011 01:15:02 -0800 Message-ID: To: Nicolas Tsiftes Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: d3e02c565cd5ac634b2ff74b6ba3e13d Cc: roll@ietf.org Subject: Re: [Roll] comments on mrhof draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 09:14:32 -0000 Thanks for the comments. Some notes inline. On Wed, Feb 23, 2011 at 6:27 AM, Nicolas Tsiftes wrote: > Hello, > > I have a few comments after having implemented most of the functionality > in this draft. In general, I think that this document would benefit from > having some discussion regarding the choice of parameter values -- in > particular the hysteresis threshold. Currently, the document just states > that "The parameter values are assigned depending on the selected > metric.". But it is unclear how these values should be assigned once we > have selected a metric. It seems that selecting a suitable > PARENT_SWITCH_THRESHOLD requires intricate knowledge of lower layers; > e.g., how the link cost is calculated (if using an EWMA, what alpha > value is used?) or what the physical layer is of the interface through > which the parent is reachable. Not only that, it also depends on the degree to which you are willing to pay the cost of path change for incremental gains in path quality. If some of these issues raise questions about interoperability, and a reasonably efficient interoperation at that, I agree that it has to be in some draft. You seem to have hit upon this issue during your implementation, so if you want to share some examples, that will help. > In addition, perhaps it should be > recommended that these parameters be made configurable by the network > administrator, who may be able to make a better decision for a > particular network deployment. Do you mean runtime reconfiguration or configuration when we "program" the nodes? It would be hard to argue that the form is essential. > It would be good if the initial path cost set by the root could be > specified for each metric. Section 4 gives an example of the ETX > MIN_PATH_COST where it is set to 0. Instead, I think that this would be > more appropriate to have in the specification of the metrics > themselves, i.e., draft-ietf-roll-routing-metrics. I think the metrics draft is supposed to be general and not dictate the values to be used by specific OFs. That is probably why it does not talk about min cost for the metrics. I will incorporate the rest of your comments in the next version. - om_p From gnawali@cs.stanford.edu Fri Feb 25 01:26:47 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6CD73A6856 for ; Fri, 25 Feb 2011 01:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qywUUAHBtiJw for ; Fri, 25 Feb 2011 01:26:47 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 10EC23A67F3 for ; Fri, 25 Feb 2011 01:26:47 -0800 (PST) Received: from mail-iy0-f172.google.com ([209.85.210.172]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Pstxa-0004ks-TU for roll@ietf.org; Fri, 25 Feb 2011 01:27:39 -0800 Received: by iyj8 with SMTP id 8so844382iyj.31 for ; Fri, 25 Feb 2011 01:27:38 -0800 (PST) Received: by 10.42.218.6 with SMTP id ho6mr522387icb.1.1298626058081; Fri, 25 Feb 2011 01:27:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.59.15 with HTTP; Fri, 25 Feb 2011 01:27:18 -0800 (PST) In-Reply-To: References: From: Omprakash Gnawali Date: Fri, 25 Feb 2011 01:27:18 -0800 Message-ID: To: Matteo Paris Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 323acaff36744e8473855e70acc36bcb Cc: ROLL WG Subject: Re: [Roll] comments on mrhof draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 09:26:48 -0000 Thanks for the comments. Some notes inline. On Wed, Feb 23, 2011 at 1:34 PM, Matteo Paris wrote: > > Hi Omprakash, thanks for your work on the mrhof draft. =A0I have a few > comments: > > In Parent Selection (3.2), what happens when the path cost corresponding = to > the new candidate preferred parent is greater than cur_min_path_cost? =A0= My > reading is that it is selected as the new preferred parent, and > cur_min_path_cost is increased accordingly. =A0Is that correct? =A0When I= tested > that strategy I ran into a frequent counting to infinity problem. =A0I > addressed the problem by adding a hysteresis factor in the upward directi= on, > and always sending a DIS before increasing rank. =A0I'd be happy to elabo= rate > if you'd like. I would like more information. Parent switch threshold did not help? > The draft does not discuss the parent set other than the preferred parent= . > =A0Does it assume any neighbor with rank less than our rank (cur_min_path= _cost > in the case of ETX) is a parent? =A0Perhaps it should mention this explic= itly. Yes, potentially any node with a rank lower by at least the switching threshold is a parent. I can be more explicit about this. > When is parent selection re-computed? =A0Section 3.2 says "After computin= g the > path cost for all the candidate neighbors ... a node selects the preferre= d > parent." =A0I think a statement similar to the one in section 3.1 for > re-computing path costs would be clearer, for example: "Parent selection > should be re-computed each time (1) the path cost of an existing parent > changes (2) a neighbor is added to or removed from the parent set." Good suggestion. I will be explicit about when parent selection is triggered. We can describe the trigger saying after any path cost recompute, perform parent selection. I think that covers the same condition. > I think the draft would benefit from a discussion of ETX. =A0There are ma= ny > ways of actually measuring (estimating) ETX, each with tradeoffs. =A0Ther= e are > parameter settings such as window size, and averaging methodologies to > consider. =A0Implementers need to be aware of these issues. =A0The > roll-routing-metrics draft does not discuss them, so the OF draft seems l= ike > a good place. JP had a comment a while ago asking to limit the things that are not essential for interoperation so it does not include those discussions. Maybe, a good place for those discussions would be rpl-recommendations draft that I posted a few days ago? - om_p From gnawali@cs.stanford.edu Fri Feb 25 01:50:07 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E3063A6855 for ; Fri, 25 Feb 2011 01:50:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 49b4pQFmL4R3 for ; Fri, 25 Feb 2011 01:50:06 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 906613A6946 for ; Fri, 25 Feb 2011 01:50:06 -0800 (PST) Received: from mail-gy0-f172.google.com ([209.85.160.172]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1PsuKA-0001Ni-8t for roll@ietf.org; Fri, 25 Feb 2011 01:50:58 -0800 Received: by gyc15 with SMTP id 15so720719gyc.31 for ; Fri, 25 Feb 2011 01:50:57 -0800 (PST) Received: by 10.151.76.1 with SMTP id d1mr3258080ybl.368.1298627457199; Fri, 25 Feb 2011 01:50:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.192.3 with HTTP; Fri, 25 Feb 2011 01:50:37 -0800 (PST) In-Reply-To: References: <20110221221135.082AE3A7153@core3.amsl.com> From: Omprakash Gnawali Date: Fri, 25 Feb 2011 01:50:37 -0800 Message-ID: To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 2d1a4fa5d0150c38835749a59b44c419 Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-gnawali-roll-rpl-recommendations-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 09:50:07 -0000 Thanks for the comments. Some notes inline. On Tue, Feb 22, 2011 at 1:16 AM, Ulrich Herberg wrote: > Thanks for that draft. I think that these are useful indications; still, I > think that some of the recommendations are actually fixing missing > specifications in the RPL draft, and should be part of RPL, not of an > additional draft. > > About item 5 and 7, one might add the caveat that they may lead to (i) a > higher delay, which may not be acceptable in all applications (e.g. home > automation, light switch!) and (ii) possible loss of data if the node has > not enough capacity to buffer the data packets. Since RPL is supposed to run > on extremely constrained devices, the latter seems possible. Loop detection and repair latency is going to depend on a lot of factors. It is certainly possible to optimize for quick loop detection and repair without poisoning but it might cost on some other aspects of performance. For (7), I agree with what you are saying and I will incorporate your suggestion in the next revision. > In item 5, it could be worth explaining why poisoning does not avoid loops, > maybe with an example. Moreover, one could add a section explaining how to > reduce the probability of loops when poisoning (e.g. by waiting some time > before processing any DIO messages). I can work on it for next revision. > I also think it could be worth giving some recommendations on how (or better > *when*) to send DAO and DAOACK messages (see my previous emails on that > matter). I have seen your email. I think we need some experience before making a recommendation on this issue. If someone has input on this topic based on experiments/deployments etc., I am happy to incorporate the suggestion. - om_p From jpv@cisco.com Fri Feb 25 01:57:07 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAE8B3A6946 for ; Fri, 25 Feb 2011 01:57:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t4D32N+v9c1w for ; Fri, 25 Feb 2011 01:57:07 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B4A263A685B for ; Fri, 25 Feb 2011 01:57:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=185; q=dns/txt; s=iport; t=1298627879; x=1299837479; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=D78tr2JyQ010SzHKbOK8DAYrzqfXsj+wjlB/kSGh+U4=; b=C0B9U7xKSis8WHqnBe2pTZCL9uYRTlwLnIe2XBMiRGs5IdoVxtpb2Mv9 oE3WmZJUpqQpfSuzyky8BPgW4mv7D16gprZm78d+Jj04GUl0oTAhl8hkj F3MMKXZKbWZmA83Q/QDcjSpgq3zHbe2cokYObMVGqQqSivdG8G4WskXZL 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0EALoLZ02Q/khMgWdsb2JhbACmOhUBARYiJaElm2OFYASMHYNE X-IronPort-AV: E=Sophos;i="4.62,224,1297036800"; d="scan'208";a="77334688" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 25 Feb 2011 09:57:58 +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 p1P9vv9k026814 for ; Fri, 25 Feb 2011 09:57:58 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, 25 Feb 2011 10:57:58 +0100 Received: from ams-jvasseur-8913.cisco.com ([10.55.82.240]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 25 Feb 2011 10:57:57 +0100 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 25 Feb 2011 10:57:56 +0100 Message-Id: <7BE2AD49-71B8-48AA-A5EC-5D208CCFB69D@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 25 Feb 2011 09:57:57.0902 (UTC) FILETIME=[7AD262E0:01CBD4D2] Subject: [Roll] Draft Agenda ROLL WG IETF 80 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 09:57:08 -0000 Dear all, Please find the draft agenda for the ROLL WG IETF-80: = http://www.ietf.org/proceedings/80/agenda/roll.txt Please let me know if you have comments. Thanks. JP.= From iesg-secretary@ietf.org Fri Feb 25 13:53:56 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC5C03A6A5A; Fri, 25 Feb 2011 13:53:55 -0800 (PST) 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.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dH0XtGwPYq7; Fri, 25 Feb 2011 13:53:55 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E28FF3A6A60; Fri, 25 Feb 2011 13:53:52 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110225215352.29369.31344.idtracker@localhost> Date: Fri, 25 Feb 2011 13:53:52 -0800 Cc: roll mailing list , Internet Architecture Board , roll chair , RFC Editor Subject: [Roll] Protocol Action: 'Routing Metrics used for Path Calculation in Low Power and Lossy Networks' to Proposed Standard (draft-ietf-roll-routing-metrics-18.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2011 21:53:56 -0000 The IESG has approved the following document: - 'Routing Metrics used for Path Calculation in Low Power and Lossy Networks' (draft-ietf-roll-routing-metrics-18.txt) as a Proposed Standard This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-roll-routing-metrics/ Technical Summary Low power and Lossy Networks (LLNs) have specific routing characteristics compared with traditional wired or ad-hoc networks that have been spelled out in [RFC5548], [RFC5673], [RFC5826] and [RFC5867]. These involve selecting routes that optimize for particular metrics under non-trivial constraints. Historically, IGP such as OSPF ([RFC2328]) and IS-IS ([RFC1195]) have used quantitative static link metrics. Other mechanisms such as Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) (see [RFC2702] and [RFC3209]) make use of other link attributes such as the available reserved bandwidth (dynamic) or link affinities (most of the time static) to compute constrained shortest paths for Traffic Engineering Label Switched Paths (TE LSPs). This document specifies routing metrics and constraints to be used in path calculation by the Routing Protocol for Low Power and Lossy Networks (RPL) specified in [I-D.ietf-roll-rpl]. It propose a flexible mechanism for the advertisement of routing metrics and constraints used by RPL. Some RPL implementations may elect to adopt an extremely simple approach based on the use of a single metric with no constraint whereas other implementations may use a larger set of link and node routing metrics and constraints. This specification provides a high degree of flexibility and a set of routing metrics and constraints, including node state and attributes, node energy, hop-count, estimated transmission count, throughput, latency, link reliability, mode of operation, or generic 'color'. Extensions are anticipated should ew routing metrics and constraints be defined in the future. Working Group Summary No issues. It took several iterations before we had a solid technical document. Document Quality Good quality. It is basically defining a type representation, so implementation is trivial. Personnel David Culler (culler@eecs.berkeley.edu) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. From prvs=031ab4423=mukul@uwm.edu Sat Feb 26 11:24:27 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B435B3A67C1 for ; Sat, 26 Feb 2011 11:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCZxrgmrX91X for ; Sat, 26 Feb 2011 11:24:26 -0800 (PST) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id B50FA3A66B4 for ; Sat, 26 Feb 2011 11:24:26 -0800 (PST) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 26 Feb 2011 13:25:21 -0600 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 2C0D72B3EF5; Sat, 26 Feb 2011 13:22:51 -0600 (CST) 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 Z-44cuz9qCko; Sat, 26 Feb 2011 13:22:50 -0600 (CST) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id B6E922B3EF3; Sat, 26 Feb 2011 13:22:50 -0600 (CST) Date: Sat, 26 Feb 2011 13:25:21 -0600 (CST) From: Mukul Goyal To: Omprakash Gnawali Message-ID: <982630998.283233.1298748321255.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-gnawali-roll-rpl-recommendations-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 19:24:27 -0000 Hi Omprakash Could you also provide some guidelines regarding how to set the redundancy constant in trickle operation? Thanks Mukul ----- Original Message ----- From: "Omprakash Gnawali" To: "Ulrich Herberg" Cc: "ROLL WG" Sent: Friday, February 25, 2011 3:50:37 AM Subject: Re: [Roll] Fwd: New Version Notification for draft-gnawali-roll-rpl-recommendations-00 Thanks for the comments. Some notes inline. On Tue, Feb 22, 2011 at 1:16 AM, Ulrich Herberg wrote: > Thanks for that draft. I think that these are useful indications; still, I > think that some of the recommendations are actually fixing missing > specifications in the RPL draft, and should be part of RPL, not of an > additional draft. > > About item 5 and 7, one might add the caveat that they may lead to (i) a > higher delay, which may not be acceptable in all applications (e.g. home > automation, light switch!) and (ii) possible loss of data if the node has > not enough capacity to buffer the data packets. Since RPL is supposed to run > on extremely constrained devices, the latter seems possible. Loop detection and repair latency is going to depend on a lot of factors. It is certainly possible to optimize for quick loop detection and repair without poisoning but it might cost on some other aspects of performance. For (7), I agree with what you are saying and I will incorporate your suggestion in the next revision. > In item 5, it could be worth explaining why poisoning does not avoid loops, > maybe with an example. Moreover, one could add a section explaining how to > reduce the probability of loops when poisoning (e.g. by waiting some time > before processing any DIO messages). I can work on it for next revision. > I also think it could be worth giving some recommendations on how (or better > *when*) to send DAO and DAOACK messages (see my previous emails on that > matter). I have seen your email. I think we need some experience before making a recommendation on this issue. If someone has input on this topic based on experiments/deployments etc., I am happy to incorporate the suggestion. - om_p _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From gnawali@cs.stanford.edu Mon Feb 28 16:40:56 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0E23A6D02 for ; Mon, 28 Feb 2011 16:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uG1JfTNb75RF for ; Mon, 28 Feb 2011 16:40:55 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 854613A6CB3 for ; Mon, 28 Feb 2011 16:40:55 -0800 (PST) Received: from mail-yw0-f44.google.com ([209.85.213.44]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1PuDf2-0006wt-Bx for roll@ietf.org; Mon, 28 Feb 2011 16:41:56 -0800 Received: by ywi6 with SMTP id 6so1698277ywi.31 for ; Mon, 28 Feb 2011 16:41:55 -0800 (PST) Received: by 10.150.168.4 with SMTP id q4mr7826639ybe.427.1298940115358; Mon, 28 Feb 2011 16:41:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.192.3 with HTTP; Mon, 28 Feb 2011 16:41:35 -0800 (PST) In-Reply-To: <20110301003318.9EA863A6CBA@core3.amsl.com> References: <20110301003318.9EA863A6CBA@core3.amsl.com> From: Omprakash Gnawali Date: Mon, 28 Feb 2011 16:41:35 -0800 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: d1b7ebe10773c68371983edd1a66f504 Subject: [Roll] Fwd: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 00:40:56 -0000 Updates based on the comments from the last couple weeks. Here are some main changes: - Mention that MRHOF *only* applies to additive metrics - Mention when parent selection should be done - Mention that the reason ETX-specific parameters are given is because we have the experience to suggest some parameters for that metric. Input from WG members who have suggestion for the parameter values for other metrics welcome. - Parent set - only the preferred parent in the parent set. From the perspective of this OF, the nodes do not narrow down the list of candidates to a smaller set and pick a node from that smaller set. I am open to suggestion on a different way to explain and think about the parent set. - om_p ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Mon, Feb 28, 2011 at 4:33 PM Subject: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-01 To: gnawali@cs.stanford.edu Cc: pal@cs.stanford.edu A new version of I-D, draft-ietf-roll-minrank-hysteresis-of-01.txt has been successfully submitted by Omprakash Gnawali and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-ietf-roll-minrank-hysteresis-of Revision: =A0 =A0 =A0 =A001 Title: =A0 =A0 =A0 =A0 =A0 The Minimum Rank Objective Function with Hystere= sis Creation_date: =A0 2011-02-28 WG ID: =A0 =A0 =A0 =A0 =A0 roll Number_of_pages: 9 Abstract: Hysteresis delays the effect of changes in link metric on parent selection. =A0Such delay makes the topology stable despite jitters in link metrics. =A0The Routing Protocol for Low Power and Lossy Networks (RPL) allows the use of objective functions to construct routes that optimize or constrain a routing metric on the paths. =A0This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that minimizes the node rank in terms of a given metric, while using hysteresis to prevent excessive rank churn. =A0The use of MRHOF with RPL results in nodes selecting stable paths that minimize the given routing metric to the roots of a Directed Acyclic Graph (DAG). The IETF Secretariat. From Internet-Drafts@ietf.org Mon Feb 28 16:45:02 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 72F0E3A6D09; Mon, 28 Feb 2011 16:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MSk+aZ0cRdP; Mon, 28 Feb 2011 16:45:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B59B73A6D0A; Mon, 28 Feb 2011 16:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110301004501.19628.50936.idtracker@localhost> Date: Mon, 28 Feb 2011 16:45:01 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-minrank-hysteresis-of-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 00:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : The Minimum Rank Objective Function with Hysteresis Author(s) : O. Gnawali, P. Levis Filename : draft-ietf-roll-minrank-hysteresis-of-01.txt Pages : 9 Date : 2011-02-28 Hysteresis delays the effect of changes in link metric on parent selection. Such delay makes the topology stable despite jitters in link metrics. The Routing Protocol for Low Power and Lossy Networks (RPL) allows the use of objective functions to construct routes that optimize or constrain a routing metric on the paths. This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that minimizes the node rank in terms of a given metric, while using hysteresis to prevent excessive rank churn. The use of MRHOF with RPL results in nodes selecting stable paths that minimize the given routing metric to the roots of a Directed Acyclic Graph (DAG). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-minrank-hysteresis-of-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-28163314.I-D@ietf.org> --NextPart--