From phoebus@ieee.org Fri Apr 1 07:46:05 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 E94CB3A6884 for ; Fri, 1 Apr 2011 07:46:05 -0700 (PDT) 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_SE=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 feWt5pBi6KiO for ; Fri, 1 Apr 2011 07:46:03 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id EAB043A6873 for ; Fri, 1 Apr 2011 07:46:02 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 5581A156EE6; Fri, 1 Apr 2011 16:47:12 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id f94DSgtun9pB; Fri, 1 Apr 2011 16:47:10 +0200 (CEST) X-KTH-Auth: phoebus [2001:6b0:1:12b0:223:dfff:fe92:5e5c] X-KTH-mail-from: phoebus@ieee.org Received: from dhcp-50-88.s3.kth.se (unknown [IPv6:2001:6b0:1:12b0:223:dfff:fe92:5e5c]) by smtp-1.sys.kth.se (Postfix) with ESMTP id CB604156B3E; Fri, 1 Apr 2011 16:47:08 +0200 (CEST) Message-ID: <4D95E56C.9070009@ieee.org> Date: Fri, 01 Apr 2011 16:47:08 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "roll@ietf.org" , Omprakash Gnawali , Philip Levis References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> In-Reply-To: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 14:46:06 -0000 JP, I suppose draft-ietf-roll-minrank-hysteresis-of-02 will be made available online soon? Or is this a last call regarding draft-ietf-roll-minrank-hysteresis-of-01? Omprakash and Phil, I made a pass through draft-ietf-roll-minrank-hysteresis-of-01. General Comments: ***************** 1) As I understand from Table 1 and the mention of node metrics in the second paragraph of the introduction, MRHOF also supports node metrics. However, in various places throughout the document, you refer to the "selected metric for the link..." . I point out where I spot this below. When using node metrics, I presume the node adds it's own node metric value to the advertised metric from its candidate neighbor to get the path cost? 2) In Section 3, you write "MRHOF cannot be used if the routing objective is to maximize the metric." Those from the optimization community may be a little puzzled, because you can just negate the objective function to convert it from a maximization problem to a minimization problem. Let's assume you wish to maximizing the product of link probabilities along a path. Then, you can use log(p) which results in only negative link metrics (so still monotonic). And instead of MIN_PATH_COST, you start with a MAX_PATH_REWARD of 0 and add the negative link metrics. I don't see any of the MRHOF mechanisms breaking here (with some minor tweaks of switching "minimize" to "maximize"). Am I missing something? As I understand, limiting MRHOF to minimization makes the explanations easier and the terminology / constant names more consistent. But are you restricting the scope of the OF too much here? 3) Are the parent selection rules in any way affected by minHopRankIncrease, mentioned in (draft-ietf-roll-rpl-19, Section 3.5.2. Rank Relationships)? Should minHopRankIncrease always be set to 1 for MRHOF? In Table 1, you discuss how to convert various metrics into rank, but make no mention of minHopRankIncrease. (draft-ietf-roll-rpl-19, Section 3.5.1 Rank Comparison (DAGRank()) ) says: "MinHopRankIncrease is the minimum increase in rank between a node and any of its DODAG parents." As I understand, PARENT_SWITCH_THRESHOLD plays the role of "coarsening" the metric, which was originally done by the DAGRank() function for rank comparisons. The way I understand the properties of rank described in (draft-ietf-roll-rpl-19, Section 3.5. Rank Properties) and from earlier discussions on the mailing list, coarsening the rank is for stability. DAGRank() may not do such a good job when two path-cost-to-root's advertised by candidate neighbors are less than PARENT_SWITCH_THRESHOLD apart but they result in different rank (e.g., DAGRank(A) > DAGRank(B)). This is why we have MRHOF, right? ************ Nits / editorial comments follow below, preceded by "PC>". Of course, don't forget to update the version numbers of the informative references for last call (or is this done after last call? I never remember.). -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus Networking Working Group O. Gnawali Internet-Draft P. Levis Intended status: Standards Track Stanford University Expires: September 1, 2011 February 28, 2011 The Minimum Rank Objective Function with Hysteresis draft-ietf-roll-minrank-hysteresis-of-01 Abstract 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). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 1, 2011. Copyright Notice Gnawali & Levis Expires September 1, 2011 [Page 1] Internet-Draft draft-ietf-roll-minrank-hysteresis-of February 2011 Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The Minimum Rank Objective Function with Hysteresis . . . . . . 4 3.1. Computing the Path cost . . . . . . . . . . . . . . . . . . 4 3.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . 5 3.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Advertising the path cost . . . . . . . . . . . . . . . . . 6 4. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . 7 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 8.2. Informative References . . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 Gnawali & Levis Expires September 1, 2011 [Page 2] Internet-Draft draft-ietf-roll-minrank-hysteresis-of February 2011 1. Introduction An objective function allows RPL [I-D.ietf-roll-rpl] to select paths that are best in terms of a given routing metric or select paths that meet certain constraints in terms of the routing metric. RPL achieves this goal by selecting the parent among the alternate parents as dictated by that objective function. For example, if an RPL instance uses an objective function that minimizes hop-count, RPL will select paths with minimum hop count. The nodes running RPL might use a number of metrics to describe a link or a node [I-D.ietf-roll-routing-metrics] and make it available for route selection. A metric can be used by different objective functions to optimize or constrain the metric in different ways. This specification describes MRHOF, an objective function for RPL. MRHOF uses hysteresis while selecting the path with the smallest metric value. The path with the minimum cost has different property PC> s/has different/has a different/ depending on the metric used for path selection. For example, the use of MRHOF with the latency metric allows RPL to find stable minimum-latency paths from the nodes to a root in the DAG instance. The use of MRHOF with the ETX metric allows RPL to find the stable minimum-ETX paths from the nodes to a root in the DAG instance. MRHOF can be used only with additive metric that must be minimized on PC> s/can be used only with additive/can only be used with an additive/ the paths selected for routing. Although MRHOF can be used with a number of metrics, this draft is based on experiences with the ETX PC> s/a number of metrics/different metrics/ metric. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This terminology used in this document is consistent with the terminologies described in [I-D.ietf-roll-terminology], [I-D.ietf-roll-rpl], and [I-D.ietf-roll-routing-metrics]. This document introduces two terms: Selected metric: The metric chosen by the network operator to use for path selection. This metric can be any additive metric listed in [I-D.ietf-roll-routing-metrics] PC> Insert period at end of sentence above. Gnawali & Levis Expires September 1, 2011 [Page 3] Internet-Draft draft-ietf-roll-minrank-hysteresis-of February 2011 Path cost: Path cost quantifies a property of an end-to-end path. Path cost is composed using the selected metric of the links along the path. Path cost can be used by RPL to compare different paths. PC> s/composed using the/obtained by summing up the/ 3. The Minimum Rank Objective Function with Hysteresis The Minimum Rank Objective Function with Hysteresis, MRHOF, is designed to find the paths with the smallest path cost while preventing excessive churn in the network. It does so by switching to the minimum cost path only if the path cost of the current path is larger than the path cost of the minimum cost path by a given threshold. MRHOF may be used with any additive metric listed in [I-D.ietf-roll-routing-metrics] as long the routing objective is to minimize the given routing metric. MRHOF cannot be used if the routing objective is to maximize the metric. 3.1. Computing the Path cost Nodes compute the path cost for each candidate neighbor reachable on all the interfaces. The Path cost represents the cost of the path, PC> When I read this sentence literally, it means that a candidate PC> neighbor must be reachable on ALL the interfaces. I don't think PC> that's what you mean. This is done at various places throughout PC> the document. May I suggest: PC> s/reachable on all the interfaces/that can be reached through an interface/ in terms of the selected metric, from a node to the root of the DODAG through the neighbor. Root nodes (Grounded or Floating) set the variable cur_min_path_cost to MIN_PATH_COST. A non-root node computes the path cost for a path to the root through each candidate neighbor by adding these two components: 1. The selected metric for the link to a candidate neighbor. 2. The value of the selected metric in the metric container in the DIO sent by that neighbor. A node SHOULD compute the path cost for the path through each candidate neighbor reachable through all the interfaces. If a node PC> Again, "reachable through all the interfaces". See comment above. cannot compute the path cost for the path through a candidate neighbor, the node MUST NOT select the candidate neighbor as its preferred parent with one exception. If the node does not have PC> s/parent with one/parent, with one/ metrics to compute the path cost through any of the candidate neighbors, it SHOULD join one of the candidate neighbors as a leaf node. If the selected metric of the link to a neighbor is not available, the path cost for the path through that neighbor SHOULD be set to MAX_PATH_COST. This cost value will prevent this path from being Gnawali & Levis Expires September 1, 2011 [Page 4] Internet-Draft draft-ietf-roll-minrank-hysteresis-of February 2011 considered for path selection. The path cost corresponding to a neighbor SHOULD be re-computed each time: 1. The selected metric of the link to the candidate neighbor is updated. 2. A node receives a new metric advertisement from the candidate neighbor. This computation MAY also be performed periodically. Deferring the path cost computation for too long after new metric advertisements or updates to the selected link metric results in nodes making parent selection decision based on stale link and path information. 3.2. Parent Selection After computing the path cost for all the candidate neighbors reachable through all the interfaces for the current DODAG iteration, a node selects the preferred parent. This process is called parent selection. Parent Selection SHOULD be performed each time: 1. The path cost for an existing candidate neighbor, including the preferred parent, changes. This condition can be checked immediately after the path cost is computed. 2. A new candidate neighbor is inserted into the neighbor table. The parent selection MAY be deferred until a later time. Deferring the parent selection can delay the use of better paths or stopping PC> s/stopping/stop/ the use of worse paths than what is available in the network. A node MUST select a candidate neighbor as its preferred parent if the path cost corresponding to that neighbor is smaller than the path cost corresponding to the rest of the neighbors, except as indicated below: 1. If the smallest path cost for paths through the candidate neighbors is smaller than cur_min_path_cost by less than PARENT_SWITCH_THRESHOLD, the node MAY continue to use the current preferred parent. 2. If there are multiple paths with the smallest path cost and that PC> remove "that" the smallest path cost is smaller than cur_min_path_cost by at least PARENT_SWITCH_THRESHOLD, a node MAY use a different objective function to select the preferred parent among the candidates which are first hop on the path with the minimum cost. PC> The last phrase is hard to parse, although it is correct. I'm not PC> sure how to reword it. Gnawali & Levis Expires September 1, 2011 [Page 5] Internet-Draft draft-ietf-roll-minrank-hysteresis-of February 2011 3. A node MAY declare itself as a Floating root, and hence no preferred parent, depending on the configuration. 4. If the selected metric for a link is greater than MAX_LINK_METRIC, the node SHOULD exclude that link from consideration for parent selection. 5. If cur_min_path_cost is greater than MAX_PATH_COST, the node MAY declare itself as a Floating root. 6. If the configuration disallows a node to be a Floating root and no neighbors are discovered, the node does not have a preferred parent, and MUST set cur_min_path_cost to MAX_PATH_COST. The preferred parent is the only node in the parent set at a given time. Any candidate neighbor may become the preferred parent as indicated above. 3.3. Computing Rank The DAG roots set their rank to MIN_PATH_COST for the selected metric. Once a non-root node selects its preferred parent, it can use the following table to covert its path cost to the DAG root through its preferred parent (written as Cost in the table) to its rank: +--------------------+------------+ | Node/link Metric | Rank | +--------------------+------------+ | Node Energy | 255 - Cost | | Hop-Count | Cost | | Latency | Cost/65536 | | Link Quality Level | Cost | | ETX | Cost | +--------------------+------------+ Table 1: Conversion of metric to rank. Node rank is undefined for these node/link metrics: Node state and attributes, throughput, and link color. 3.4. Advertising the path cost Once the preferred parent is selected, the node sets its cur_min_path_cost variable to the path cost corresponding to the preferred parent. Thus, cur_min_path_cost is the cost of the minimum cost path from the node to the root. The value of the Gnawali & Levis Expires September 1, 2011 [Page 6] Internet-Draft draft-ietf-roll-minrank-hysteresis-of February 2011 cur_min_path_cost is carried in the metric container whenever DIO messages are sent. 4. MRHOF Variables and Parameters MRHOF uses the following variable: cur_min_path_cost: The cost of the path from a node through its preferred parent to the root computed at the last parent selection. MRHOF uses the following parameters: MAX_LINK_METRIC: Maximum allowed value for the selected link metric for each link on the path. MAX_PATH_COST: Maximum allowed value for the path metric of a selected path. MIN_PATH_COST: The minimum allowed value for the path metric of the selected path. PARENT_SWITCH_THRESHOLD: The difference between metric of the path through the preferred parent and the minimum-metric path to trigger new preferred parent selection. PC> s/to trigger new preferred parent selection/in order to trigger the selection of a new preferred parent./ The parameter values are assigned depending on the selected metric. The best values for these parameters should be experimentally determined. The working group has long experience routing with the ETX metric. Based on those experiences, these ETX parameters are known to work in many settings: MAX_LINK_METRIC: 10. Disallow links with greater than 10 expected transmission count on the selected path. MAX_PATH_COST: 100. Disallow paths with greater than 100 expected transmission count. MIN_PATH_COST: 0. At root, the expected transmission count is 0. PARENT_SWITCH_THRESHOLD: 1.5. Switch to a new path only if it is expected to require at least 1.5 fewer transmission than the current path. Gnawali & Levis Expires September 1, 2011 [Page 7] Internet-Draft draft-ietf-roll-minrank-hysteresis-of February 2011 5. Acknowledgements Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur for their comments. 6. IANA Considerations This specification requires an allocated OCP. A value of 1 is requested. 7. Security Considerations Security considerations to be developed in accordance to the output of the WG. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.ietf-roll-routing-metrics] Vasseur, J. and D. Networks, "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", draft-ietf-roll-routing-metrics-01 (work in progress), October 2009. [I-D.ietf-roll-rpl] Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-05 (work in progress), December 2009. [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-01 (work in progress), May 2009. Gnawali & Levis Expires September 1, 2011 [Page 8] Internet-Draft draft-ietf-roll-minrank-hysteresis-of February 2011 Authors' Addresses Omprakash Gnawali Stanford University S255 Clark Center, 318 Campus Drive Stanford, CA 94305 USA Phone: +1 650 725 6086 Email: gnawali@cs.stanford.edu Philip Levis Stanford University 358 Gates Hall, Stanford University Stanford, CA 94305 USA Email: pal@cs.stanford.edu Gnawali & Levis Expires September 1, 2011 [Page 9] Html markup produced by rfcmarkup 1.92, available from http://tools.ietf.org/tools/rfcmarkup/ On 4/1/11 6:13 AM, JP Vasseur wrote: > Dear all, > > draft-ietf-roll-minrank-hysteresis-of has been discussed for quite some time, > the document is stable and is now ready for Working Group Last Call. As discussed > during the WG meeting yesterday, there a very questions to address. > > This starts a 2-week WG Last call on draft-ietf-roll-minrank-hysteresis-of-02 > that will end on April 11 at noon ET (this is a bit more than 2 weeks, considering > most of us flying back end of this week). > > Please send your comments to the authors and copy the mailing list. > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Fri Apr 1 07:50:55 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 B5D2128C0D0 for ; Fri, 1 Apr 2011 07:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.322 X-Spam-Level: X-Spam-Status: No, score=-110.322 tagged_above=-999 required=5 tests=[AWL=0.277, 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 deVUF1Ew0tjz for ; Fri, 1 Apr 2011 07:50:52 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3F1343A687B for ; Fri, 1 Apr 2011 07:50:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=24654; q=dns/txt; s=iport; t=1301669552; x=1302879152; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=nVWUTFC5ut7PjGHa33xKRDEpHluEaN4gk/LXgSaHV4U=; b=Mo1frDsuztx93+hNXv1+m9vbikKFZcR4jYGOkyoIiGaJ1gus3ntTmUcN BLmadRmMsHL8S+cvOP/QABxTIxuG9kjPMmwzI4YuVH16F7wQGioLFmxHD Iw3gmdPVDNxqy1Rm7i8ohZBS708Nd0t6Hu/dU51rCrprWBnZgKKVsAVOW Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAFXmlU2rRDoJ/2dsb2JhbAAupSl3iHmccpw+AoMVglQEjRuDWQY X-IronPort-AV: E=Sophos;i="4.63,282,1299456000"; d="scan'208";a="422376861" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 01 Apr 2011 14:52:21 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p31EqLAM029836; Fri, 1 Apr 2011 14:52:21 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 07:52:21 -0700 Received: from [10.60.114.232] ([10.60.114.232]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 07:52:19 -0700 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <4D95E56C.9070009@ieee.org> Date: Fri, 1 Apr 2011 16:52:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <4D95E56C.9070009@ieee.org> To: phoebus@ieee.org X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 01 Apr 2011 14:52:19.0986 (UTC) FILETIME=[66B3C720:01CBF07C] Cc: "roll@ietf.org" Subject: Re: [Roll] WG Last Call 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: Fri, 01 Apr 2011 14:50:55 -0000 Sorry for the typo, this is a WG on the -01 version. Thanks ! JP. On Apr 1, 2011, at 4:47 PM, Phoebus Chen wrote: > JP, >=20 > I suppose draft-ietf-roll-minrank-hysteresis-of-02 will be made = available online soon? Or is this a last call regarding = draft-ietf-roll-minrank-hysteresis-of-01? >=20 >=20 >=20 >=20 > Omprakash and Phil, >=20 > I made a pass through draft-ietf-roll-minrank-hysteresis-of-01. >=20 > General Comments: > ***************** > 1) As I understand from Table 1 and the mention of node metrics in the = second paragraph of the introduction, MRHOF also supports node metrics. = However, in various places throughout the document, you refer to the = "selected metric for the link..." . I point out where I spot this = below. When using node metrics, I presume the node adds it's own node = metric value to the advertised metric from its candidate neighbor to get = the path cost? >=20 >=20 > 2) In Section 3, you write "MRHOF cannot be used if the routing = objective is to maximize the metric." Those from the optimization = community may be a little puzzled, because you can just negate the = objective function to convert it from a maximization problem to a = minimization problem. >=20 > Let's assume you wish to maximizing the product of link probabilities = along a path. Then, you can use log(p) which results in only negative = link metrics (so still monotonic). And instead of MIN_PATH_COST, you = start with a MAX_PATH_REWARD of 0 and add the negative link metrics. I = don't see any of the MRHOF mechanisms breaking here (with some minor = tweaks of switching "minimize" to "maximize"). Am I missing something? >=20 > As I understand, limiting MRHOF to minimization makes the explanations = easier and the terminology / constant names more consistent. But are = you restricting the scope of the OF too much here? >=20 >=20 > 3) Are the parent selection rules in any way affected by = minHopRankIncrease, mentioned in (draft-ietf-roll-rpl-19, Section 3.5.2. = Rank Relationships)? Should minHopRankIncrease always be set to 1 for = MRHOF? In Table 1, you discuss how to convert various metrics into = rank, but make no mention of minHopRankIncrease. = (draft-ietf-roll-rpl-19, Section 3.5.1 Rank Comparison (DAGRank()) ) = says: >=20 > "MinHopRankIncrease is the minimum increase in rank between a node and = any of its DODAG parents." >=20 > As I understand, PARENT_SWITCH_THRESHOLD plays the role of = "coarsening" the metric, which was originally done by the DAGRank() = function for rank comparisons. The way I understand the properties of = rank described in (draft-ietf-roll-rpl-19, Section 3.5. Rank Properties) = and from earlier discussions on the mailing list, coarsening the rank is = for stability. DAGRank() may not do such a good job when two = path-cost-to-root's advertised by candidate neighbors are less than = PARENT_SWITCH_THRESHOLD apart but they result in different rank (e.g., = DAGRank(A) > DAGRank(B)). This is why we have MRHOF, right? > ************ >=20 >=20 > Nits / editorial comments follow below, preceded by "PC>". >=20 > Of course, don't forget to update the version numbers of the = informative references for last call (or is this done after last call? = I never remember.). >=20 >=20 > --=20 > Phoebus Chen > Postdoctoral Researcher > Automatic Control Lab, KTH (Royal Institute of Technology) > http://www.ee.kth.se/~phoebus >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Networking Working Group O. = Gnawali > Internet-Draft P. = Levis > Intended status: Standards Track Stanford = University > Expires: September 1, 2011 February 28, = 2011 >=20 >=20 >=20 > The Minimum Rank Objective Function with Hysteresis >=20 >=20 > draft-ietf-roll-minrank-hysteresis-of-01 >=20 >=20 > Abstract >=20 > 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). >=20 > Status of this Memo >=20 > This Internet-Draft is submitted to IETF in full conformance with = the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. >=20 > Internet-Drafts are draft documents valid for a maximum of six = months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. >=20 > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. >=20 > This Internet-Draft will expire on September 1, 2011. >=20 > Copyright Notice >=20 >=20 >=20 >=20 > Gnawali & Levis Expires September 1, 2011 [Page = 1] >=20 >=20 > Internet-Draft draft-ietf-roll-minrank-hysteresis-of February = 2011 >=20 >=20 > Copyright (c) 2011 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with = respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. >=20 >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . = 3 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . = 3 > 3. The Minimum Rank Objective Function with Hysteresis . . . . . . = 4 > 3.1. Computing the Path cost . . . . . . . . . . . . . . . . . . = 4 > 3.2. Parent Selection . . . . . . . . . . . . . . . . . . . . . = 5 > 3.3. Computing Rank . . . . . . . . . . . . . . . . . . . . . . = 6 > 3.4. Advertising the path cost . . . . . . . . . . . . . . . . . = 6 > 4. MRHOF Variables and Parameters . . . . . . . . . . . . . . . . = 7 > 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . = 8 > 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . = 8 > 7. Security Considerations . . . . . . . . . . . . . . . . . . . . = 8 > 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . = 8 > 8.1. Normative References . . . . . . . . . . . . . . . . . . . = 8 > 8.2. Informative References . . . . . . . . . . . . . . . . . . = 8 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . = 8 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Gnawali & Levis Expires September 1, 2011 [Page = 2] >=20 >=20 > Internet-Draft draft-ietf-roll-minrank-hysteresis-of February = 2011 >=20 >=20 > 1. Introduction >=20 >=20 > An objective function allows RPL [I-D.ietf-roll-rpl] to select paths > that are best in terms of a given routing metric or select paths = that > meet certain constraints in terms of the routing metric. RPL > achieves this goal by selecting the parent among the alternate > parents as dictated by that objective function. For example, if an > RPL instance uses an objective function that minimizes hop-count, = RPL > will select paths with minimum hop count. >=20 > The nodes running RPL might use a number of metrics to describe a > link or a node [I-D.ietf-roll-routing-metrics] and make it available > for route selection. A metric can be used by different objective > functions to optimize or constrain the metric in different ways. >=20 > This specification describes MRHOF, an objective function for RPL. > MRHOF uses hysteresis while selecting the path with the smallest > metric value. The path with the minimum cost has different property >=20 > PC> s/has different/has a different/ >=20 > depending on the metric used for path selection. For example, the > use of MRHOF with the latency metric allows RPL to find stable > minimum-latency paths from the nodes to a root in the DAG instance. > The use of MRHOF with the ETX metric allows RPL to find the stable > minimum-ETX paths from the nodes to a root in the DAG instance. >=20 > MRHOF can be used only with additive metric that must be minimized = on >=20 > PC> s/can be used only with additive/can only be used with an = additive/ >=20 > the paths selected for routing. Although MRHOF can be used with a > number of metrics, this draft is based on experiences with the ETX >=20 > PC> s/a number of metrics/different metrics/ >=20 > metric. >=20 >=20 > 2. Terminology >=20 >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and > "OPTIONAL" in this document are to be interpreted as described in = RFC > 2119 [RFC2119]. >=20 > This terminology used in this document is consistent with the > terminologies described in [I-D.ietf-roll-terminology], > [I-D.ietf-roll-rpl], and [I-D.ietf-roll-routing-metrics]. >=20 > This document introduces two terms: >=20 > Selected metric: The metric chosen by the network operator to use > for path selection. This metric can be any additive metric > listed in [I-D.ietf-roll-routing-metrics] >=20 > PC> Insert period at end of sentence above. >=20 >=20 >=20 >=20 >=20 > Gnawali & Levis Expires September 1, 2011 [Page = 3] >=20 >=20 > Internet-Draft draft-ietf-roll-minrank-hysteresis-of February = 2011 >=20 >=20 > Path cost: Path cost quantifies a property of an end-to-end path. > Path cost is composed using the selected metric of the links > along the path. Path cost can be used by RPL to compare > different paths. >=20 > PC> s/composed using the/obtained by summing up the/ >=20 >=20 > 3. The Minimum Rank Objective Function with Hysteresis >=20 >=20 > The Minimum Rank Objective Function with Hysteresis, MRHOF, is > designed to find the paths with the smallest path cost while > preventing excessive churn in the network. It does so by switching > to the minimum cost path only if the path cost of the current path = is > larger than the path cost of the minimum cost path by a given > threshold. MRHOF may be used with any additive metric listed in > [I-D.ietf-roll-routing-metrics] as long the routing objective is to > minimize the given routing metric. MRHOF cannot be used if the > routing objective is to maximize the metric. >=20 > 3.1. Computing the Path cost >=20 >=20 > Nodes compute the path cost for each candidate neighbor reachable on > all the interfaces. The Path cost represents the cost of the path, >=20 > PC> When I read this sentence literally, it means that a candidate > PC> neighbor must be reachable on ALL the interfaces. I don't think > PC> that's what you mean. This is done at various places throughout > PC> the document. May I suggest: > PC> s/reachable on all the interfaces/that can be reached through an = interface/ >=20 >=20 > in terms of the selected metric, from a node to the root of the = DODAG > through the neighbor. >=20 > Root nodes (Grounded or Floating) set the variable cur_min_path_cost > to MIN_PATH_COST. >=20 > A non-root node computes the path cost for a path to the root = through > each candidate neighbor by adding these two components: >=20 > 1. The selected metric for the link to a candidate neighbor. >=20 > 2. The value of the selected metric in the metric container in the > DIO sent by that neighbor. >=20 > A node SHOULD compute the path cost for the path through each > candidate neighbor reachable through all the interfaces. If a node >=20 > PC> Again, "reachable through all the interfaces". See comment above. >=20 > cannot compute the path cost for the path through a candidate > neighbor, the node MUST NOT select the candidate neighbor as its > preferred parent with one exception. If the node does not have >=20 > PC> s/parent with one/parent, with one/ >=20 > metrics to compute the path cost through any of the candidate > neighbors, it SHOULD join one of the candidate neighbors as a leaf > node. >=20 > If the selected metric of the link to a neighbor is not available, > the path cost for the path through that neighbor SHOULD be set to > MAX_PATH_COST. This cost value will prevent this path from being >=20 >=20 >=20 > Gnawali & Levis Expires September 1, 2011 [Page = 4] >=20 >=20 > Internet-Draft draft-ietf-roll-minrank-hysteresis-of February = 2011 >=20 >=20 > considered for path selection. >=20 > The path cost corresponding to a neighbor SHOULD be re-computed each > time: >=20 > 1. The selected metric of the link to the candidate neighbor is > updated. >=20 > 2. A node receives a new metric advertisement from the candidate > neighbor. >=20 > This computation MAY also be performed periodically. Deferring the > path cost computation for too long after new metric advertisements = or > updates to the selected link metric results in nodes making parent > selection decision based on stale link and path information. >=20 > 3.2. Parent Selection >=20 >=20 > After computing the path cost for all the candidate neighbors > reachable through all the interfaces for the current DODAG = iteration, > a node selects the preferred parent. This process is called parent > selection. Parent Selection SHOULD be performed each time: >=20 > 1. The path cost for an existing candidate neighbor, including the > preferred parent, changes. This condition can be checked > immediately after the path cost is computed. >=20 > 2. A new candidate neighbor is inserted into the neighbor table. >=20 > The parent selection MAY be deferred until a later time. Deferring > the parent selection can delay the use of better paths or stopping >=20 > PC> s/stopping/stop/ >=20 > the use of worse paths than what is available in the network. >=20 > A node MUST select a candidate neighbor as its preferred parent if > the path cost corresponding to that neighbor is smaller than the = path > cost corresponding to the rest of the neighbors, except as indicated > below: >=20 > 1. If the smallest path cost for paths through the candidate > neighbors is smaller than cur_min_path_cost by less than > PARENT_SWITCH_THRESHOLD, the node MAY continue to use the = current > preferred parent. >=20 > 2. If there are multiple paths with the smallest path cost and that >=20 > PC> remove "that" >=20 > the smallest path cost is smaller than cur_min_path_cost by at > least PARENT_SWITCH_THRESHOLD, a node MAY use a different > objective function to select the preferred parent among the > candidates which are first hop on the path with the minimum = cost. >=20 > PC> The last phrase is hard to parse, although it is correct. I'm not > PC> sure how to reword it. >=20 >=20 > Gnawali & Levis Expires September 1, 2011 [Page = 5] >=20 >=20 > Internet-Draft draft-ietf-roll-minrank-hysteresis-of February = 2011 >=20 >=20 > 3. A node MAY declare itself as a Floating root, and hence no > preferred parent, depending on the configuration. >=20 > 4. If the selected metric for a link is greater than > MAX_LINK_METRIC, the node SHOULD exclude that link from > consideration for parent selection. >=20 > 5. If cur_min_path_cost is greater than MAX_PATH_COST, the node MAY > declare itself as a Floating root. >=20 > 6. If the configuration disallows a node to be a Floating root and > no neighbors are discovered, the node does not have a preferred > parent, and MUST set cur_min_path_cost to MAX_PATH_COST. >=20 > The preferred parent is the only node in the parent set at a given > time. Any candidate neighbor may become the preferred parent as > indicated above. >=20 > 3.3. Computing Rank >=20 >=20 > The DAG roots set their rank to MIN_PATH_COST for the selected > metric. >=20 > Once a non-root node selects its preferred parent, it can use the > following table to covert its path cost to the DAG root through its > preferred parent (written as Cost in the table) to its rank: >=20 > +--------------------+------------+ > | Node/link Metric | Rank | > +--------------------+------------+ > | Node Energy | 255 - Cost | > | Hop-Count | Cost | > | Latency | Cost/65536 | > | Link Quality Level | Cost | > | ETX | Cost | > +--------------------+------------+ >=20 > Table 1: Conversion of metric to rank. >=20 > Node rank is undefined for these node/link metrics: Node state and > attributes, throughput, and link color. >=20 > 3.4. Advertising the path cost >=20 >=20 > Once the preferred parent is selected, the node sets its > cur_min_path_cost variable to the path cost corresponding to the > preferred parent. Thus, cur_min_path_cost is the cost of the = minimum > cost path from the node to the root. The value of the >=20 >=20 >=20 > Gnawali & Levis Expires September 1, 2011 [Page = 6] >=20 >=20 > Internet-Draft draft-ietf-roll-minrank-hysteresis-of February = 2011 >=20 >=20 > cur_min_path_cost is carried in the metric container whenever DIO > messages are sent. >=20 >=20 > 4. MRHOF Variables and Parameters >=20 >=20 > MRHOF uses the following variable: >=20 > cur_min_path_cost: The cost of the path from a node through its > preferred parent to the root computed at the last parent > selection. >=20 > MRHOF uses the following parameters: >=20 > MAX_LINK_METRIC: Maximum allowed value for the selected link > metric for each link on the path. >=20 > MAX_PATH_COST: Maximum allowed value for the path metric of a > selected path. >=20 > MIN_PATH_COST: The minimum allowed value for the path metric of > the selected path. >=20 > PARENT_SWITCH_THRESHOLD: The difference between metric of the = path > through the preferred parent and the minimum-metric path to > trigger new preferred parent selection. >=20 > PC> s/to trigger new preferred parent selection/in order to trigger = the selection of a new preferred parent./ >=20 > The parameter values are assigned depending on the selected metric. > The best values for these parameters should be experimentally > determined. The working group has long experience routing with the > ETX metric. Based on those experiences, these ETX parameters are > known to work in many settings: >=20 > MAX_LINK_METRIC: 10. Disallow links with greater than 10 = expected > transmission count on the selected path. >=20 > MAX_PATH_COST: 100. Disallow paths with greater than 100 = expected > transmission count. >=20 > MIN_PATH_COST: 0. At root, the expected transmission count is 0. >=20 > PARENT_SWITCH_THRESHOLD: 1.5. Switch to a new path only if it is > expected to require at least 1.5 fewer transmission than the > current path. >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Gnawali & Levis Expires September 1, 2011 [Page = 7] >=20 >=20 > Internet-Draft draft-ietf-roll-minrank-hysteresis-of February = 2011 >=20 >=20 > 5. Acknowledgements >=20 >=20 > Thanks to Antonio Grilo, Nicolas Tsiftes, Matteo Paris, JP Vasseur > for their comments. >=20 >=20 > 6. IANA Considerations >=20 >=20 > This specification requires an allocated OCP. A value of 1 is > requested. >=20 >=20 > 7. Security Considerations >=20 >=20 > Security considerations to be developed in accordance to the output > of the WG. >=20 >=20 > 8. References >=20 >=20 > 8.1. Normative References >=20 >=20 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. >=20 > 8.2. Informative References >=20 >=20 > [I-D.ietf-roll-routing-metrics] > Vasseur, J. and D. Networks, "Routing Metrics used for > Path Calculation in Low Power and Lossy Networks", > draft-ietf-roll-routing-metrics-01 (work in progress), > October 2009. >=20 > [I-D.ietf-roll-rpl] > Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing > Protocol for Low power and Lossy Networks", > draft-ietf-roll-rpl-05 (work in progress), December 2009. >=20 > [I-D.ietf-roll-terminology] > Vasseur, J., "Terminology in Low power And Lossy > Networks", draft-ietf-roll-terminology-01 (work in > progress), May 2009. >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Gnawali & Levis Expires September 1, 2011 [Page = 8] >=20 >=20 > Internet-Draft draft-ietf-roll-minrank-hysteresis-of February = 2011 >=20 >=20 > Authors' Addresses >=20 > Omprakash Gnawali > Stanford University > S255 Clark Center, 318 Campus Drive > Stanford, CA 94305 > USA >=20 > Phone: +1 650 725 6086 > Email: gnawali@cs.stanford.edu >=20 >=20 > Philip Levis > Stanford University > 358 Gates Hall, Stanford University > Stanford, CA 94305 > USA >=20 > Email: pal@cs.stanford.edu >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Gnawali & Levis Expires September 1, 2011 [Page = 9] >=20 >=20 > Html markup produced by rfcmarkup 1.92, available from = http://tools.ietf.org/tools/rfcmarkup/ >=20 >=20 >=20 >=20 > On 4/1/11 6:13 AM, JP Vasseur wrote: >> Dear all, >>=20 >> draft-ietf-roll-minrank-hysteresis-of has been discussed for quite = some time, >> the document is stable and is now ready for Working Group Last Call. = As discussed >> during the WG meeting yesterday, there a very questions to address. >>=20 >> This starts a 2-week WG Last call on = draft-ietf-roll-minrank-hysteresis-of-02 >> that will end on April 11 at noon ET (this is a bit more than 2 = weeks, considering >> most of us flying back end of this week). >>=20 >> Please send your comments to the authors and copy the mailing list. >>=20 >> Thanks. >>=20 >> JP. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Fri Apr 1 09:12:11 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 60F423A68AC for ; Fri, 1 Apr 2011 09:12:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.405 X-Spam-Level: X-Spam-Status: No, score=-10.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 OIGMRb39Ih30 for ; Fri, 1 Apr 2011 09:12:10 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0D20F3A6843 for ; Fri, 1 Apr 2011 09:12:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1991; q=dns/txt; s=iport; t=1301674430; x=1302884030; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=B2YLKDk+hDKzu93cOid0lJKXhnwlFuBDO0lplooFOLo=; b=HG1bBHoUpL40NiYdzrZKFDtKX6bPHfsz34N1+L5k4ABEyUNkL7x+k+xr T69tkRj1sfdIWng3MOqzCdlZgdnA3G8vYv7XMaYJ6nxpTj3QdEKgB/4Qe vljhA6UhMjhRsMxJ01hEMV8Kv01HSTsw9IHC7NHwNtnH1BojOK0W3/0hu M=; X-IronPort-AV: E=Sophos;i="4.63,283,1299456000"; d="scan'208";a="81859343" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2011 16:13:49 +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 p31GDncl030553; Fri, 1 Apr 2011 16:13:49 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, 1 Apr 2011 18:13:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2011 18:13:45 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> In-Reply-To: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 Thread-Index: AcvwIzbSiLSPDOyHTl+eArdiGDhxnAAXvi6g References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur" , "ROLL WG" X-OriginalArrivalTime: 01 Apr 2011 16:13:49.0535 (UTC) FILETIME=[C919BEF0:01CBF087] Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-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: Fri, 01 Apr 2011 16:12:11 -0000 Hi JP and authors: Phil and I have worked hard to clarify that OF0 can use link layer information though it is not propagating it in containers.=20 For good reasons, Mr Hof is more specific that OF0 in its behavior and its use of metrics than OF0 that had to be as generic as possible.=20 Yet I think that getting as much commonality as we can is a valuable goal. This starts with the ranges that are similar but not identical. Yes, MrHof uses metrics containers, whereas OF0 does not. But can a Mr Hof implementation refrain from using containers and connect to an OF0 network? IOW, what does it take for an MrHof implementation be able to attach to an OF0 network? What needs to be done - is it a simple tuning, complete rewrite? Also I wonder, should a Mr Hof implementation support all the metrics that are listed? If not, then how does a node know if it can actually work with the metrics in use in a Mr Hof network? Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP > Vasseur > Sent: Friday, April 01, 2011 6:14 AM > To: ROLL WG > Subject: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 >=20 > Dear all, >=20 > draft-ietf-roll-minrank-hysteresis-of has been discussed for quite some time, > the document is stable and is now ready for Working Group Last Call. As > discussed during the WG meeting yesterday, there a very questions to > address. >=20 > This starts a 2-week WG Last call on draft-ietf-roll-minrank-hysteresis-of-02 > that will end on April 11 at noon ET (this is a bit more than 2 weeks, > considering most of us flying back end of this week). >=20 > Please send your comments to the authors and copy the mailing list. >=20 > Thanks. >=20 > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=066546d27=mukul@uwm.edu Fri Apr 1 18:32: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 8449D3A69C3 for ; Fri, 1 Apr 2011 18:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IxZpB6wUMHLL for ; Fri, 1 Apr 2011 18:32:54 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id E2AAE3A69BE for ; Fri, 1 Apr 2011 18:32:53 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 01 Apr 2011 20:34:34 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 3C6DB2B3EF3; Fri, 1 Apr 2011 20:31:41 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yvxRxTznfo8; Fri, 1 Apr 2011 20:31:40 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id E115B2B3EF2; Fri, 1 Apr 2011 20:31:40 -0500 (CDT) Date: Fri, 1 Apr 2011 20:34:33 -0500 (CDT) From: Mukul Goyal To: JP Vasseur Message-ID: <266860965.101248.1301708073877.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <43AEA790-8199-4A86-A318-4963713CD991@cisco.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 Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Apr 2011 01:32:58 -0000 Hi all I favor adapting this draft as a WG document. The mechanism specified in this document is necessary to decide whether to invoke P2P route discovery and to determine the constraints that the P2P route must satisfy. Thanks Mukul ----- Original Message ----- From: "JP Vasseur" To: "ROLL WG" Sent: Thursday, March 31, 2011 11:56:43 PM Subject: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document Dear all, draft-goyal-roll-p2p-measurement has been discussed on the mailing list and is a normative reference of the P2P document. Could you tell us if you are in favor/opposed to adopt draft-goyal-roll-p2p-measurement-01 as a ROLL Working Group document ? Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Sat Apr 2 07:10: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 B17A13A6821; Sat, 2 Apr 2011 07:10:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.326 X-Spam-Level: X-Spam-Status: No, score=-2.326 tagged_above=-999 required=5 tests=[AWL=-0.078, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 QeTZPV3Svq3u; Sat, 2 Apr 2011 07:10:16 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id AEAFB3A681F; Sat, 2 Apr 2011 07:10:13 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id DB93A9400D0; Sat, 2 Apr 2011 16:11:46 +0200 (CEST) Message-ID: <4D972EA0.8030401@gmail.com> Date: Sat, 02 Apr 2011 16:11:44 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Brian Haberman References: <4D934844.1090106@innovationslab.net> In-Reply-To: <4D934844.1090106@innovationslab.net> Content-Type: multipart/mixed; boundary="------------030508030604010700040401" X-Antivirus: avast! (VPS 110402-0, 02/04/2011), Outbound message X-Antivirus-Status: Clean Cc: 6man Chairs <6man-chairs@tools.ietf.org>, 6man-ads@tools.ietf.org, IPv6 WG Mailing List , ROLL WG , iesg-secretary@ietf.org Subject: Re: [Roll] Request To Advance: 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, 02 Apr 2011 14:10:19 -0000 This is a multi-part message in MIME format. --------------030508030604010700040401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit [if needed I can trim the To/Cc, I just dont know] Hello Brian, Chairs, ADs, 6man, roll, This draft-ietf-6man-rpl-routing-header-03 is way too brief about the security risks of RPL RH. It basically states that this RPL RH is not risky when looked at from the outside, and does not seem to talk about risks from within RPL network. This perspective contradicts the RPL draft which says "[RPL networks] are vulnerable to passive eavesdropping attacks [and more]". This RPL RH is intended to be used with RPL protocol. RPL's draft security text states that AH and message auth code should be used over the entire IPv6 headers; hence over this RPL RH as well. However, there is no example of how to do it. Whereas it is known how to apply AH over Routing Header Type 0 (some advice in RFC4302). For RPL RH, we had an agreeing discussion on the RoLL WG email list September 10th, 2010, about a step-by-step description of using AH over RPL RH. See the first attached email and url: http://www.ietf.org/mail-archive/web/roll/current/msg05418.html My agreement to that discussion is ok, but does not show in these archives I dont know why, but I attached it as well to this email. I suggest inserting that example of using AH over RPL RH into the RPL RH draft. Maybe as an appendix, as an example. I find it very useful to implementer. (note: I do not know whether Robert Cragie who wrote that proposal on the mailing list agrees or even needs to insert it in the draft). Thank you for considering this issue, and I will follow this issue, Alex Le 30/03/2011 17:12, Brian Haberman a écrit : > Jari& Ralph, On behalf of the 6MAN WG, the chairs request the > advancement of: > > Title : An IPv6 Routing Header for Source Routes with RPL > Author(s) : J. Hui, et al. Filename : > draft-ietf-6man-rpl-routing-header-03.txt Pages : 19 Date : > 2011-03-29 > > as a Proposed Standard. A 6MAN WG Last Call ended on December 6, > 2010 and this version addresses all comments raised. > > Regards, Brian& Bob > -------------------------------------------------------------------- > IETF IPv6 working group mailing list ipv6@ietf.org Administrative > Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > --------------030508030604010700040401 Content-Type: message/rfc822; name="Message joint" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Message joint" Return-Path: alexandru.petrescu+caf_=alexandru.petrescu=incognitus.eu@gmail.com Received: from zimbra31-e6.priv.proxad.net (LHLO zimbra31-e6.priv.proxad.net) (172.20.243.181) by zimbra31-e6.priv.proxad.net with LMTP; Fri, 10 Sep 2010 18:51:27 +0200 (CEST) Received: from relay4-v.mail.gandi.net (mx23-g26.priv.proxad.net [172.20.243.93]) by zimbra31-e6.priv.proxad.net (Postfix) with ESMTP id 247651255D7 for ; Fri, 10 Sep 2010 18:48:15 +0200 (CEST) Received: from relay4-v.mail.gandi.net ([217.70.178.78]) by mx1-g20.free.fr (MXproxy) for alexandru.petrescu@free.fr ; Fri, 10 Sep 2010 18:48:15 +0200 (CEST) X-ProXaD-SC: state=HAM score=0 X-Originating-IP: 10.0.21.73 Received: from spool.mail.gandi.net (mspool3-v.mgt.gandi.net [10.0.21.73]) by relay4-v.mail.gandi.net (Postfix) with ESMTP id 010D2BA7F; Fri, 10 Sep 2010 18:48:15 +0200 (CEST) Received: from mfilter4-v.gandi.net (mfilter4-v.gandi.net [217.70.178.38]) by spool.mail.gandi.net (Postfix) with ESMTP id AA47B1B4068; Fri, 10 Sep 2010 18:48:14 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter4-v.gandi.net Received: from spool.mail.gandi.net ([10.0.21.73]) by mfilter4-v.gandi.net (mfilter4-v.gandi.net [217.70.178.38]) (amavisd-new, port 10024) with ESMTP id G7BztIKZ9ffv; Fri, 10 Sep 2010 18:48:11 +0200 (CEST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by spool.mail.gandi.net (Postfix) with ESMTP id 32BAF1B4060 for ; Fri, 10 Sep 2010 18:48:10 +0200 (CEST) Received: by bwz20 with SMTP id 20so3317779bwz.27 for ; Fri, 10 Sep 2010 09:48:10 -0700 (PDT) Received: by 10.204.48.75 with SMTP id q11mr750192bkf.0.1284137290444; Fri, 10 Sep 2010 09:48:10 -0700 (PDT) X-Forwarded-To: alexandru.petrescu@incognitus.eu X-Forwarded-For: alexandru.petrescu@gmail.com alexandru.petrescu@incognitus.eu Delivered-To: alexandru.petrescu@gmail.com Received: by 10.204.51.82 with SMTP id c18cs21786bkg; Fri, 10 Sep 2010 09:48:10 -0700 (PDT) Received: by 10.227.147.211 with SMTP id m19mr83585wbv.200.1284137286743; Fri, 10 Sep 2010 09:48:06 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by mx.google.com with ESMTP id k29si3455389wbb.65.2010.09.10.09.48.06; Fri, 10 Sep 2010 09:48:06 -0700 (PDT) Received-SPF: neutral (google.com: 79.170.40.78 is neither permitted nor denied by best guess record for domain of robert.cragie@gridmerge.com) client-ip=79.170.40.78; Authentication-Results: mx.google.com; spf=neutral (google.com: 79.170.40.78 is neither permitted nor denied by best guess record for domain of robert.cragie@gridmerge.com) smtp.mail=robert.cragie@gridmerge.com Received: from client-86-23-76-166.brhm.adsl.virginmedia.com ([86.23.76.166] helo=[192.168.1.72]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1Ou6lh-0005Oe-0K; Fri, 10 Sep 2010 17:48:06 +0100 Message-ID: <4C8A6144.1070401@gridmerge.com> Date: Fri, 10 Sep 2010 17:48:04 +0100 From: Robert Cragie Reply-To: robert.cragie@gridmerge.com Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-GB; rv:1.9.2.9) Gecko/20100825 Lightning/1.0b2 Thunderbird/3.1.3 MIME-Version: 1.0 To: Alexandru Petrescu CC: roll@ietf.org Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit References: <13773.1282327971@marajade.sandelman.ca> <4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> <4C87C73E.1040806@gmail.com> <4C88FD45.60004@gmail.com> <8556A091-D8F9-4B6B-8F49-4260005C577C@cs.berkeley.edu> <4C8A008C.7080406@gridmerge.com> <4C8A4D19.40202@gmai l.com> In-Reply-To: <4C8A4D19.40202@gmail.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040403030608070304050109" X-Antivirus: avast! (VPS 100910-1, 10/09/2010), Inbound message X-Antivirus-Status: Clean This is a cryptographically signed message in MIME format. --------------ms040403030608070304050109 Content-Type: multipart/alternative; boundary="------------070303040201040809040700" This is a multi-part message in MIME format. --------------070303040201040809040700 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Alex, Thank you for focusing on a pertinent issue. You are right to highlight=20 what we do with a RH4 header as I believe secured DAO ACK is the (only)=20 RPL control message which requires RH4 in non-storing mode. So, to follow the rules for mutable and predictable fields (see RFC=20 4302), we can resubstitute at the end: Consider the following: A -> B -> C -> D -> E A -> B: |Src|Dst|RH4 | | | |Seq|A0 |A1 |A2 | ------------------------- | A | B | 3 | C | D | E | B -> C: |Src|Dst|RH4 | | | |Seq|A0 |A1 |A2 | ------------------------- | A | C | 2 | B | D | E | C -> D: |Src|Dst|RH4 | | | |Seq|A0 |A1 |A2 | ------------------------- | A | D | 1 | B | C | E | D -> E: |Src|Dst|RH4 | | | |Seq|A0 |A1 |A2 | ------------------------- | A | E | 0 | B | C | D | When the packet arrives at E, recreate the original RH4 header for MAC=20 computation: n =3D ((Hdr Ext Len * 8) - Pad) / (16 - Comp) tmp =3D Dst Dst =3D RH4.A[0] RH4.Seq =3D n for (k =3D 1; k < n; k++) { RH4.A[k-1] =3D RH4.A[k] } RH4.A[k] =3D tmp |Src|Dst|RH4 | | | |Seq|L0 |L1 |L2 | ------------------------- | A | B | 3 | C | D | E | Is that acceptable? Now, just because I refer to IPSec AH, it doesn't mean I am suggesting=20 we use it. I am suggesting we can use the fundamental principles from=20 IPSec for an equivalent operation. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 10/09/2010 4:22 PM, Alexandru Petrescu wrote: > Le 10/09/2010 11:55, Robert Cragie a =E9crit : >> David, >> >> I totally agree with what you say. Thank you for restating generally >> that IPSec has already been extensively considered - I use the term >> 'paraphernalia' as a general term for the overheads. >> >> Alex - can we please drop the IPSec discussion and move on and >> concentrate on the things which do need to sorted out? > > Ok... let me try to avoid dissent and do what you ask. > > Let's come back to RPL-11 text: >> 3. If the packet header specifies a source route by including a RH4 >> header as specified in [I-D.ietf-6man-rpl-routing-header] > > then draft-ietf-6man-rpl-routing-header-00 says: >> else { swap the IPv6 Destination Address and Address[i] > > That means that there is a mutable but predictable field (IPv6 > Destination Addess) in RH of RPL. But RPL Security doesn't understand > mutable but predictable fields (only mutable as per recent discussion).= > RPL Security covers "entire IPv6 packet", which changes enroute despit= e > RPL Security's expectation it won't change. > > So the question is: does RPL Security secure the RH4 header? I think i= t > does not, because its MAC computation does not say how are the mutable > but predictable fields covered. > > For example, a sender builds a packet with Dst address1, computes MAC, > inserts MAC. Then intermediary routers process that packet and replace= > that Dst address1 with address2 from the Routing Header. Now the packe= t > is received at address1. The MAC can't be meaningfully computed on the= > receiver, because the "IPv6 entire packet" has changed, it is not the > same as at emission. > > I think this example is correct. > > It can't be solved in the same way we solved the mutability of "Hop > Limit" (we said to make HopLimit set to 0 for MAC calculation), because= > if we do so then we have a higher risk of attack than when left HopLimi= t > unsecure. If we set to 0 de Dst for MAC calculation then the risk of > implication of forged IP dst addresses is higher than forged HopLimit. > Forging an IP dst address is stronger security attack than forging > HopLimit, intuitively speaking. > > Besides, whereas the receiver has really no idea about what could the > original HopLimit be, it knows precisely what the original Dst address > was (it's in the RH4, swapped). Thus the securing solution should be > different - it should be as smart as RH4 is. > > Knowing the previous discussion, it may be possible that people will > request we refer to that Authentication Header RFC which tells how > mutable, mutable but predictable fields are dealt with. At that point > we come back to IPsec, but I will abstain from saying so if you wish. > There is also the fact that previous IPsec talk says RH0 whereas here w= e > have RH4 and things may be different. > > That's too long for anyone to read, but you get the point. > > Alex > > > > > You are of course >> entitled to your opinion but progress is only made in the IETF >> through rough consensus. Consensus does not mean unanimous agreement; >> if we can all at least consent to a solution then the process will >> run a lot more smoothly and we will all benefit. Continual dissent >> will only serve to hinder this progress. >> >> I think the consensus is clear: >> >> * We do not mention IPSec in RPL security * The mutable field >> discussion is entirely independent from IPSec >> >> Robert >> >> Robert Cragie (Pacific Gas & Electric) >> >> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 >> 1924 910888 +1 415 513 0064 http://www.gridmerge.com >> >> >> >> On 09/09/2010 9:33 PM, David Culler wrote: >>> Dear Alex, Thank you for focusing on the question of routing >>> security, rather than internet security in general. Yes, IPSec has >>> been utilized to secure routing protocols. Now please take the >>> next step and focus on routing for low power and lossy networks. >>> Obviously, IPSec has to be the first thing considered. And it was. >>> Dating back to the earliest security framework discussions it was >>> considered many times. We returned to the IPSec issue extensively >>> back in June on the mailing list. I won't reiterate the >>> discussion on the storage and time complexity, nor the message >>> overhead implications that were in those prior postings. But I >>> will observe that no one suggested that they saw their way to a >>> full IPSec implementation within the constraints articulated in the >>> Routing Requirements documents. The WG group has long since >>> reached a rough consensus on this matter and moved on. That is the >>> nature of a group process and specifically the role of WG LC. At >>> some point, we commit to certain things and stop revisiting them >>> from first principles. That allows us to focus more sharply on >>> the selected approach and refine it more completely. For example, >>> in security, we have specifics to resolve, such as which header >>> fields need to be skipped. It is not a matter of "but I imagine >>> that there may be alternatives". There might be. But we don't >>> just turn the same rocks over and over again. We carve the rough >>> stone, we chisel the details, we sand, we polish. >>> >>> So I assume that the point of your posting is that you want to be >>> sure that the justification for the choices that the WG made are >>> properly documented in the WG documents. If you feel that they are >>> not, perhaps you could point to the document and section that you >>> feel should contain this material more substantially. >>> >>> D. >>> >>> For reference,http://www.ietf.org/tao.html section 7.4 >>> >>> >>> On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote: >>> >>>> Le 09/09/2010 16:59, David Culler a=E9crit : >>>>> The RPL charter calls for us to address routing security >>>>> considerations. Not security in general. Not application >>>>> security. Not link level. Routing security. It is focused for >>>>> good reason. >>>> Routing security like OSPF using IPsec? "Authentication has been >>>> removed from the OSPF protocol and instead relies on IPv6's >>>> Authentication Header and Encapsulating Security Payload (ESP)." >>>> says rfc5340... why does RPL need to be different in this >>>> respect? >>>> >>>> Alex >>>> >>>>> On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote: >>>>> >>>>>> Le 08/09/2010 18:15, Philip Levis a=E9crit : >>>>>>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: >>>>>>> >>>>>>>> Le 03/09/2010 13:48, Robert Cragie a=E9crit : [skipped >>>>>>>> agreed opinions about IPsec] >>>>>>>>>> Reusing the IPsec module ensures a secure system - >>>>>>>>>> it's proven by earlier experience. We know it worked >>>>>>>>>> ok so why avoid using it. >>>>>>>>> I don't think the specification of RPL security >>>>>>>>> precludes the use of IPSec instead. Does the use of >>>>>>>>> IPSec need to be specified in the RPL >>>>>>>>> specification? >>>>>>>> YEs, the RPL specification must say something about >>>>>>>> security in its Security Considerations section. That >>>>>>>> something has to mention something about IPsec. >>>>>>> Why does it have to do so? In theory, RPL should be >>>>>>> entirely independent of IPSec. There have already been >>>>>>> numerous discussions about why simply relying on IPSec >>>>>>> would be problematic. Unfortunately you seem to forget >>>>>>> these points every few weeks and rehash the same >>>>>>> discussion. At some point it becomes a waste of everyone's >>>>>>> time. >>>>>> Phil - if RPL says "security" then it must understand that >>>>>> Internet security is usually IPsec. This is truer with IPv6 >>>>>> (as opposed to IPv4) where IPsec is very much integrated in >>>>>> the design (mutable fields, etc.) >>>>>> >>>>>> Have you checked the mutable field discussion? Do you agree >>>>>> that mutable fields must be taken into account? >>>>>> >>>>>> Please read that around 3 people agreed on a list of items >>>>>> which are worth discussion of security and IPsec - mutable >>>>>> fields is one such item. >>>>>> >>>>>> As such this discussion is not a waste of everyone's time. >>>>>> >>>>>> Alex >>>>>> >>>>>>> Phil >>>>>> >>>>>> _______________________________________________ Roll mailing >>>>>> list Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>> David Cullerculler@cs.berkeley.edu Chair Computer Science >>>>> Associate Chair EECS >>>>> >>>>> >>>>> >>>>> >>>> >>> David Culler culler@cs.berkeley.edu Chair Computer Science >>> Associate Chair EECS >>> >>> >>> >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >> >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------070303040201040809040700 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Alex,

Thank you for focusing on a pertinent issue. You are right to highlight what we do with a RH4 header as I believe secured DAO ACK is the (only) RPL control message which requires RH4 in non-storing mode.

So, to follow the rules for mutable and predictable fields (see RFC 4302), we can resubstitute at the end:

Consider the following:

A -> B -> C -> D -> E

A -> B:

|Src|Dst|RH4         &= nbsp;  |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
 | A | B | 3 | C | D | E |
B -> C:

|Src|Dst|RH4         &= nbsp;  |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
 | A | C | 2 | B | D | E |
C -> D:

|Src|Dst|RH4         &= nbsp;  |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
 | A | D | 1 | B | C | E |
D -> E:

|Src|Dst|RH4         &= nbsp;  |
|   |   |Seq|A0 |A1 |A2 |
-------------------------
 | A | E | 0 | B | C | D |
When the packet arrives at E, recreate the original RH4 header for MAC computation:

n =3D ((Hdr Ext Len * 8) - Pad) / (16 - Comp)
tmp =3D Dst
Dst =3D RH4.A[0]
RH4.Seq =3D n
for (k =3D 1; k < n; k++)
{
  RH4.A[k-1] =3D RH4.A[k]
}
RH4.A[k] =3D tmp

|Src|Dst|RH4         = ;   |
|   |   |Seq|L0 |L1 |L2 |
-------------------------
 | A | B | 3 | C | D | E |
Is that acceptable?

Now, just because I refer to IPSec AH, it doesn't mean I am suggesting we use it. I am suggesting we can use the fundamental principles from IPSec for an equivalent operation.

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd.
89 Greenfield Crescent,
Wakefield, WF4 4WA, UK
+44 1924 910888
+1 415 513 0064
http://www.gridmerge.com


On 10/09/2010 4:22 PM, Alexandru Petrescu wrote:
Le 10/09/2010 11:55, Robert Cragie a écrit :
David,

I totally agree with what you say. Thank you for restating generally
 that IPSec has already been extensively considered - I use = the term
 'paraphernalia' as a general term for the overheads.

Alex - can we please drop the IPSec discussion and move on and
concentrate on the things which do need to sorted out?

Ok... let me try to avoid dissent and do what you ask.

Let's come back to RPL-11 text:
3.  If the packet header specifies a= source route by including a RH4
header as specified in [I-D.ietf-6man-rpl-routing-header]

then draft-ietf-6man-rpl-routing-header-00 says:
else { swap the IPv6 Destination Address and Address[i]

That means that there is a mutable but predictable field (IPv6
Destination Addess) in RH of RPL.  But RPL Security doesn't understand
mutable but predictable fields (only mutable as per recent discussion).
 RPL Security covers "entire IPv6 packet", which changes enrou= te despite
RPL Security's expectation it won't change.

So the question is: does RPL Security secure the RH4 header?  = I think it
does not, because its MAC computation does not say how are the mutable
but predictable fields covered.

For example, a sender builds a packet with Dst address1, computes MAC,
inserts MAC.  Then intermediary routers process that packet an= d replace
that Dst address1 with address2 from the Routing Header.  Now = the packet
is received at address1.  The MAC can't be meaningfully comput= ed on the
receiver, because the "IPv6 entire packet" has changed, it is not the
same as at emission.

I think this example is correct.

It can't be solved in the same way we solved the mutability of "Hop
Limit" (we said to make HopLimit set to 0 for MAC calculation), because
if we do so then we have a higher risk of attack than when left HopLimit
unsecure.  If we set to 0 de Dst for MAC calculation then the = risk of
implication of forged IP dst addresses is higher than forged HopLimit.
Forging an IP dst address is stronger security attack than forging
HopLimit, intuitively speaking.

Besides, whereas the receiver has really no idea about what could the
original HopLimit be, it knows precisely what the original Dst address
was (it's in the RH4, swapped).  Thus the securing solution sh= ould be
different - it should be as smart as RH4 is.

Knowing the previous discussion, it may be possible that people will
request we refer to that Authentication Header RFC which tells how
mutable, mutable but predictable fields are dealt with.  At th= at point
we come back to IPsec, but I will abstain from saying so if you wish.
There is also the fact that previous IPsec talk says RH0 whereas here we
have RH4 and things may be different.

That's too long for anyone to read, but you get the point.

Alex




 You are of course
entitled to your opinion but progress is only made in the IETF
through rough consensus. Consensus does not mean unanimous agreement;
if we can all at least consent to a solution then the process will
run a lot more smoothly and we will all benefit. Continual dissent
will only serve to hinder this progress.

I think the consensus is clear:

* We do not mention IPSec in RPL security * The mutable field
discussion is entirely independent from IPSec

Robert

Robert Cragie (Pacific Gas & Electric)

Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44
1924 910888 +1 415 513 0064 http://www.gridmerge.com
<http://www.gridmerge.com/>


On 09/09/2010 9:33 PM, David Culler wrote:
Dear Alex, Thank you for focusing on th= e question of routing
security, rather than internet security in general.  Yes, IPSec has
been utilized to secure routing protocols.  Now please tak= e the
next step and focus on routing for low power and lossy networks.
Obviously, IPSec has to be the first thing considered.  An= d it was.
Dating back to the earliest security framework discussions it was
considered many times.   We returned to the IPSec iss= ue extensively
back in June on the mailing list.   I won't reiterate= the
discussion on the storage and time complexity, nor the message
overhead implications that were in those prior postings.  = But I
will observe that no one suggested that they saw their way to a
full IPSec implementation within the constraints articulated in the
Routing Requirements documents.   The WG group has lo= ng since
reached a rough consensus on this matter and moved on.  Th= at is the
nature of a group process and specifically the role of WG LC.&n= bsp; At
some point, we commit to certain things and stop revisiting them
from first principles.   That allows us to focus more= sharply on
the selected approach and refine it more completely.  For example,
in security, we have specifics to resolve, such as which header
fields need to be skipped.  It is not a matter of "but I imagine
that there may be alternatives".  There might be.  Bu= t we don't
just turn the same rocks over and over again.  We carve th= e rough
stone, we chisel the details, we sand, we polish.

So I assume that the point of your posting is that you want to be
sure that the justification for the choices that the WG made are
properly documented in the WG documents.  If you feel that= they are
not, perhaps you could point to the document and section that you
feel should contain this material more substantially.

D.

For reference,http://www.ietf.org/tao.html  section 7.= 4


On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote:

Le 09/09/2010 16:59, David Culler aécrit :
The RPL charter calls for us to address routing security
considerations.  Not security in general.  Not ap= plication
security. Not link level.  Routing security.  It = is focused for
good reason.
Routing security like OSPF using IPsec? "Authentication has been
removed from the OSPF protocol and instead relies on IPv6's
Authentication Header and Encapsulating Security Payload (ESP)."
says rfc5340... why does RPL need to be different in this
respect?

Alex

On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote:

Le 08/09/2010 18:15, Philip Levis= aécrit :
On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote:

Le 03/09/2010 13:48, Robert Cragie aécrit : [skipped
agreed opinions about IPsec]
Reusing the IPsec module ensures a secure system -
it's proven by earlier experience. We know it worked
ok so why avoid using it.
<RCC>I don't think the specification of RPL security
precludes the use of IPSec instead. Does the use of
IPSec need to be specified in the RPL
specification?</RCC>
YEs, the RPL specification must say something about
security in its Security Considerations section. = ; That
something has to mention something about IPsec.
Why does it have to do so? In theory, RPL should be
entirely independent of IPSec. There have already been
numerous discussions about why simply relying on IPSec
would be problematic. Unfortunately you seem to forget
these points every few weeks and rehash the same
discussion. At some point it becomes a waste of everyone's
time.
Phil - if RPL says "security" then it must understand that
Internet security is usually IPsec.  This is truer w= ith IPv6
(as opposed to IPv4) where IPsec is very much integrated in
the design (mutable fields, etc.)

Have you checked the mutable field discussion?  Do y= ou agree
that mutable fields must be taken into account?

Please read that around 3 people agreed on a list of items
which are worth discussion of security and IPsec - mutable
fields is one such item.

As such this discussion is not a waste of everyone's time.

Alex

Phil

_______________________________________________ Roll mailing
list Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll<= /a>
David Cullerculler@cs.berkeley.edu  Chai= r Computer Science
Associate Chair EECS





David Culler culler@cs.berkeley.edu Chair Computer Scie= nce
Associate Chair EECS



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



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


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

--------------070303040201040809040700-- --------------ms040403030608070304050109 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwOTEwMTY0ODA0WjAjBgkqhkiG9w0BCQQxFgQUTdtE PCVAAP81UIbq1+ioPsG25dwwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEAC0QjFHwszqO8++MWHvM1P+zw9EMMnMNiCyMR OSx0AXP7EhwkjsNKwAe9EoSbGqlYCEZNpMx4SnThqikSmVQM72OoaBPA/TA+ShC9rxs7z0zN NOhwyRevhOoh0K6KCz0FUj9MCyTi/MmkuDW8AlvRh6YxMxCuhoewNmISEgTuQtH9R9lAvHK0 YpxEzK7ITdg/kY7AuQlYwlsVFeFhSHUCfSSUsB/tCJ5GPwrMJR+l3wJRlOMhJ+G7dWfzUd85 LrrKOItOujSooErd7BDdvTPN1fQzs41h+3JBD+Ian6IRmkL7LDg2/fA0N5X5Dh0dPo3UQphO 7HqIocjFFkQNQNnnmAAAAAAAAA== --------------ms040403030608070304050109-- --------------030508030604010700040401 Content-Type: message/rfc822; name="Message joint" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="Message joint" Return-Path: alexandru.petrescu+caf_=alexandru.petrescu=incognitus.eu@gmail.com Received: from zimbra31-e6.priv.proxad.net (LHLO zimbra31-e6.priv.proxad.net) (172.20.243.181) by zimbra31-e6.priv.proxad.net with LMTP; Fri, 10 Sep 2010 19:55:22 +0200 (CEST) Received: from relay2-v.mail.gandi.net (mx15-g26.priv.proxad.net [172.20.243.85]) by zimbra31-e6.priv.proxad.net (Postfix) with ESMTP id 7027811FCB5 for ; Fri, 10 Sep 2010 19:55:22 +0200 (CEST) Received: from relay2-v.mail.gandi.net ([217.70.178.76]) by mx1-g20.free.fr (MXproxy) for alexandru.petrescu@free.fr ; Fri, 10 Sep 2010 19:55:22 +0200 (CEST) X-ProXaD-SC: state=HAM score=0 X-Originating-IP: 10.0.21.74 Received: from spool.mail.gandi.net (mspool4-v.mgt.gandi.net [10.0.21.74]) by relay2-v.mail.gandi.net (Postfix) with ESMTP id 2453D135D8; Fri, 10 Sep 2010 19:55:25 +0200 (CEST) Received: from mfilter1-v.gandi.net (mfilter1-v.gandi.net [217.70.178.35]) by spool.mail.gandi.net (Postfix) with ESMTP id 4AB762DC051; Fri, 10 Sep 2010 19:55:22 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter1-v.gandi.net Received: from spool.mail.gandi.net ([10.0.21.74]) by mfilter1-v.gandi.net (mfilter1-v.gandi.net [217.70.178.35]) (amavisd-new, port 10024) with ESMTP id HuhmBYnH-CSC; Fri, 10 Sep 2010 19:55:19 +0200 (CEST) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by spool.mail.gandi.net (Postfix) with ESMTP id 6D3292DC052 for ; Fri, 10 Sep 2010 19:55:19 +0200 (CEST) Received: by bwz20 with SMTP id 20so3404710bwz.27 for ; Fri, 10 Sep 2010 10:55:19 -0700 (PDT) Received: by 10.204.112.129 with SMTP id w1mr672062bkp.204.1284141318683; Fri, 10 Sep 2010 10:55:18 -0700 (PDT) X-Forwarded-To: alexandru.petrescu@incognitus.eu X-Forwarded-For: alexandru.petrescu@gmail.com alexandru.petrescu@incognitus.eu Delivered-To: alexandru.petrescu@gmail.com Received: by 10.204.51.82 with SMTP id c18cs23924bkg; Fri, 10 Sep 2010 10:55:18 -0700 (PDT) Received: by 10.100.174.8 with SMTP id w8mr1076648ane.12.1284141316616; Fri, 10 Sep 2010 10:55:16 -0700 (PDT) Received: from mail.ietf.org (mail.ietf.org [64.170.98.32]) by mx.google.com with ESMTP id f15si7265617ibb.27.2010.09.10.10.55.15; Fri, 10 Sep 2010 10:55:16 -0700 (PDT) Received-SPF: pass (google.com: domain of roll-bounces@ietf.org designates 64.170.98.32 as permitted sender) client-ip=64.170.98.32; Authentication-Results: mx.google.com; spf=pass (google.com: domain of roll-bounces@ietf.org designates 64.170.98.32 as permitted sender) smtp.mail=roll-bounces@ietf.org Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7411C3A6866; Fri, 10 Sep 2010 10:54:47 -0700 (PDT) X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 847E53A685C for ; Fri, 10 Sep 2010 10:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com 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 2M2olbT+kkRU for ; Fri, 10 Sep 2010 10:54:37 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 8BD923A67EB for ; Fri, 10 Sep 2010 10:54:29 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o8AHstZI017005 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Sep 2010 19:54:55 +0200 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 o8AHst3l025570; Fri, 10 Sep 2010 19:54:55 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o8AHss2r011600; Fri, 10 Sep 2010 19:54:55 +0200 Message-ID: <4C8A70EE.1050301@gmail.com> Date: Fri, 10 Sep 2010 19:54:54 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <13773.1282327971@marajade.sandelman.ca> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D6ACF.6040109@gmail.com> <2091800C08C647F8A9E7A4995ED7ED9F@ubilogixrodo> <4C80004B.4000305@gmail.com> <4C80B91E.2050200@gridmerge.com> <4C80BE98.80904@gmail.com> <4C80E09D.5040702@gridmerge.com> <4C811655.5000008@gmail.com> <519A78D0-77BC-466C-BAFF-084DEF5D9CB5@cs.stanford.edu> <4C87C73E.1040806@gmail.com> <4C88FD45.60004@gmail.com> <8556A091-D8F9-4B6B-8F49-4260005C577C@cs.berkeley.edu> <4C8A008C.7080406@gridmerge.com> <4C8A4D19.40202@gmai l.com> <4C8A6144.1070401@gridme! rge.com> In-Reply-To: <4C8A6144.1070401@gridmerge.com> Cc: roll@ietf.org Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Sender: roll-bounces@ietf.org Errors-To: roll-bounces@ietf.org X-Antivirus: avast! (VPS 100910-1, 10/09/2010), Inbound message X-Antivirus-Status: Clean Le 10/09/2010 18:48, Robert Cragie a =E9crit : > Hi Alex, > > Thank you for focusing on a pertinent issue. You are right to highlight > what we do with a RH4 header as I believe secured DAO ACK is the (only) > RPL control message which requires RH4 in non-storing mode. Sounds reassuring to know RH4 is only for DAO ACK and only for non-storing mode. And in storing mode? Is RH4 present in other than DAO ACK? Just to make sure I understand you. > So, to follow the rules for mutable and predictable fields (see RFC > 4302), we can resubstitute at the end: > > Consider the following: > > A -> B -> C -> D -> E > > A -> B: > > |Src|Dst|RH4 | > | | |Seq|A0 |A1 |A2 | > ------------------------- > | A | B | 3 | C | D | E | > > B -> C: > > |Src|Dst|RH4 | > | | |Seq|A0 |A1 |A2 | > ------------------------- > | A | C | 2 | B | D | E | > > C -> D: > > |Src|Dst|RH4 | > | | |Seq|A0 |A1 |A2 | > ------------------------- > | A | D | 1 | B | C | E | > > D -> E: > > |Src|Dst|RH4 | > | | |Seq|A0 |A1 |A2 | > ------------------------- > | A | E | 0 | B | C | D | > > When the packet arrives at E, recreate the original RH4 header for MAC > computation: > > n =3D ((Hdr Ext Len * 8) - Pad) / (16 - Comp) > tmp =3D Dst > Dst =3D RH4.A[0] > RH4.Seq =3D n > for (k =3D 1; k < n; k++) > { > RH4.A[k-1] =3D RH4.A[k] > } > RH4.A[k] =3D tmp > > |Src|Dst|RH4 | > | | |Seq|L0 |L1 |L2 | > ------------------------- > | A | B | 3 | C | D | E | > > Is that acceptable? Thanks for the method - it reads reasonable. It is a good way (one way? = are there others? are there little bugs in that code?) to specify MAC = over RH4 coherently - reconstruct the RH at reception. This solution is = different than solving the mutability of the Hop Limit field. Can we see further - RH4 draft also says IPv6-in-IPv6 tunnelling must be = used sometime, together with RH4. This raises the obvious question = about: is the header of the encapsulating packet also protected by the = MAC of RPL? Or not? RPL spec currently says the "entire IPv6 packet" is covered by its MAC. = But does that cover the IPv6 base header of the encapsulating header? = Or not? And in which order? > Now, just because I refer to IPSec AH, it doesn't mean I am suggesting > we use it. I am suggesting we can use the fundamental principles from > IPSec for an equivalent operation. I understand. I am just afraid sometimes we try to rewrite much parts = of it. For example, I wonder how to you plan to refer to that RFC document? = Just wondering. Alex > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. > 89 Greenfield Crescent, > Wakefield, WF4 4WA, UK > +44 1924 910888 > +1 415 513 0064 > http://www.gridmerge.com > > > On 10/09/2010 4:22 PM, Alexandru Petrescu wrote: >> Le 10/09/2010 11:55, Robert Cragie a =E9crit : >>> David, >>> >>> I totally agree with what you say. Thank you for restating generally >>> that IPSec has already been extensively considered - I use the term >>> 'paraphernalia' as a general term for the overheads. >>> >>> Alex - can we please drop the IPSec discussion and move on and >>> concentrate on the things which do need to sorted out? >> >> Ok... let me try to avoid dissent and do what you ask. >> >> Let's come back to RPL-11 text: >>> 3. If the packet header specifies a source route by including a RH4 >>> header as specified in [I-D.ietf-6man-rpl-routing-header] >> >> then draft-ietf-6man-rpl-routing-header-00 says: >>> else { swap the IPv6 Destination Address and Address[i] >> >> That means that there is a mutable but predictable field (IPv6 >> Destination Addess) in RH of RPL. But RPL Security doesn't understand >> mutable but predictable fields (only mutable as per recent discussion). >> RPL Security covers "entire IPv6 packet", which changes enroute despite >> RPL Security's expectation it won't change. >> >> So the question is: does RPL Security secure the RH4 header? I think it >> does not, because its MAC computation does not say how are the mutable >> but predictable fields covered. >> >> For example, a sender builds a packet with Dst address1, computes MAC, >> inserts MAC. Then intermediary routers process that packet and replace >> that Dst address1 with address2 from the Routing Header. Now the packet >> is received at address1. The MAC can't be meaningfully computed on the >> receiver, because the "IPv6 entire packet" has changed, it is not the >> same as at emission. >> >> I think this example is correct. >> >> It can't be solved in the same way we solved the mutability of "Hop >> Limit" (we said to make HopLimit set to 0 for MAC calculation), because >> if we do so then we have a higher risk of attack than when left HopLimit >> unsecure. If we set to 0 de Dst for MAC calculation then the risk of >> implication of forged IP dst addresses is higher than forged HopLimit. >> Forging an IP dst address is stronger security attack than forging >> HopLimit, intuitively speaking. >> >> Besides, whereas the receiver has really no idea about what could the >> original HopLimit be, it knows precisely what the original Dst address >> was (it's in the RH4, swapped). Thus the securing solution should be >> different - it should be as smart as RH4 is. >> >> Knowing the previous discussion, it may be possible that people will >> request we refer to that Authentication Header RFC which tells how >> mutable, mutable but predictable fields are dealt with. At that point >> we come back to IPsec, but I will abstain from saying so if you wish. >> There is also the fact that previous IPsec talk says RH0 whereas here we >> have RH4 and things may be different. >> >> That's too long for anyone to read, but you get the point. >> >> Alex >> >> >> >> >> You are of course >>> entitled to your opinion but progress is only made in the IETF >>> through rough consensus. Consensus does not mean unanimous agreement; >>> if we can all at least consent to a solution then the process will >>> run a lot more smoothly and we will all benefit. Continual dissent >>> will only serve to hinder this progress. >>> >>> I think the consensus is clear: >>> >>> * We do not mention IPSec in RPL security * The mutable field >>> discussion is entirely independent from IPSec >>> >>> Robert >>> >>> Robert Cragie (Pacific Gas & Electric) >>> >>> Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 >>> 1924 910888 +1 415 513 0064 http://www.gridmerge.com >>> >>> >>> >>> On 09/09/2010 9:33 PM, David Culler wrote: >>>> Dear Alex, Thank you for focusing on the question of routing >>>> security, rather than internet security in general. Yes, IPSec has >>>> been utilized to secure routing protocols. Now please take the >>>> next step and focus on routing for low power and lossy networks. >>>> Obviously, IPSec has to be the first thing considered. And it was. >>>> Dating back to the earliest security framework discussions it was >>>> considered many times. We returned to the IPSec issue extensively >>>> back in June on the mailing list. I won't reiterate the >>>> discussion on the storage and time complexity, nor the message >>>> overhead implications that were in those prior postings. But I >>>> will observe that no one suggested that they saw their way to a >>>> full IPSec implementation within the constraints articulated in the >>>> Routing Requirements documents. The WG group has long since >>>> reached a rough consensus on this matter and moved on. That is the >>>> nature of a group process and specifically the role of WG LC. At >>>> some point, we commit to certain things and stop revisiting them >>>> from first principles. That allows us to focus more sharply on >>>> the selected approach and refine it more completely. For example, >>>> in security, we have specifics to resolve, such as which header >>>> fields need to be skipped. It is not a matter of "but I imagine >>>> that there may be alternatives". There might be. But we don't >>>> just turn the same rocks over and over again. We carve the rough >>>> stone, we chisel the details, we sand, we polish. >>>> >>>> So I assume that the point of your posting is that you want to be >>>> sure that the justification for the choices that the WG made are >>>> properly documented in the WG documents. If you feel that they are >>>> not, perhaps you could point to the document and section that you >>>> feel should contain this material more substantially. >>>> >>>> D. >>>> >>>> For reference,http://www.ietf.org/tao.html section 7.4 >>>> >>>> >>>> On Sep 9, 2010, at 8:29 AM, Alexandru Petrescu wrote: >>>> >>>>> Le 09/09/2010 16:59, David Culler a=E9crit : >>>>>> The RPL charter calls for us to address routing security >>>>>> considerations. Not security in general. Not application >>>>>> security. Not link level. Routing security. It is focused for >>>>>> good reason. >>>>> Routing security like OSPF using IPsec? "Authentication has been >>>>> removed from the OSPF protocol and instead relies on IPv6's >>>>> Authentication Header and Encapsulating Security Payload (ESP)." >>>>> says rfc5340... why does RPL need to be different in this >>>>> respect? >>>>> >>>>> Alex >>>>> >>>>>> On Sep 8, 2010, at 10:26 AM, Alexandru Petrescu wrote: >>>>>> >>>>>>> Le 08/09/2010 18:15, Philip Levis a=E9crit : >>>>>>>> On Sep 3, 2010, at 8:37 AM, Alexandru Petrescu wrote: >>>>>>>> >>>>>>>>> Le 03/09/2010 13:48, Robert Cragie a=E9crit : [skipped >>>>>>>>> agreed opinions about IPsec] >>>>>>>>>>> Reusing the IPsec module ensures a secure system - >>>>>>>>>>> it's proven by earlier experience. We know it worked >>>>>>>>>>> ok so why avoid using it. >>>>>>>>>> I don't think the specification of RPL security >>>>>>>>>> precludes the use of IPSec instead. Does the use of >>>>>>>>>> IPSec need to be specified in the RPL >>>>>>>>>> specification? >>>>>>>>> YEs, the RPL specification must say something about >>>>>>>>> security in its Security Considerations section. That >>>>>>>>> something has to mention something about IPsec. >>>>>>>> Why does it have to do so? In theory, RPL should be >>>>>>>> entirely independent of IPSec. There have already been >>>>>>>> numerous discussions about why simply relying on IPSec >>>>>>>> would be problematic. Unfortunately you seem to forget >>>>>>>> these points every few weeks and rehash the same >>>>>>>> discussion. At some point it becomes a waste of everyone's >>>>>>>> time. >>>>>>> Phil - if RPL says "security" then it must understand that >>>>>>> Internet security is usually IPsec. This is truer with IPv6 >>>>>>> (as opposed to IPv4) where IPsec is very much integrated in >>>>>>> the design (mutable fields, etc.) >>>>>>> >>>>>>> Have you checked the mutable field discussion? Do you agree >>>>>>> that mutable fields must be taken into account? >>>>>>> >>>>>>> Please read that around 3 people agreed on a list of items >>>>>>> which are worth discussion of security and IPsec - mutable >>>>>>> fields is one such item. >>>>>>> >>>>>>> As such this discussion is not a waste of everyone's time. >>>>>>> >>>>>>> Alex >>>>>>> >>>>>>>> Phil >>>>>>> >>>>>>> _______________________________________________ Roll mailing >>>>>>> list Roll@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>> David Cullerculler@cs.berkeley.edu Chair Computer Science >>>>>> Associate Chair EECS >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> David Culler culler@cs.berkeley.edu Chair Computer Science >>>> Associate Chair EECS >>>> >>>> >>>> >>>> _______________________________________________ Roll mailing list >>>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>> >>> >>> >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --------------030508030604010700040401-- From pthubert@cisco.com Mon Apr 4 07:16: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 CD7493A67FB for ; Mon, 4 Apr 2011 07:16:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.41 X-Spam-Level: X-Spam-Status: No, score=-10.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 jUhuZ58fcJ3G for ; Mon, 4 Apr 2011 07:16:01 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id F1C443A69EF for ; Mon, 4 Apr 2011 07:16:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1462; q=dns/txt; s=iport; t=1301926664; x=1303136264; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=IblbkPDJYh91hf0ztx+b5ZSQyfMrC12HGGu6XG03XGk=; b=mvHa3ImNVavvBILg/s084toY/7AYM9q9nJ8JudMJA+xBSTCUKKq0NzIL aGlHDZkZ4HMwF+pkE66ic72zJ0lyWx44SXpKFF8I/K54FuOVJllL8tBm+ FmQdvlwMktsZGuwKYioUzmpP/fHYHCZtxrBQ6xDs0UD87UGdRSmrulD70 0=; X-IronPort-AV: E=Sophos;i="4.63,297,1299456000"; d="scan'208";a="82100132" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 04 Apr 2011 14:17:43 +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 p34EHhBw026114; Mon, 4 Apr 2011 14:17:43 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); Mon, 4 Apr 2011 16:17:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 4 Apr 2011 16:17:40 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0444154B@XMB-AMS-107.cisco.com> In-Reply-To: <266860965.101248.1301708073877.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document Thread-Index: Acvw1iXnSozAAax+RgOwsSz21YYMfgB/OPfw References: <43AEA790-8199-4A86-A318-4963713CD991@cisco.com> <266860965.101248.1301708073877.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "JP Vasseur" X-OriginalArrivalTime: 04 Apr 2011 14:17:43.0047 (UTC) FILETIME=[0FFD4970:01CBF2D3] Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Apr 2011 14:16:07 -0000 +1 Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Mukul Goyal > Sent: Saturday, April 02, 2011 3:35 AM > To: JP Vasseur > Cc: ROLL WG > Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL > WG document >=20 > Hi all >=20 > I favor adapting this draft as a WG document. The mechanism specified in > this document is necessary to decide whether to invoke P2P route discovery > and to determine the constraints that the P2P route must satisfy. >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "JP Vasseur" > To: "ROLL WG" > Sent: Thursday, March 31, 2011 11:56:43 PM > Subject: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG > document >=20 > Dear all, >=20 > draft-goyal-roll-p2p-measurement has been discussed on the mailing list and > is a normative reference of the P2P document. >=20 > Could you tell us if you are in favor/opposed to adopt draft-goyal-roll-p2p- > measurement-01 as a ROLL Working Group document ? >=20 > Thanks. >=20 > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abr@sdesigns.dk Tue Apr 5 07:06: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 0439A28C122 for ; Tue, 5 Apr 2011 07:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 2XF9N13SKcRf for ; Tue, 5 Apr 2011 07:06:00 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 9754528C115 for ; Tue, 5 Apr 2011 07:06:00 -0700 (PDT) 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, 5 Apr 2011 16:07:42 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD865@zensys17.zensys.local> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0444154B@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLLWG document Thread-Index: Acvw1iXnSozAAax+RgOwsSz21YYMfgB/OPfwADHmd1A= References: <43AEA790-8199-4A86-A318-4963713CD991@cisco.com><266860965.101248.1301708073877.JavaMail.root@mail02.pantherlink.uwm.edu> <6A2A459175DABE4BB11DE2026AA50A5D0444154B@XMB-AMS-107.cisco.com> From: "Anders Brandt" To: "Mukul Goyal" Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLLWG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Apr 2011 14:06:09 -0000 +1 > > Could you tell us if you are in favor/opposed to adopt > draft-goyal-roll-p2p- > > measurement-01 as a ROLL Working Group document ? - Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On=20 > Behalf Of Pascal Thubert (pthubert) > Sent: Monday, April 04, 2011 16:18 > To: Mukul Goyal; JP Vasseur > Cc: ROLL WG > Subject: Re: [Roll] Adoption=20 > draft-goyal-roll-p2p-measurement-01 as a ROLLWG document >=20 > +1 >=20 > Pascal > http://www.xtranormal.com/watch/7011357/ >=20 >=20 > > -----Original Message----- > > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > Of > > Mukul Goyal > > Sent: Saturday, April 02, 2011 3:35 AM > > To: JP Vasseur > > Cc: ROLL WG > > Subject: Re: [Roll] Adoption=20 > draft-goyal-roll-p2p-measurement-01 as a > ROLL > > WG document > >=20 > > Hi all > >=20 > > I favor adapting this draft as a WG document. The mechanism=20 > specified > in > > this document is necessary to decide whether to invoke P2P route > discovery > > and to determine the constraints that the P2P route must satisfy. > >=20 > > Thanks > > Mukul > >=20 > > ----- Original Message ----- > > From: "JP Vasseur" > > To: "ROLL WG" > > Sent: Thursday, March 31, 2011 11:56:43 PM > > Subject: [Roll] Adoption=20 > draft-goyal-roll-p2p-measurement-01 as a ROLL > WG > > document > >=20 > > Dear all, > >=20 > > draft-goyal-roll-p2p-measurement has been discussed on the mailing > list and > > is a normative reference of the P2P document. > >=20 > > Could you tell us if you are in favor/opposed to adopt > draft-goyal-roll-p2p- > > measurement-01 as a ROLL Working Group document ? > >=20 > > Thanks. > >=20 > > JP. > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From Internet-Drafts@ietf.org Tue Apr 5 09:00: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 E615228C124; Tue, 5 Apr 2011 09:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id keXcyZ3gUT3Y; Tue, 5 Apr 2011 09:00:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18C9928C11C; Tue, 5 Apr 2011 09:00:02 -0700 (PDT) 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.14 Message-ID: <20110405160002.12711.52229.idtracker@localhost> Date: Tue, 05 Apr 2011 09:00:02 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-of0-09.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, 05 Apr 2011 16:00: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 : RPL Objective Function 0 Author(s) : P. Thubert Filename : draft-ietf-roll-of0-09.txt Pages : 10 Date : 2011-04-05 The Routing Protocol for Low Power and Lossy Networks defines a generic Distance Vector protocol for Low Power and Lossy Networks. That generic protocol requires a specific Objective Function to establish a desired routing topology. This specification defines a basic Objective Function that operates solely with the protocol elements defined in the generic protocol specification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-09.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-of0-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-05085757.I-D@ietf.org> --NextPart-- From d.sturek@att.net Thu Apr 7 06:32:41 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 12EE13A6916 for ; Thu, 7 Apr 2011 06:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.856 X-Spam-Level: X-Spam-Status: No, score=-0.856 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=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 FnU5A20LF589 for ; Thu, 7 Apr 2011 06:32:40 -0700 (PDT) Received: from nm16.bullet.mail.bf1.yahoo.com (nm16.bullet.mail.bf1.yahoo.com [98.139.212.175]) by core3.amsl.com (Postfix) with SMTP id D64533A690F for ; Thu, 7 Apr 2011 06:32:39 -0700 (PDT) Received: from [98.139.212.153] by nm16.bullet.mail.bf1.yahoo.com with NNFMP; 07 Apr 2011 13:34:21 -0000 Received: from [98.139.212.218] by tm10.bullet.mail.bf1.yahoo.com with NNFMP; 07 Apr 2011 13:34:21 -0000 Received: from [127.0.0.1] by omp1027.mail.bf1.yahoo.com with NNFMP; 07 Apr 2011 13:34:21 -0000 X-Yahoo-Newman-Id: 537851.24537.bm@omp1027.mail.bf1.yahoo.com Received: (qmail 3860 invoked from network); 7 Apr 2011 13:34:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1302183261; bh=sFpml3fInM6Fpf78x0gWTZedl0Ge8J5dxqtOmUN7eYg=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=n3EUZAgv+NDJvFmz1Imwjj55b3EYztY3ibPQdHEUKyllNktArTGw6Er3tVCEduC4Wxw7ybZgjtcIAAUfD8l2KAu5MemSH2m976h1RDwQbPIbHO94Hm/PPDTKMvClzUEZbuNk7/syJvR+xJVOMIOsKBu6CvMJZ+D4SI3GrA1urk4= Received: from Studio (d.sturek@77.107.140.146 with login) by smtp106.sbc.mail.bf1.yahoo.com with SMTP; 07 Apr 2011 06:34:21 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: v7m_GEQVM1l_v1R8vu33_8MoOA7lkOHf9UDtXTWwGWCpSY. 3aRSMRWT0k6MEtampFgtqD_tNjtmKgfX22mI113t5Y6fSamRrh6G1yKgcPt3 4xeLpFB9kcnoo8AqqBkjVwTZDgMnBOM5Po1qvJr_be8lNePHG1Tn_hSFiHuK unDONUidL2HSm6prWbQ.6w7HkdlTFZ8olsSDzJtKz7T84cNcawkAq8OXt3Bq YtBep02ArY0WkvonRd0KW1z9JETsbK8qXMZAFP8bJfs7W6O5gA9MgdHscLb. tDB86y.xvRwcv.qyTGS05NNWiY8kNDB4FekvLAWRlRunoUQ-- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'JP Vasseur'" Date: Thu, 7 Apr 2011 06:34:17 -0700 Message-ID: <00e401cbf528$7f7ee270$7e7ca750$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvgB+WAjp8ESRgwQ0a1EmHlyn9YMAAAI+vQBUfxOFA= Content-Language: en-us Cc: roll@ietf.org Subject: [Roll] FW: Status of ROLL RPL related drafts in 6man (please note point on trickle multicast draft) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2011 13:32:41 -0000 Hi JP, Could we consider adding the draft below: Trickle Multicast to the ROLL group as a working group document? As you can see from below, the 6MAN group does not believe the scope of the draft is appropriate for 6MAN and suggest ROLL as a better home. We are using the Trickle Multicast draft in our ZigBee IP work. Thanks, Don Sturek -----Original Message----- From: Don Sturek [mailto:d.sturek@att.net] Sent: Friday, March 11, 2011 8:26 AM To: 'roll@ietf.org' Subject: FW: Status of ROLL RPL related drafts in 6man (please note point on trickle multicast draft) In checking on the status of 6MAN drafts related to ROLL RPL, I asked about the trickle multicast draft currently in 6MAN. Here is a link to the draft: http://datatracker.ietf.org/doc/draft-hui-6man-trickle-mcast/ Have a look below at the response from Brian Haberman. What does the group think about adopting this draft into ROLL RPL? Don -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Friday, March 11, 2011 8:18 AM To: ipv6@ietf.org Subject: Re: Status of ROLL RPL related drafts in 6man On 3/11/11 11:03 AM, Don Sturek wrote: > Can I ask about the current WG status of the following drafts: > > http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-routing-header/ > > http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-option/ > The WG Last Call completed for these documents. There were some comments that, according to the authors, have been resolved but not incorporated into the document(s). > > > Also, the following draft has not been adopted by WG (can it?): > > http://datatracker.ietf.org/doc/draft-hui-6man-trickle-mcast/ > No one has made a request for the WG to adopt it. > > We would also like to see the trickle multicast draft adopted by the group. > >From my brief read of the draft, I am not sure it belongs in 6MAN. It describes a multicast forwarding paradigm specific to low-power networks. It would seem like ROLL is a better fit for this draft. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From culler@cs.berkeley.edu Thu Apr 7 09:22:51 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 DD4D328C159 for ; Thu, 7 Apr 2011 09:22:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aaUVrzp9j3fu for ; Thu, 7 Apr 2011 09:22:50 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id AB9803A6A14 for ; Thu, 7 Apr 2011 09:22:50 -0700 (PDT) Received: from [10.152.178.105] ([198.217.64.127]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id p37GORFd015466 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 7 Apr 2011 09:24:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: David Culler In-Reply-To: <00e401cbf528$7f7ee270$7e7ca750$%sturek@att.net> Date: Thu, 7 Apr 2011 09:23:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <43B80571-CC01-4452-B095-E53036B81746@cs.berkeley.edu> References: <00e401cbf528$7f7ee270$7e7ca750$%sturek@att.net> To: d.sturek@att.net, Philip Levis X-Mailer: Apple Mail (2.1084) Cc: roll@ietf.org Subject: Re: [Roll] FW: Status of ROLL RPL related drafts in 6man (please note point on trickle multicast 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, 07 Apr 2011 16:22:52 -0000 I am in support of considering this draft and would like to hear WG = comments. =20 One note - the trickle work is partly rooted in the work on scalable = reliable multicast (SRM), with the additional influence of wireless = communication. It would be good to see the informational references = touch on some of the related use of suppression techniques in the = specific context of multicast. On Apr 7, 2011, at 6:34 AM, Don Sturek wrote: > Hi JP, >=20 > Could we consider adding the draft below: Trickle Multicast to the = ROLL > group as a working group document? >=20 > As you can see from below, the 6MAN group does not believe the scope = of the > draft is appropriate for 6MAN and suggest ROLL as a better home. >=20 > We are using the Trickle Multicast draft in our ZigBee IP work. >=20 > Thanks, >=20 > Don Sturek >=20 >=20 > -----Original Message----- > From: Don Sturek [mailto:d.sturek@att.net]=20 > Sent: Friday, March 11, 2011 8:26 AM > To: 'roll@ietf.org' > Subject: FW: Status of ROLL RPL related drafts in 6man (please note = point on > trickle multicast draft) >=20 > In checking on the status of 6MAN drafts related to ROLL RPL, I asked = about > the trickle multicast draft currently in 6MAN. Here is a link to the = draft: > http://datatracker.ietf.org/doc/draft-hui-6man-trickle-mcast/=20 >=20 > Have a look below at the response from Brian Haberman. What does the = group > think about adopting this draft into ROLL RPL? >=20 > Don=20 >=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = Of > Brian Haberman > Sent: Friday, March 11, 2011 8:18 AM > To: ipv6@ietf.org > Subject: Re: Status of ROLL RPL related drafts in 6man >=20 > On 3/11/11 11:03 AM, Don Sturek wrote: >> Can I ask about the current WG status of the following drafts: >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-routing-header/ >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-option/ >>=20 >=20 > The WG Last Call completed for these documents. There were some > comments that, according to the authors, have been resolved but not > incorporated into the document(s). >=20 >>=20 >>=20 >> Also, the following draft has not been adopted by WG (can it?): >>=20 >> http://datatracker.ietf.org/doc/draft-hui-6man-trickle-mcast/ >>=20 >=20 > No one has made a request for the WG to adopt it. >=20 >>=20 >> We would also like to see the trickle multicast draft adopted by the > group. >>=20 >=20 > =46rom my brief read of the draft, I am not sure it belongs in 6MAN. = It > describes a multicast forwarding paradigm specific to low-power > networks. It would seem like ROLL is a better fit for this draft. >=20 > Regards, > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll David Culler culler@cs.berkeley.edu Chair Computer Science Associate Chair EECS From daniel.gavelle@nxp.com Thu Apr 7 09:40: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 443FB3A68EC for ; Thu, 7 Apr 2011 09:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OVNoYtpzMoLA for ; Thu, 7 Apr 2011 09:40:34 -0700 (PDT) Received: from be1ssnxpe1.nxp.com (be1ssnxpe1.nxp.com [57.67.164.69]) by core3.amsl.com (Postfix) with ESMTP id BFEBC3A6819 for ; Thu, 7 Apr 2011 09:40:33 -0700 (PDT) Received: from EU1RDCRDC1VW024.exi.nxp.com ([134.27.176.169]) by be1ssnxpe1.nxp.com (8.14.3/8.14.3) with ESMTP id p37GgFSO022475 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Thu, 7 Apr 2011 18:42:15 +0200 Received: from eu1rdcrdc1wx032.exi.nxp.com ([134.27.179.186]) by EU1RDCRDC1VW024.exi.nxp.com ([134.27.176.169]) with mapi; Thu, 7 Apr 2011 18:42:15 +0200 From: Daniel Gavelle To: "roll@ietf.org" Date: Thu, 7 Apr 2011 18:42:14 +0200 Thread-Topic: [Roll] FW: Status of ROLL RPL related drafts in 6man (please note point on trickle multicast draft) Thread-Index: Acv1QFR3v9K6bbkwTcirTwx0QLYVyQAAhK1g Message-ID: <78B923726E7D59429936580CF127E943A14DB929EF@eu1rdcrdc1wx032.exi.nxp.com> References: <00e401cbf528$7f7ee270$7e7ca750$%sturek@att.net> <43B80571-CC01-4452-B095-E53036B81746@cs.berkeley.edu> In-Reply-To: <43B80571-CC01-4452-B095-E53036B81746@cs.berkeley.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.2.15, 1.0.148, 0.0.0000 definitions=2011-04-07_06:2011-04-07, 2011-04-07, 1970-01-01 signatures=0 Subject: Re: [Roll] FW: Status of ROLL RPL related drafts in 6man (please note point on trickle multicast 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, 07 Apr 2011 16:40:35 -0000 I support the adoption of this draft in the working group. I implemented t= he draft. I am interested in optimising the suppression to minimise traffic= whilst maintaining a good level of reliability. Daniel. -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Dav= id Culler Sent: 07 April 2011 17:23 To: d.sturek@att.net; Philip Levis Cc: roll@ietf.org Subject: Re: [Roll] FW: Status of ROLL RPL related drafts in 6man (please n= ote point on trickle multicast draft) I am in support of considering this draft and would like to hear WG comment= s. =20 One note - the trickle work is partly rooted in the work on scalable reliab= le multicast (SRM), with the additional influence of wireless communication= . It would be good to see the informational references touch on some of th= e related use of suppression techniques in the specific context of multicas= t. On Apr 7, 2011, at 6:34 AM, Don Sturek wrote: > Hi JP, >=20 > Could we consider adding the draft below: Trickle Multicast to the RO= LL > group as a working group document? >=20 > As you can see from below, the 6MAN group does not believe the scope of t= he > draft is appropriate for 6MAN and suggest ROLL as a better home. >=20 > We are using the Trickle Multicast draft in our ZigBee IP work. >=20 > Thanks, >=20 > Don Sturek >=20 >=20 > -----Original Message----- > From: Don Sturek [mailto:d.sturek@att.net]=20 > Sent: Friday, March 11, 2011 8:26 AM > To: 'roll@ietf.org' > Subject: FW: Status of ROLL RPL related drafts in 6man (please note point= on > trickle multicast draft) >=20 > In checking on the status of 6MAN drafts related to ROLL RPL, I asked abo= ut > the trickle multicast draft currently in 6MAN. Here is a link to the dra= ft: > http://datatracker.ietf.org/doc/draft-hui-6man-trickle-mcast/=20 >=20 > Have a look below at the response from Brian Haberman. What does the gro= up > think about adopting this draft into ROLL RPL? >=20 > Don=20 >=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Brian Haberman > Sent: Friday, March 11, 2011 8:18 AM > To: ipv6@ietf.org > Subject: Re: Status of ROLL RPL related drafts in 6man >=20 > On 3/11/11 11:03 AM, Don Sturek wrote: >> Can I ask about the current WG status of the following drafts: >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-routing-header/ >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-option/ >>=20 >=20 > The WG Last Call completed for these documents. There were some > comments that, according to the authors, have been resolved but not > incorporated into the document(s). >=20 >>=20 >>=20 >> Also, the following draft has not been adopted by WG (can it?): >>=20 >> http://datatracker.ietf.org/doc/draft-hui-6man-trickle-mcast/ >>=20 >=20 > No one has made a request for the WG to adopt it. >=20 >>=20 >> We would also like to see the trickle multicast draft adopted by the > group. >>=20 >=20 > From my brief read of the draft, I am not sure it belongs in 6MAN. It > describes a multicast forwarding paradigm specific to low-power > networks. It would seem like ROLL is a better fit for this draft. >=20 > Regards, > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll David Culler culler@cs.berkeley.edu Chair Computer Science Associate Chair EECS _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Thu Apr 7 09:41: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 9690A3A68EC for ; Thu, 7 Apr 2011 09:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nkLwyRP+2zS5 for ; Thu, 7 Apr 2011 09:41:49 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 0A3823A6819 for ; Thu, 7 Apr 2011 09:41:49 -0700 (PDT) Received: from [50.12.161.7] (helo=50-12-161-7.sfo.clearwire-wmx.net) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Q7sIu-0006ap-Ml; Thu, 07 Apr 2011 09:43:32 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <00e401cbf528$7f7ee270$7e7ca750$@sturek@att.net> Date: Thu, 7 Apr 2011 09:43:31 -0700 Content-Transfer-Encoding: 7bit Message-Id: <37AFAE58-AC55-4EFE-850A-BF4DC19A0F77@cs.stanford.edu> References: <00e401cbf528$7f7ee270$7e7ca750$@sturek@att.net> To: d.sturek@att.net X-Mailer: Apple Mail (2.1084) X-Scan-Signature: a1ccd6d2fa83ef575f7b7817ead66a1e Cc: roll@ietf.org Subject: Re: [Roll] FW: Status of ROLL RPL related drafts in 6man (please note point on trickle multicast 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, 07 Apr 2011 16:41:49 -0000 On Apr 7, 2011, at 6:34 AM, Don Sturek wrote: > Hi JP, > > Could we consider adding the draft below: Trickle Multicast to the ROLL > group as a working group document? > > As you can see from below, the 6MAN group does not believe the scope of the > draft is appropriate for 6MAN and suggest ROLL as a better home. > > We are using the Trickle Multicast draft in our ZigBee IP work. I support making the Trickle Multicast draft a WG document. Phil From gnawali@cs.stanford.edu Thu Apr 7 11:38: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 634E73A695C for ; Thu, 7 Apr 2011 11:38:06 -0700 (PDT) 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 N+p+9qWu9+b6 for ; Thu, 7 Apr 2011 11:38:05 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 8F0183A67B0 for ; Thu, 7 Apr 2011 11:38:05 -0700 (PDT) Received: from mail-pv0-f172.google.com ([74.125.83.172]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Q7u7S-0004u4-Bc for roll@ietf.org; Thu, 07 Apr 2011 11:39:50 -0700 Received: by pvh1 with SMTP id 1so1203302pvh.31 for ; Thu, 07 Apr 2011 11:39:49 -0700 (PDT) Received: by 10.143.21.14 with SMTP id y14mr882114wfi.126.1302201589870; Thu, 07 Apr 2011 11:39:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.55.6 with HTTP; Thu, 7 Apr 2011 11:39:29 -0700 (PDT) In-Reply-To: <37AFAE58-AC55-4EFE-850A-BF4DC19A0F77@cs.stanford.edu> References: <37AFAE58-AC55-4EFE-850A-BF4DC19A0F77@cs.stanford.edu> From: Omprakash Gnawali Date: Thu, 7 Apr 2011 11:39:29 -0700 Message-ID: To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: b64bce576883819501cf77c9371f4538 Cc: roll@ietf.org Subject: Re: [Roll] FW: Status of ROLL RPL related drafts in 6man (please note point on trickle multicast 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, 07 Apr 2011 18:38:06 -0000 +1 - om_p On Thu, Apr 7, 2011 at 9:43 AM, Philip Levis wrote: > > On Apr 7, 2011, at 6:34 AM, Don Sturek wrote: > >> Hi JP, >> >> Could we consider adding the draft below: =A0 Trickle Multicast =A0 to t= he ROLL >> group as a working group document? >> >> As you can see from below, the 6MAN group does not believe the scope of = the >> draft is appropriate for 6MAN and suggest ROLL as a better home. >> >> We are using the Trickle Multicast draft in our ZigBee IP work. > > I support making the Trickle Multicast draft a WG document. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From c.chauvenet@watteco.com Fri Apr 8 00:53:01 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 1D0383A68E1 for ; Fri, 8 Apr 2011 00:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.647 X-Spam-Level: X-Spam-Status: No, score=-5.647 tagged_above=-999 required=5 tests=[AWL=0.952, 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 f1vlscUQ0SGE for ; Fri, 8 Apr 2011 00:53:00 -0700 (PDT) Received: from TX2EHSOBE005.bigfish.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by core3.amsl.com (Postfix) with ESMTP id 1A1DD28B797 for ; Fri, 8 Apr 2011 00:52:59 -0700 (PDT) Received: from mail147-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE005.bigfish.com (10.9.40.25) with Microsoft SMTP Server id 14.1.225.8; Fri, 8 Apr 2011 07:54:44 +0000 Received: from mail147-tx2 (localhost.localdomain [127.0.0.1]) by mail147-tx2-R.bigfish.com (Postfix) with ESMTP id B16B11BA821D; Fri, 8 Apr 2011 07:54:44 +0000 (UTC) X-SpamScore: -48 X-BigFish: VPS-48(zzbb2dK9371O542M1432N98dK4015Lzz1202hzz1033IL8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB005.red002.local; RD:none; EFVD:NLI Received: from mail147-tx2 (localhost.localdomain [127.0.0.1]) by mail147-tx2 (MessageSwitch) id 1302249284324101_18185; Fri, 8 Apr 2011 07:54:44 +0000 (UTC) Received: from TX2EHSMHS034.bigfish.com (unknown [10.9.14.250]) by mail147-tx2.bigfish.com (Postfix) with ESMTP id 4AAAE96004F; Fri, 8 Apr 2011 07:54:44 +0000 (UTC) Received: from IE2RD2HUB005.red002.local (213.199.187.153) by TX2EHSMHS034.bigfish.com (10.9.99.134) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 8 Apr 2011 07:54:39 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB005.red002.local ([10.33.16.153]) with mapi; Fri, 8 Apr 2011 00:54:32 -0700 From: C Chauvenet To: "d.sturek@att.net" Date: Fri, 8 Apr 2011 00:54:30 -0700 Thread-Topic: [Roll] FW: Status of ROLL RPL related drafts in 6man (please note point on trickle multicast draft) Thread-Index: Acv1wjG9SLL/hdl2TlOltBmCsv/zvA== Message-ID: <8AD67D5F-2912-4A2E-B575-EDF61AEA02E3@watteco.com> References: <00e401cbf528$7f7ee270$7e7ca750$@sturek@att.net> In-Reply-To: <00e401cbf528$7f7ee270$7e7ca750$@sturek@att.net> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "roll@ietf.org" Subject: Re: [Roll] FW: Status of ROLL RPL related drafts in 6man (please note point on trickle multicast 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, 08 Apr 2011 07:53:01 -0000 +1 C=E9dric Le 7 avr. 2011 =E0 15:34, Don Sturek a =E9crit : > Hi JP, >=20 > Could we consider adding the draft below: Trickle Multicast to the RO= LL > group as a working group document? >=20 > As you can see from below, the 6MAN group does not believe the scope of t= he > draft is appropriate for 6MAN and suggest ROLL as a better home. >=20 > We are using the Trickle Multicast draft in our ZigBee IP work. >=20 > Thanks, >=20 > Don Sturek >=20 >=20 > -----Original Message----- > From: Don Sturek [mailto:d.sturek@att.net]=20 > Sent: Friday, March 11, 2011 8:26 AM > To: 'roll@ietf.org' > Subject: FW: Status of ROLL RPL related drafts in 6man (please note point= on > trickle multicast draft) >=20 > In checking on the status of 6MAN drafts related to ROLL RPL, I asked abo= ut > the trickle multicast draft currently in 6MAN. Here is a link to the dra= ft: > http://datatracker.ietf.org/doc/draft-hui-6man-trickle-mcast/=20 >=20 > Have a look below at the response from Brian Haberman. What does the gro= up > think about adopting this draft into ROLL RPL? >=20 > Don=20 >=20 > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Brian Haberman > Sent: Friday, March 11, 2011 8:18 AM > To: ipv6@ietf.org > Subject: Re: Status of ROLL RPL related drafts in 6man >=20 > On 3/11/11 11:03 AM, Don Sturek wrote: >> Can I ask about the current WG status of the following drafts: >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-routing-header/ >>=20 >> http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-option/ >>=20 >=20 > The WG Last Call completed for these documents. There were some > comments that, according to the authors, have been resolved but not > incorporated into the document(s). >=20 >>=20 >>=20 >> Also, the following draft has not been adopted by WG (can it?): >>=20 >> http://datatracker.ietf.org/doc/draft-hui-6man-trickle-mcast/ >>=20 >=20 > No one has made a request for the WG to adopt it. >=20 >>=20 >> We would also like to see the trickle multicast draft adopted by the > group. >>=20 >=20 > From my brief read of the draft, I am not sure it belongs in 6MAN. It > describes a multicast forwarding paradigm specific to low-power > networks. It would seem like ROLL is a better fit for this draft. >=20 > Regards, > Brian > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From c.chauvenet@watteco.com Fri Apr 8 05:41:40 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 BB3583A691A for ; Fri, 8 Apr 2011 05:41:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.242 X-Spam-Level: X-Spam-Status: No, score=-4.242 tagged_above=-999 required=5 tests=[AWL=-0.643, 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 xYeKLz0VDmLf for ; Fri, 8 Apr 2011 05:41:39 -0700 (PDT) Received: from VA3EHSOBE008.bigfish.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by core3.amsl.com (Postfix) with ESMTP id 6F6A43A6911 for ; Fri, 8 Apr 2011 05:41:38 -0700 (PDT) Received: from mail81-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.8; Fri, 8 Apr 2011 12:43:23 +0000 Received: from mail81-va3 (localhost.localdomain [127.0.0.1]) by mail81-va3-R.bigfish.com (Postfix) with ESMTP id E269DCB0268; Fri, 8 Apr 2011 12:43:22 +0000 (UTC) X-SpamScore: -26 X-BigFish: VPS-26(zz1432Nzz1202hzz1033IL8275dhz2dh2a8h668h839h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB006.red002.local; RD:none; EFVD:NLI Received: from mail81-va3 (localhost.localdomain [127.0.0.1]) by mail81-va3 (MessageSwitch) id 1302266602567375_29065; Fri, 8 Apr 2011 12:43:22 +0000 (UTC) Received: from VA3EHSMHS036.bigfish.com (unknown [10.7.14.248]) by mail81-va3.bigfish.com (Postfix) with ESMTP id 875D6168804D; Fri, 8 Apr 2011 12:43:22 +0000 (UTC) Received: from IE2RD2HUB006.red002.local (213.199.187.153) by VA3EHSMHS036.bigfish.com (10.7.99.46) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 8 Apr 2011 12:43:22 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB006.red002.local ([10.33.16.154]) with mapi; Fri, 8 Apr 2011 05:43:12 -0700 From: C Chauvenet To: JP Vasseur Date: Fri, 8 Apr 2011 05:43:09 -0700 Thread-Topic: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document Thread-Index: Acv16oUFPB1PD/YWSfWMQrLDO0oCZw== Message-ID: <8E7048E9-87CC-4BD5-8B50-D4C3098F177B@watteco.com> References: <43AEA790-8199-4A86-A318-4963713CD991@cisco.com> In-Reply-To: <43AEA790-8199-4A86-A318-4963713CD991@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 12:41:40 -0000 +1 C=E9dric. Le 1 avr. 2011 =E0 06:56, JP Vasseur a =E9crit : > Dear all, >=20 > draft-goyal-roll-p2p-measurement has been discussed on the mailing list a= nd is a normative > reference of the P2P document. >=20 > Could you tell us if you are in favor/opposed to adopt draft-goyal-roll-p= 2p-measurement-01 as=20 > a ROLL Working Group document ? >=20 > Thanks. >=20 > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From jpv@cisco.com Fri Apr 8 07:18:17 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 5D71E28C118 for ; Fri, 8 Apr 2011 07:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.482 X-Spam-Level: X-Spam-Status: No, score=-110.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 Y9Mb2oLRM5sy for ; Fri, 8 Apr 2011 07:18:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 664F528C0F0 for ; Fri, 8 Apr 2011 07:18:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=196; q=dns/txt; s=iport; t=1302272402; x=1303482002; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=oDE0TJSQh6AIB9eQbhdvTrtPvcNXx1lLdFSWPsoFxqQ=; b=i8I6oqRDA4ic5nJxDPEP+AFUmiWf92D+avvV758qbSBnAkFJwleFd4MI R3uL2jSvFUYu2Ms00VUGAcUcljpx1B3QhEulhaFL+w8JoROJgdtCus/Nv ozxhtjsU2STODNJH+fxPc/KV7jHMcP9+n09GdAqq4VQAlhs9vKxGjV67I Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocDAEwYn02Q/khLgWdsb2JhbACmFBQBARYmJaUlnCyFbQSNToNqBw X-IronPort-AV: E=Sophos;i="4.63,323,1299456000"; d="scan'208";a="82802361" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 08 Apr 2011 14:20:01 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p38EK0Vk020517 for ; Fri, 8 Apr 2011 14:20:00 GMT Received: from xfe-bgl-412.cisco.com ([72.163.129.200]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Apr 2011 19:49:59 +0530 Received: from [10.60.114.229] ([10.60.114.229]) by xfe-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 8 Apr 2011 19:49:59 +0530 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 8 Apr 2011 16:19:57 +0200 Message-Id: To: "roll@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 08 Apr 2011 14:19:59.0700 (UTC) FILETIME=[0B17E140:01CBF5F8] Subject: [Roll] Draft ROLL WG meeting minutes 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, 08 Apr 2011 14:18:17 -0000 The draft minutes of the ROLL WG IETF-80 has been posted: please provide = your comment if any by April 16 at noon ET. http://www.ietf.org/proceedings/80/minutes/roll.txt Thanks. JP.= From jonhui@cisco.com Fri Apr 8 08:27: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 761FD3A6974 for ; Fri, 8 Apr 2011 08:27:31 -0700 (PDT) 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 hD-FQm8nNJLm for ; Fri, 8 Apr 2011 08:27:30 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 7BFD73A6819 for ; Fri, 8 Apr 2011 08:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=537; q=dns/txt; s=iport; t=1302276556; x=1303486156; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=xLgxVHC+tfOEdyks1F1Sodw99NSDGFj2EgCKw3WXIvg=; b=MMeXJ0e/aoL5tMxFOvC1iP3VC7Mpmch+5XH+ddERx/CA0Utp43Je2cU7 kZhgr53GecoXa/XghRuDpTXPDr2dus5IOfXZ32M30H6JCpiRapqb5sZxr Ur5O/8iVp/LQTfn4jI2YFSgpYqj8p1+XvE7cBtp0U1us60vHmqMSWHuQD k=; X-IronPort-AV: E=Sophos;i="4.63,324,1299456000"; d="scan'208";a="426419014" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by sj-iport-1.cisco.com with ESMTP; 08 Apr 2011 15:29:15 +0000 Received: from dhcp-128-107-155-201.cisco.com (dhcp-128-107-155-201.cisco.com [128.107.155.201]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p38FTFWu025519; Fri, 8 Apr 2011 15:29:15 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <43AEA790-8199-4A86-A318-4963713CD991@cisco.com> Date: Fri, 8 Apr 2011 08:29:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <913549B1-D3E8-4357-BFA7-4905F377EDC3@cisco.com> References: <43AEA790-8199-4A86-A318-4963713CD991@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1084) Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2011 15:27:31 -0000 +1 -- Jonathan Hui On Mar 31, 2011, at 9:56 PM, JP Vasseur wrote: > Dear all, >=20 > draft-goyal-roll-p2p-measurement has been discussed on the mailing = list and is a normative > reference of the P2P document. >=20 > Could you tell us if you are in favor/opposed to adopt = draft-goyal-roll-p2p-measurement-01 as=20 > a ROLL Working Group document ? >=20 > Thanks. >=20 > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From buttyan@crysys.hu Fri Apr 8 11:07: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 7951C3A6A0D for ; Fri, 8 Apr 2011 11:07:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.004 X-Spam-Level: X-Spam-Status: No, score=-0.004 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G7FfH+QwyQDn for ; Fri, 8 Apr 2011 11:07:28 -0700 (PDT) Received: from shamir.crysys.hit.bme.hu (shamir.crysys.hit.bme.hu [152.66.249.135]) by core3.amsl.com (Postfix) with ESMTP id 04B3A3A6A03 for ; Fri, 8 Apr 2011 11:07:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crysys.hu; s=shamir; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:To:MIME-Version:From:Date:Message-ID; bh=J4g0O879xvjcZvobxu0hg9XFrccs9cFPb+7NYwuPHuI=; b=opIAZMOEbDz1C/4EYj9elEmYT9kMcmDWXLkoy31mQkbO8ZQeO40v19Ec9bJgYMGgbUWBh+BPe5Iyssl7K1YGQEDpG3RGjedSut8zF140WilM8Pb8WrnyeTSncid9ZJN2BpS4VtDHhUWqEBnX6Q2hk3IeBWf3OqpajNZhY1jdejk=; Received: from ip10-105-55.ebizlab.hit.bme.hu ([10.105.1.55] helo=localhost ident=amavis) by shamir.crysys.hit.bme.hu with esmtp (Exim 4.72) (envelope-from ) id 1Q8G4A-0006Lu-91; Fri, 08 Apr 2011 20:05:54 +0200 X-Virus-Scanned: by amavis-dc Received: from shamir.crysys.hit.bme.hu ([10.105.1.254]) by localhost (seeve.etl.hu [10.105.1.55]) (amavisd-new, port 10023) with ESMTP id uoOJDTrsOQff; Fri, 8 Apr 2011 18:05:48 +0000 (UTC) Received: from 183-101-163.ip.adsl.hu ([81.183.101.163] helo=[10.7.1.100]) by shamir.crysys.hit.bme.hu with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Q8G44-0006Lg-K4; Fri, 08 Apr 2011 20:05:48 +0200 Message-ID: <4D9F4E73.5080202@crysys.hu> Date: Fri, 08 Apr 2011 20:05:39 +0200 From: Levente Buttyan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Lightning/1.0b2 Thunderbird/3.1.9 MIME-Version: 1.0 To: JP Vasseur , roll@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Draft ROLL WG meeting minutes 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, 08 Apr 2011 18:07:29 -0000 Dear Jean-Philippe, I have some comments related to 11) Version Number Authentication and Local Key Agreement - as mentioned at the beginning of the presentation, the talk was given by Levente Buttyan (!= Amit Dvir) - questions were also responded by Levente Buttyan (!= Amit Dvir) - the current version already controls an authentication mechanism, indeed that's one of the main points of the draft - the next version will contain a mechanism that authenticates not only the version number but also prevents the decrease of the rank value by compromised nodes (this issue was raised by Phil) Thanks for fixing the minutes accordingly. Levente Buttyan On 4/8/2011 4:19 PM, JP Vasseur wrote: > The draft minutes of the ROLL WG IETF-80 has been posted: please provide your comment if any by April 16 > at noon ET. > > http://www.ietf.org/proceedings/80/minutes/roll.txt > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > -- Dr Levente Buttyan Associate Professor Laboratory of Cryptography and System Security (CrySyS) Budapest University of Technology and Economics (BME) URL: http://www.hit.bme.hu/~buttyan/ From gnawali@cs.stanford.edu Sat Apr 9 21:38:46 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 96C603A69C3 for ; Sat, 9 Apr 2011 21:38:46 -0700 (PDT) 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 lt0yg0rRl3vA for ; Sat, 9 Apr 2011 21:38:45 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 667EA3A69AF for ; Sat, 9 Apr 2011 21:38:45 -0700 (PDT) Received: from mail-px0-f182.google.com ([209.85.212.182]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Q8mRr-0008QM-Kf for roll@ietf.org; Sat, 09 Apr 2011 21:40:32 -0700 Received: by pxi20 with SMTP id 20so2647209pxi.27 for ; Sat, 09 Apr 2011 21:40:31 -0700 (PDT) Received: by 10.142.149.10 with SMTP id w10mr3807372wfd.69.1302410431041; Sat, 09 Apr 2011 21:40:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.55.6 with HTTP; Sat, 9 Apr 2011 21:40:11 -0700 (PDT) In-Reply-To: <4D95E56C.9070009@ieee.org> References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <4D95E56C.9070009@ieee.org> From: Omprakash Gnawali Date: Sat, 9 Apr 2011 21:40:11 -0700 Message-ID: To: phoebus@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 49896a3a751959820c06ecc920723d92 Cc: "roll@ietf.org" Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-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: Sun, 10 Apr 2011 04:38:46 -0000 On Fri, Apr 1, 2011 at 7:47 AM, Phoebus Chen wrote: > JP, > > =A0 =A0 =A0 =A0I suppose draft-ietf-roll-minrank-hysteresis-of-02 will be= made > available online soon? =A0Or is this a last call regarding > draft-ietf-roll-minrank-hysteresis-of-01? The last call is on -01. > 1) As I understand from Table 1 and the mention of node metrics in the > second paragraph of the introduction, MRHOF also supports node metrics. > =A0However, in various places throughout the document, you refer to the > "selected metric for the link..." . =A0I point out where I spot this belo= w. > =A0When using node metrics, I presume the node adds it's own node metric = value > to the advertised metric from its candidate neighbor to get the path cost= ? Yes. Would it be better to say near the top that the discussion uses the phrase link metric but all the discussions also apply to node metric or use the phrase link or node metric throughout the text? > 2) In Section 3, you write "MRHOF cannot be used if the routing objective= is > to maximize the metric." =A0Those from the optimization community may be = a > little puzzled, because you can just negate the objective function to > convert it from a maximization problem to a minimization problem. > > Let's assume you wish to maximizing the product of link probabilities alo= ng > a path. =A0Then, you can use log(p) which results in only negative link > metrics (so still monotonic). =A0And instead of MIN_PATH_COST, you start = with > a MAX_PATH_REWARD of 0 and add the negative link metrics. =A0I don't see = any > of the MRHOF mechanisms breaking here (with some minor tweaks of switchin= g > "minimize" to "maximize"). =A0Am I missing something? > > As I understand, limiting MRHOF to minimization makes the explanations > easier and the terminology / constant names more consistent. =A0But are y= ou > restricting the scope of the OF too much here? Yes. Another way way converting maximization to minimization is by computing a reciprocal of the metric. Would it be adequate to include a subsection that describes how to convert maximization metric to a minimization metric so that we can use mrhof? I think the most common use of mrhof will be with something like etx so I hesitate to make the draft too general which will make force the implementers of the most common case to have to read a lot of generalizations. If we want to use mrhof with maximization metrics by converting them to minimization, we need to standardize how to do this conversion so that two mrhof implementations can interoperate. One option is to use negative metric another is computing a reciprocal. We need to pick one. > 3) Are the parent selection rules in any way affected by minHopRankIncrea= se, > mentioned in (draft-ietf-roll-rpl-19, Section 3.5.2. Rank Relationships)? > =A0Should minHopRankIncrease always be set to 1 for MRHOF? =A0In Table 1,= you > discuss how to convert various metrics into rank, but make no mention of > minHopRankIncrease. (draft-ietf-roll-rpl-19, Section 3.5.1 Rank Compariso= n > (DAGRank()) ) says: > > "MinHopRankIncrease is the minimum increase in rank between a node and an= y > of its DODAG parents." Good point. We should put a requirement saying RPL minHopRankIncrease should be 1 because depending on the metric, mrhof computes the rank at the granularity of 1. What is the best section to put such requirements? > As I understand, PARENT_SWITCH_THRESHOLD plays the role of "coarsening" t= he > metric, which was originally done by the DAGRank() function for rank > comparisons. =A0The way I understand the properties of rank described in > (draft-ietf-roll-rpl-19, Section 3.5. Rank Properties) and from earlier > discussions on the mailing list, coarsening the rank is for stability. > DAGRank() may not do such a good job when two path-cost-to-root's adverti= sed > by candidate neighbors are less than PARENT_SWITCH_THRESHOLD apart but th= ey > result in different rank (e.g., DAGRank(A) > DAGRank(B)). =A0This is why = we > have MRHOF, right? MRHOF will compute the rank based on the metrics. I believe the rank you are talking about is more like hop-count Rank? I processed all your editorial comments. Thanks for all the comments. - om_p From gnawali@cs.stanford.edu Sat Apr 9 21:52: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 8D33E3A6979 for ; Sat, 9 Apr 2011 21:52:19 -0700 (PDT) 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 aNVMG6fLDsfF for ; Sat, 9 Apr 2011 21:52:19 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 0A0643A6951 for ; Sat, 9 Apr 2011 21:52:19 -0700 (PDT) Received: from mail-pz0-f44.google.com ([209.85.210.44]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Q8mez-00071k-EG for roll@ietf.org; Sat, 09 Apr 2011 21:54:05 -0700 Received: by pzk30 with SMTP id 30so2082605pzk.31 for ; Sat, 09 Apr 2011 21:54:05 -0700 (PDT) Received: by 10.143.86.10 with SMTP id o10mr567492wfl.240.1302411245057; Sat, 09 Apr 2011 21:54:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.55.6 with HTTP; Sat, 9 Apr 2011 21:53:45 -0700 (PDT) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> From: Omprakash Gnawali Date: Sat, 9 Apr 2011 21:53:45 -0700 Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: f9929892efd47015c544d6ca2fb551e9 Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-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: Sun, 10 Apr 2011 04:52:19 -0000 On Fri, Apr 1, 2011 at 9:13 AM, Pascal Thubert (pthubert) wrote: > Hi JP and authors: > > Phil and I have worked hard to clarify that OF0 can use link layer > information though it is not propagating it in containers. > > For good reasons, Mr Hof is more specific that OF0 in its behavior and > its use of metrics than OF0 that had to be as generic as possible. > > Yet I think that getting as much commonality as we can is a valuable > goal. This starts with the ranges that are similar but not identical. > > Yes, MrHof uses metrics containers, whereas OF0 does not. But can a Mr > Hof implementation refrain from using containers and connect to an OF0 > network? IOW, what =A0does it take for an MrHof implementation be able to > attach to an OF0 network? What needs to be done - is it a simple tuning, > complete rewrite? We can change mrhof to use the rank advertised by of0 as the advertised path cost if there is no metric container. Then the network with mrhof can compute additive metric based on that base cost. of0 would have no difficulty using the rank computed by mrhof. So, with that little tweak above, we can make mrhof and of0 networks interoperate. The interoperation, however, will not be ideal. If there are multiple connection points between a mrhof and an of0 networks, the metric minimization algorithm will compute the lowest ranks assuming homogeneous metric because downstream nodes in a mrhof network don't know what fraction of the path cost is due to rank from of0. > Also I wonder, should a Mr Hof implementation support all the metrics > that are listed? If not, then how does a node know if it can actually > work with the metrics in use in a Mr Hof network? I have this text for now: " Node rank is undefined for these node/link metrics: Node state and attributes, throughput, and link color." We can set the rank to max rank in case of unsupported metrics? - om_p From gnawali@cs.stanford.edu Sun Apr 10 05:04:10 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 75B1D3A6A07 for ; Sun, 10 Apr 2011 05:04:10 -0700 (PDT) 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 Irh983klTihZ for ; Sun, 10 Apr 2011 05:04:10 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 0FC263A6A0B for ; Sun, 10 Apr 2011 05:04:10 -0700 (PDT) Received: from mail-pw0-f44.google.com ([209.85.160.44]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Q8tOu-0006cj-OU for roll@ietf.org; Sun, 10 Apr 2011 05:05:56 -0700 Received: by pwi5 with SMTP id 5so2183390pwi.31 for ; Sun, 10 Apr 2011 05:05:56 -0700 (PDT) Received: by 10.142.218.2 with SMTP id q2mr3908853wfg.395.1302437156085; Sun, 10 Apr 2011 05:05:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Sun, 10 Apr 2011 05:05:36 -0700 (PDT) In-Reply-To: References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> From: Omprakash Gnawali Date: Sun, 10 Apr 2011 05:05:36 -0700 Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: b219533affeb7a3d33db26149f6cdee6 Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-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: Sun, 10 Apr 2011 12:04:10 -0000 Regarding parent set - I am planning to suggest a parent set of size 3. It will be a SHOULD because this might not be too big in a very sparse network. Please send your comments. - om_p From pthubert@cisco.com Mon Apr 11 03:05:10 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 A898528C0E8 for ; Mon, 11 Apr 2011 03:05:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.42 X-Spam-Level: X-Spam-Status: No, score=-10.42 tagged_above=-999 required=5 tests=[AWL=0.179, 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 54DmOoQvJDQV for ; Mon, 11 Apr 2011 03:05:06 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 6778328C0E0 for ; Mon, 11 Apr 2011 03:05:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3306; q=dns/txt; s=iport; t=1302516307; x=1303725907; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ShyT6mbg7UgCo9n16bd1a6p6wfa4YqkS5OLPfjQkBmI=; b=VfYwl3Px1HN/+bZbrTKAOOW3nP1ZfgXglFXrJGQUp4ocIyPUBFJ/B7Fw +o9BWmjHnlYhZxX6UQYAj3ATib4tV8Ol4nDS9Oci8bGQau/IVVP+eAN6N TJkr55UkZJs6uvujAhOZIxAGBClXlDcwftqBk5CiI7MULD5J0f5F9tuXT Q=; X-IronPort-AV: E=Sophos;i="4.63,338,1299456000"; d="scan'208";a="25219648" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 11 Apr 2011 10:05:06 +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 p3BA56fv021873; Mon, 11 Apr 2011 10:05:06 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); Mon, 11 Apr 2011 12:05:05 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Apr 2011 12:04:59 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 Thread-Index: Acv3O18lr+V8rc41SWGi8KmcG1jBSAA8eLyw References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Omprakash Gnawali" X-OriginalArrivalTime: 11 Apr 2011 10:05:05.0905 (UTC) FILETIME=[EE853610:01CBF82F] Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-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, 11 Apr 2011 10:05:10 -0000 Hi Om: > > Yes, MrHof uses metrics containers, whereas OF0 does not. But can a = Mr > > Hof implementation refrain from using containers and connect to an = OF0 > > network? IOW, what =A0does it take for an MrHof implementation be = able > > to attach to an OF0 network? What needs to be done - is it a simple > > tuning, complete rewrite? >=20 > We can change mrhof to use the rank advertised by of0 as the = advertised > path cost if there is no metric container. Then the network with mrhof = can [Pascal] Yes. I think that when there is no metric container, Mr Hof should operate = within the OF0 frame, and then: - explain that by default F(ETX) of the link is used for step-of-rank.=20 - describe F() - add the hysteresis logic - ... Which means that we need to agree of the constants in OF0 section 7. = Right now: - OF0 has a MAXIMUM_STEP_OF_RANK of 9 while Mr Hof has = MAX_LINK_METRIC of 10 - OF0 allows up to 28 hops even when default settings are used and each = hop has the worst Rank-increase of 9, while MrHof has only 10 hops = (MAX_PATH_METRIC: 100). Note that this comes from Phil's comment that 16 = was not enough. - Mr Hof does not have a MINIMUM_STEP_OF_RANK - Mr Hof does not have a Rank Factor=20 I think you should align all these constants to OF0 and point onto OF0 = for their definitions. I can still change MAXIMUM_STEP_OF_RANK to 10 in = OF0 if that's important for your use cases. > compute additive metric based on that base cost. of0 would have no > difficulty using the rank computed by mrhof. So, with that little = tweak above, > we can make mrhof and of0 networks interoperate. The interoperation, [Pascal] It is not about interoperation between a Mr Hof DAG and an OF0 = DAG. Right now we do not really try to do that. It is about the fact that an implementation of Mr Hof can claim = compliance to OF0, which is a MUST in RPL. As opposed to having to = implement 2different OFs. > however, will not be ideal. If there are multiple connection points = between a > mrhof and an of0 networks, the metric minimization algorithm will = compute > the lowest ranks assuming homogeneous metric because downstream > nodes in a mrhof network don't know what fraction of the path cost is = due to > rank from of0. [Pascal] Agreed. Things work better when the metrics are passed in = containers. > > Also I wonder, should a Mr Hof implementation support all the = metrics > > that are listed? If not, then how does a node know if it can = actually > > work with the metrics in use in a Mr Hof network? >=20 > I have this text for now: >=20 > " Node rank is undefined for these node/link metrics: Node state and > attributes, throughput, and link color." >=20 > We can set the rank to max rank in case of unsupported metrics? [Pascal] No I think that you need to - MUST support certain metric containers (give the list) - MAY/SHOULD others to hint an implementation that they are considered = useful to support - MUST not switch containers in flight. Root decides, routers propagate = the same containers with updated metrics, leaves are free to ignore - MUST act as a leaf when not supporting the container that's decided by = the root : ) [Pascal]=20 From nicolas.dejean.ietf@googlemail.com Mon Apr 11 03:08: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 B849C3A6AF5 for ; Mon, 11 Apr 2011 03:08:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwdUHrqcNM5R for ; Mon, 11 Apr 2011 03:08:36 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 6BC553A6AA6 for ; Mon, 11 Apr 2011 03:08:33 -0700 (PDT) Received: by wyb29 with SMTP id 29so5120896wyb.31 for ; Mon, 11 Apr 2011 03:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=8o5WWxJEmEkkmmO5+v/uRuy+0XLxDpbVORnzIq9vC60=; b=NMxtmv/LJhi7jCxc4HZhTsqwPpmTHSXiiw1Op/L+Ydq00j+NY1ivBMc1dFce1XDuCS YlagmfqluT23g73K1Xb7GXpqreVqs7R/s1ObLh3XTxwyiKNKNy2uuZZoC/+oyfqvw3fm rp+xNi8gqOyYulkt9rf9j81ar/t7XgWrC5tBo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xidRuDqODGQLQpIJ/X1mTuRggs0Lv/y4N5bAc8tOufFOotCXHzI7EVOf8IjE8W1RkA jJUr8QW206Re+BrK0xkKwgw2RRm7ehZ0pj8hJVNANQTY0GqoTipKC5mMA9KmlfHcOZ2A LrIUvU9BMlN74CpvXr0r2MWd6CF6Fl2gz0S94= MIME-Version: 1.0 Received: by 10.216.62.129 with SMTP id y1mr494173wec.61.1302516512966; Mon, 11 Apr 2011 03:08:32 -0700 (PDT) Received: by 10.216.180.18 with HTTP; Mon, 11 Apr 2011 03:08:32 -0700 (PDT) In-Reply-To: <913549B1-D3E8-4357-BFA7-4905F377EDC3@cisco.com> References: <43AEA790-8199-4A86-A318-4963713CD991@cisco.com> <913549B1-D3E8-4357-BFA7-4905F377EDC3@cisco.com> Date: Mon, 11 Apr 2011 12:08:32 +0200 Message-ID: From: Nicolas DEJEAN To: jpv@cisco.com Content-Type: text/plain; charset=ISO-8859-1 Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 10:08:37 -0000 Dear all, RPL-P2P is a must for several markets (HBA fr instance). This measurement method is necessary for finding "good enough" routes and this draft deserves to be normative for RPL-P2P. So, Yes, it should become a working group document. Cheers, Nicolas. 2011/4/8 Jonathan Hui : > > +1 > > -- > Jonathan Hui > > On Mar 31, 2011, at 9:56 PM, JP Vasseur wrote: > >> Dear all, >> >> draft-goyal-roll-p2p-measurement has been discussed on the mailing list and is a normative >> reference of the P2P document. >> >> Could you tell us if you are in favor/opposed to adopt draft-goyal-roll-p2p-measurement-01 as >> a ROLL Working Group document ? >> >> Thanks. >> >> JP. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pal@cs.stanford.edu Mon Apr 11 03: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 960A33A6AF7 for ; Mon, 11 Apr 2011 03:21:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEPCQ3e63SrF for ; Mon, 11 Apr 2011 03:21:20 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 10D343A69EB for ; Mon, 11 Apr 2011 03:21:20 -0700 (PDT) Received: from [141.201.223.151] by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Q9EFD-0008Mm-UW; Mon, 11 Apr 2011 03:21:20 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <43AEA790-8199-4A86-A318-4963713CD991@cisco.com> Date: Mon, 11 Apr 2011 12:21:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <0D8537DE-7F25-4C58-B1F3-B05BC8A54A2F@cs.stanford.edu> References: <43AEA790-8199-4A86-A318-4963713CD991@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1084) X-Scan-Signature: a1ccd6d2fa83ef575f7b7817ead66a1e Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 10:21:20 -0000 On Apr 1, 2011, at 6:56 AM, JP Vasseur wrote: > Dear all, >=20 > draft-goyal-roll-p2p-measurement has been discussed on the mailing = list and is a normative > reference of the P2P document. >=20 > Could you tell us if you are in favor/opposed to adopt = draft-goyal-roll-p2p-measurement-01 as=20 > a ROLL Working Group document ? I support making draft-goyal-roll-p2p-measurement a ROLL WG document. Phil= From pthubert@cisco.com Mon Apr 11 03:25:44 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 7172928C0EB for ; Mon, 11 Apr 2011 03:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.424 X-Spam-Level: X-Spam-Status: No, score=-10.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 zUuXITcV2YDv for ; Mon, 11 Apr 2011 03:25:42 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 88BFC3A6AFA for ; Mon, 11 Apr 2011 03:25:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1931; q=dns/txt; s=iport; t=1302517543; x=1303727143; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ejpLGWITAiyzcvwaavh3yJyP8E5F2P+KEo2eFHD5LPQ=; b=jLFOY07euZCMbkEydaR0kjwWwyyoMeYHB3TgJ9O8Wygb8WIb0KpvwIK1 oKKwBLvLAoiHIrLeawdaTZPqVxzx0uo6dK8TUZDqIz/Qq0Z+hG/prXDRs yCPXIW2VMcPA9OgBWRALWd50gNNGPGzh2jOYg1P/gCgYHrm5uYhG4pHxa 4=; X-IronPort-AV: E=Sophos;i="4.63,338,1299456000"; d="scan'208";a="83046191" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 11 Apr 2011 10:25:42 +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 p3BAPgND027437; Mon, 11 Apr 2011 10:25:42 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); Mon, 11 Apr 2011 12:25:41 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 11 Apr 2011 12:24:24 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D044F835A@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 Thread-Index: Acv3d6sBUFGywjOaQDOCgXg+r7/HfQAuEzsw References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Omprakash Gnawali" X-OriginalArrivalTime: 11 Apr 2011 10:25:41.0978 (UTC) FILETIME=[CF46FBA0:01CBF832] Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-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, 11 Apr 2011 10:25:44 -0000 Parent set size and STRETCH of Rank are antagonistic goals. OF0 started with the conservative approach to allow a stretch only to get a sibling, but did not allow a node A to stop being a potential next hop for a node B by stretching below that node B. Which is in essence the greediness problem. This goes along the general recommendation in RPL section 14. Phil convinced me that we need OF0 to be more generic and allow a stretch. But then the implementation has to be very careful to make sure that when A stretches its rank, it does not cause B to be deprived of a (its 3rd in your case) parent. It's the same problem as the MaxRankIncrease in RPL. It is fine for A to go down to attach to B if B is not in A's subdag, but harmful and source of Count to Infinity if B is in A's subdag.=20 Trouble is that A does not know. The STRETCH of Rank and the MaxRankIncrease are both mechanism to control how deep the CTI goes; but it is still a bad idea when it happens and we allow deployments to turn it off. In any case you probably have to choose between making a number of parent a desirable goal for the OF, and allow stretch. Otherwise you're prone to see domino effects.=20 To judge that I'll need to see how you word the equivalent of OF 0 section 4/5. Right now it is a bit unclear to me: do you inherit them from OF0, if not what's the delta? Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Omprakash Gnawali [mailto:gnawali@cs.stanford.edu] > Sent: Sunday, April 10, 2011 2:06 PM > To: Pascal Thubert (pthubert) > Cc: JP Vasseur; ROLL WG > Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 >=20 > Regarding parent set - I am planning to suggest a parent set of size 3. It will > be a SHOULD because this might not be too big in a very sparse network. > Please send your comments. >=20 > - om_p From phoebus@ieee.org Mon Apr 11 03:28:15 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 C121E3A6AFA for ; Mon, 11 Apr 2011 03:28:15 -0700 (PDT) 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_SE=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 18NDsJMsEb5W for ; Mon, 11 Apr 2011 03:28:14 -0700 (PDT) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 8EC143A69EB for ; Mon, 11 Apr 2011 03:28:13 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id B2006156438; Mon, 11 Apr 2011 12:27:42 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id Bu2YzCqecPrt; Mon, 11 Apr 2011 12:27:40 +0200 (CEST) X-KTH-Auth: phoebus [2001:6b0:1:12b0:223:dfff:fe92:5e5c] X-KTH-mail-from: phoebus@ieee.org Received: from dhcp-50-7.s3.kth.se (unknown [IPv6:2001:6b0:1:12b0:223:dfff:fe92:5e5c]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 62B431563F9; Mon, 11 Apr 2011 12:27:38 +0200 (CEST) Message-ID: <4DA2D799.8090005@ieee.org> Date: Mon, 11 Apr 2011 12:27:37 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Omprakash Gnawali References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <4D95E56C.9070009@ieee.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "roll@ietf.org" Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 10:28:15 -0000 Omprakash, Responses are inline below. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 4/10/11 6:40 AM, Omprakash Gnawali wrote: > On Fri, Apr 1, 2011 at 7:47 AM, Phoebus Chen wrote: >> JP, >> >> I suppose draft-ietf-roll-minrank-hysteresis-of-02 will be made >> available online soon? Or is this a last call regarding >> draft-ietf-roll-minrank-hysteresis-of-01? > > The last call is on -01. > > > >> 1) As I understand from Table 1 and the mention of node metrics in the >> second paragraph of the introduction, MRHOF also supports node metrics. >> However, in various places throughout the document, you refer to the >> "selected metric for the link..." . I point out where I spot this below. >> When using node metrics, I presume the node adds it's own node metric value >> to the advertised metric from its candidate neighbor to get the path cost? > > Yes. Would it be better to say near the top that the discussion uses > the phrase link metric but all the discussions also apply to node > metric or use the phrase link or node metric throughout the text? > I think either approach is fine (if you choose the latter, you may also use "link (node)" if you think "link or node" is too much text). On related note, I'm wondering if it's necessary to emphasize in the introduction that a node adds its own node metric to the aggregate before checking for parent selection (basically, emphasize that the steps in the subsections of section 3 MUST be followed in that order). Just for consistency amongst the nodes if they come from different vendors. An implementor might think it doesn't matter since the addition of the node's own metric doesn't change the parent selection. What do you think? > > >> 2) In Section 3, you write "MRHOF cannot be used if the routing objective is >> to maximize the metric." Those from the optimization community may be a >> little puzzled, because you can just negate the objective function to >> convert it from a maximization problem to a minimization problem. >> >> Let's assume you wish to maximizing the product of link probabilities along >> a path. Then, you can use log(p) which results in only negative link >> metrics (so still monotonic). And instead of MIN_PATH_COST, you start with >> a MAX_PATH_REWARD of 0 and add the negative link metrics. I don't see any >> of the MRHOF mechanisms breaking here (with some minor tweaks of switching >> "minimize" to "maximize"). Am I missing something? >> >> As I understand, limiting MRHOF to minimization makes the explanations >> easier and the terminology / constant names more consistent. But are you >> restricting the scope of the OF too much here? > > > Yes. Another way way converting maximization to minimization is by > computing a reciprocal of the metric. Would it be adequate to include > a subsection that describes how to convert maximization metric to a > minimization metric so that we can use mrhof? I think the most common > use of mrhof will be with something like etx so I hesitate to make the > draft too general which will make force the implementers of the most > common case to have to read a lot of generalizations. > > If we want to use mrhof with maximization metrics by converting them > to minimization, we need to standardize how to do this conversion so > that two mrhof implementations can interoperate. One option is to use > negative metric another is computing a reciprocal. We need to pick > one. > Yes, I think your suggestion about writing a subsection describing how to convert the maximization metric to a minimization metric is the best approach, rather what I had written above. Maybe you can mention that the key point for determining whether you can convert the maximization problem to a minimization problem that MRHOF can handle is that there is a known, fixed bound on the optimum that is the value taken on by the root (corresponding to MIN_PATH_COST), and the additive link (node) costs are all the same sign (negative in the maximization problem, positive in the minimization problem). I would certainly prefer negating the metric. Taking the reciprocal of the entire path metric is more complicated to describe (you are advertising the denominator in the DIO messages so you don't have round off / quantization errors, and then you take the reciprocal for comparisons for parent selection). If by taking the reciprocal you mean the reciprocal of each individual link (node) metric, this would rescale the metrics and yield a different topology when you try to maximize the path metric. I'm sure you know this already, but for the others following this thread on the mailing list: just look at building a tree that minimizes ETX vs. a tree that maximizes path probability (ex. root = A, probability of links BA = 0.9, CB = 0.9, CA = 0.5; ETX will have path CA, path probability will have path CBA). > >> 3) Are the parent selection rules in any way affected by minHopRankIncrease, >> mentioned in (draft-ietf-roll-rpl-19, Section 3.5.2. Rank Relationships)? >> Should minHopRankIncrease always be set to 1 for MRHOF? In Table 1, you >> discuss how to convert various metrics into rank, but make no mention of >> minHopRankIncrease. (draft-ietf-roll-rpl-19, Section 3.5.1 Rank Comparison >> (DAGRank()) ) says: >> >> "MinHopRankIncrease is the minimum increase in rank between a node and any >> of its DODAG parents." > > Good point. We should put a requirement saying RPL minHopRankIncrease > should be 1 because depending on the metric, mrhof computes the rank > at the granularity of 1. What is the best section to put such > requirements? > Hmm, I can't see a nice way to add it to the intro paragraph of Section 3 as it is written now. I would mention it both in Section 3.2 and 3.3. It really belongs in Section 3.3, but the reader first needs to consider this in 3.2. In Section 3.2, maybe just a sentence that we assume that minHopRankIncrease = 1, so the considerations in draft-ietf-roll-rpl-19, Section 3.5.1 do not impose additional constraints on the parent selection rules. > > >> As I understand, PARENT_SWITCH_THRESHOLD plays the role of "coarsening" the >> metric, which was originally done by the DAGRank() function for rank >> comparisons. The way I understand the properties of rank described in >> (draft-ietf-roll-rpl-19, Section 3.5. Rank Properties) and from earlier >> discussions on the mailing list, coarsening the rank is for stability. >> DAGRank() may not do such a good job when two path-cost-to-root's advertised >> by candidate neighbors are less than PARENT_SWITCH_THRESHOLD apart but they >> result in different rank (e.g., DAGRank(A)> DAGRank(B)). This is why we >> have MRHOF, right? > > MRHOF will compute the rank based on the metrics. I believe the rank > you are talking about is more like hop-count Rank? > No, I was just pointing out that maybe the rules in (draft-ietf-roll-rpl-19, Section 3.5. Rank Properties) are redundant given the PARENT_SWITCH_THRESHOLD in MRHOF. In any case, if we set minHopRankIncrease = 1, we won't be applying two sets of rules to achieve the same effect of coarsening the metric. > I processed all your editorial comments. > > Thanks for all the comments. > > - om_p Sure! Thanks for incorporating them. From jpv@cisco.com Mon Apr 11 07:28: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 BDD6228C126 for ; Mon, 11 Apr 2011 07:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.535 X-Spam-Level: X-Spam-Status: No, score=-110.535 tagged_above=-999 required=5 tests=[AWL=0.063, 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 NpjPEIgtFrHq for ; Mon, 11 Apr 2011 07:28:37 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C47A528C0F5 for ; Mon, 11 Apr 2011 07:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=3689; q=dns/txt; s=iport; t=1302532117; x=1303741717; h=from:subject:date:message-id:to:mime-version; bh=+YlJYax09iGJEbgpIfPBg1rlvFzQ04+CW0L4FVKNUik=; b=EvgrNUYgX2pR/c9UiC/oU3ljXSkLGs7ccGwIZfODjP/oy+a3CPTevhVT eio74wTYXwN+3FzTfApTd/k++qy6cmEjEngHWBUCceDBQM5wLBVDs2bOi J+U7Mo5yXoF6uOlJY8LFLapu7nj0w9cMXV18sc7dJexHk3vMri+Vx2/A5 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8EABMPo02Q/khNgWdsb2JhbACCYaM5FAEBFiYlpjSbd4VuBI1Yg2oH X-IronPort-AV: E=Sophos;i="4.63,339,1299456000"; d="scan'208,217";a="83089814" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 11 Apr 2011 14:28:36 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3BESYtb018687 for ; Mon, 11 Apr 2011 14:28:36 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 22:27:11 +0800 Received: from [10.60.114.229] ([10.60.114.229]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 22:27:10 +0800 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-28--45201877 Date: Mon, 11 Apr 2011 16:27:08 +0200 Message-Id: To: "roll@ietf.org WG" Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 11 Apr 2011 14:27:10.0768 (UTC) FILETIME=[8B44E300:01CBF854] Subject: [Roll] Two New ROLL Working Documents 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, 11 Apr 2011 14:28:37 -0000 --Apple-Mail-28--45201877 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Dear WG, This is to inform of the adoption of two new WG documents: 1) draft-goyal-roll-p2p-measurement-01 => draft-ietf-roll-p2p-measurement-00 8 in favor, 1 not in favor, so we have a strong consensus. 2) draft-hui-6man-trickle-mcast-01 => draft-ietf-roll-trickle-mcast-00 all in favor. Authors, please resubmit with no change other than names, titles and dates. Thanks. JP. --Apple-Mail-28--45201877 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear WG,

This is to inform of the = adoption of two new WG documents:

1) draft-goyal-roll-p2p-measurement-01 = =3D> draft-ietf-roll-p2p-measurement-00
=
8 in favor, 1 not in favor, so = we have a strong consensus.

2) draft-hui-6man-trickle-mcast-01 = =3D> draft-ietf-roll-trickle-mcast-00

all in = favor.

Authors, please resubmit with = no change other than names, titles and = dates.

Thanks.

JP.

= --Apple-Mail-28--45201877-- From Internet-Drafts@ietf.org Mon Apr 11 08:30: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 CDFE03A697E; Mon, 11 Apr 2011 08:30:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 gYvksfhzsjuC; Mon, 11 Apr 2011 08:30:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2288B3A6A72; Mon, 11 Apr 2011 08:30:02 -0700 (PDT) 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.16 Message-ID: <20110411153002.21991.29675.idtracker@localhost> Date: Mon, 11 Apr 2011 08:30:02 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-p2p-measurement-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 15:30: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 : A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network Author(s) : M. Goyal, et al. Filename : draft-ietf-roll-p2p-measurement-00.txt Pages : 14 Date : 2011-04-11 This document specifies a mechanism that enables an RPL node to measure the quality of an existing route to/from another RPL node in a low power and lossy network, thereby allowing the node to decide if it wants to initiate the discovery of a more optimal route. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-p2p-measurement-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-11082250.I-D@ietf.org> --NextPart-- From jpv@cisco.com Mon Apr 11 09:00:12 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 6CA5828C147 for ; Mon, 11 Apr 2011 09:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.521 X-Spam-Level: X-Spam-Status: No, score=-110.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 ggr2n8AqFv2x for ; Mon, 11 Apr 2011 09:00:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 3FE6628C134 for ; Mon, 11 Apr 2011 09:00:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=1125; q=dns/txt; s=iport; t=1302537611; x=1303747211; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=HvagFZP+ZGHqjfTi9dSuyZgh5t/Od69sAeDLo6qRAp4=; b=TshsK3ZDCIzg0sQiXpC2OP0eyrl1ZGsgPBfozdHJ0jXdDRHcauT9C0Md V9hCr4qpCCUumWB5qH/FTqYsvpw6eIq61gh89WfpodVdaitprUd6elQSX eP9EKEATORFEFPaVHMba2q7I+78+aT0bNj2xqOr7XkfJq25zZiZeyZnws A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAE4ko02rRDoG/2dsb2JhbACmGneIep1nnA+FbgSNWINqB4ka X-IronPort-AV: E=Sophos;i="4.63,339,1299456000"; d="scan'208";a="427567991" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 11 Apr 2011 16:00:10 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3BG0AqJ017101; Mon, 11 Apr 2011 16:00:10 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 09:00:10 -0700 Received: from [10.60.114.229] ([10.60.114.229]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 11 Apr 2011 09:00:09 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> Date: Mon, 11 Apr 2011 18:00:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> To: Omprakash Gnawali , Philip Levis X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 11 Apr 2011 16:00:09.0910 (UTC) FILETIME=[88B26560:01CBF861] Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-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, 11 Apr 2011 16:00:12 -0000 Hi, WG Last Call on draft-ietf-roll-minrank-hysteresis-of-01 is now over.=20 Several comments were made during the WG Last Call. Authors, could you please update the document, post the new revision and send a email to = the lists summarizing the changes and making sure that all comments have = been addressed ? Thanks. JP. On Apr 1, 2011, at 6:13 AM, JP Vasseur wrote: > Dear all, >=20 > draft-ietf-roll-minrank-hysteresis-of has been discussed for quite = some time,=20 > the document is stable and is now ready for Working Group Last Call. = As discussed > during the WG meeting yesterday, there a very questions to address. >=20 > This starts a 2-week WG Last call on = draft-ietf-roll-minrank-hysteresis-of-02=20 > that will end on April 11 at noon ET (this is a bit more than 2 weeks, = considering > most of us flying back end of this week). >=20 > Please send your comments to the authors and copy the mailing list. >=20 > Thanks. >=20 > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Internet-Drafts@ietf.org Mon Apr 11 09:15: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 36ED128C13F; Mon, 11 Apr 2011 09:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 ri2dqTdUikPY; Mon, 11 Apr 2011 09:15:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5893B28C12F; Mon, 11 Apr 2011 09:15:02 -0700 (PDT) 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.16 Message-ID: <20110411161502.2668.56179.idtracker@localhost> Date: Mon, 11 Apr 2011 09:15:02 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-trickle-mcast-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 16:15: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 : Multicast Forwarding Using Trickle Author(s) : J. Hui, R. Kelsey Filename : draft-ietf-roll-trickle-mcast-00.txt Pages : 19 Date : 2011-04-11 Low power and Lossy Networks (LLNs) are typically composed of resource constrained nodes communicating over links that have dynamic characteristics. Memory constraints coupled with temporal variations in link connectivity makes the use of topology maintenance to support IPv6 multicast challenging. This document describes the use of Trickle to efficiently forward multicast messages without the need for topology maintenance. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-trickle-mcast-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-trickle-mcast-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-11091300.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Mon Apr 11 10:00: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 237F23A68DC; Mon, 11 Apr 2011 10:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.592 X-Spam-Level: X-Spam-Status: No, score=-102.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 w87kFUzYYzwi; Mon, 11 Apr 2011 10:00:06 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8ED673A6B28; Mon, 11 Apr 2011 10:00:05 -0700 (PDT) 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.16 Message-ID: <20110411170005.14339.42144.idtracker@localhost> Date: Mon, 11 Apr 2011 10:00:05 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-of0-10.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, 11 Apr 2011 17:00: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 : RPL Objective Function 0 Author(s) : P. Thubert Filename : draft-ietf-roll-of0-10.txt Pages : 10 Date : 2011-04-11 The Routing Protocol for Low Power and Lossy Networks (RPL) defines a generic Distance Vector protocol that is adapted to such networks. RPL requires a specific Objective Function to establish a desired routing topology. This document specifies a basic Objective Function that relies only on RPL's basic Protocol Data Units; it does not use extensions such as RPL metric containers. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-10.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-of0-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-11094836.I-D@ietf.org> --NextPart-- From phoebus@ieee.org Mon Apr 11 11:27:51 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 EC0C93A6A67 for ; Mon, 11 Apr 2011 11:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.949 X-Spam-Level: X-Spam-Status: No, score=-106.949 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, J_CHICKENPOX_22=0.6, 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 Glw8W7m4KO9S for ; Mon, 11 Apr 2011 11:27:49 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id 2A34B3A6A47 for ; Mon, 11 Apr 2011 11:27:48 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 704FE14EA27; Mon, 11 Apr 2011 20:27:17 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id DgzW6AW2BQ+a; Mon, 11 Apr 2011 20:27:14 +0200 (CEST) X-KTH-Auth: phoebus [2001:6b0:1:12b0:223:dfff:fe92:5e5c] X-KTH-mail-from: phoebus@ieee.org Received: from dhcp-50-7.s3.kth.se (unknown [IPv6:2001:6b0:1:12b0:223:dfff:fe92:5e5c]) by smtp-2.sys.kth.se (Postfix) with ESMTP id AAD1414DC71; Mon, 11 Apr 2011 20:27:12 +0200 (CEST) Message-ID: <4DA347FF.6070503@ieee.org> Date: Mon, 11 Apr 2011 20:27:11 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "roll@ietf.org" , "Pascal Thubert (pthubert)" References: <20110405160002.12711.52229.idtracker@localhost> In-Reply-To: <20110405160002.12711.52229.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 18:27:52 -0000 Pascal, Sorry these comments are coming so late, after last call. I hope you can at least incorporate some of them. My comments below are based on my current understanding that Phil and you are no longer using hop-count as the rank increment. Instead, each node will have an implementation specific way of converting a node or link cost to a rank. I'm still unclear if there is a preference rule to try to stick with using the same metrics as the metrics advertised in a received DIO, if the current node has access to multiple types of metrics (energy, LQI, ETX, etc.). That would allow the root node to specify a preferred type of metric to use in the instance. Major Points: ************* 1) I'm still hoping that the format for writing Objective Function specifications can be more uniform, as I mentioned in an earlier comment (point number 7 in http://www.ietf.org/mail-archive/web/roll/current/msg03240.html). Comparing MRHOF and OF0, I think that the discussion on Step-of-Rank / Stretch-of-Rank etc. can be moved to it's own subsection. I suggest the following reorganization of sections: 3. Objective Function 0 3.1. Computing Rank-increase 3.2. Parent / Backup Successor Selection 3.2.1. Selection of the Preferred Parent 3.2.2. Selection of the backup feasible successor 3.3. Advertising Rank-increase 4. Interface with RPL core If you are allowing the root to specified a preferred metric type, then Section 3.3. should state how to propagate this preference. I would have assumed it's by propagating an empty DAG/Metric Container, but in (Section 2.1, draft-ietf-roll-routing-metrics-19) it says "The object body carries one or more sub-objects defined later in this document" which means you cannot have empty containers. Maybe the overview in Section 3 should also state explicitly that the processing rules of a DIO must do 3.1, then 3.2, then 3.3, in that order. 2) There have been two variables and one parameter defined in the overview section, but they are not mentioned in Section 7, OF0 Constants and Variables. Variables: Step-of-Rank, Stretch-of-Rank Parameters: Rank-factor (I noticed that there is no MINIMUM_RANK_STRETCH and DEFAULT_RANK_STRETCH and presume this is intentional.) Also, it would be nice to use underscore instead of hyphen for variables, like in MRHOF (and use capital letters for parameters). Finally, how is Stretch-of-Rank computed? Implementation dependent? 3) How does one configure the parameter(s) (Rank-Factor) from the root? (I just realized that this same comment applies to the parameters in MRHOF as well). Or is that not configurable from the root, but must be configured before deployment of the nodes? 4) I think it would be nice to adopt the format of draft-ietf-roll-rpl-19 and draft-ietf-roll-minrank-hysteresis-of for the Terminology section. That is, write the word, then the definition (this is not done for "feasible successor" in this section). Some other words to define in this section are "Rank-increase," "RPL core," and "higher order interface." Unless the last one is common IPv6 terminology that I am unaware of... I was unable to tell if that meant the higher order bits of the interface are higher, or if the interface is somehow preferred. 5) Just a reminder that the discussion on Rank-increase in the introduction section "OF0 uses a unit of Rank-increase of 0x100 so that Rank value can be stored in one octet." needs to be aligned with text in Section 3, "Ri = Rf*Sp + Sr" so that they are consistent. I see you are discussing this with Omprakash. 6) I like the "Abstract Interface with RPL core" section, but would it be better to separate them into "Input" and "Output"? That would end up splitting up "Providing DAG information" and "Providing a Parent List" into two pieces though. More minor editorial comments to follow below, preceded by PC>. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus ROLL P. Thubert, Ed. Internet-Draft Cisco Systems Intended status: Standards Track April 5, 2011 Expires: October 7, 2011 RPL Objective Function 0 draft-ietf-roll-of0-09 Abstract The Routing Protocol for Low Power and Lossy Networks defines a generic Distance Vector protocol for Low Power and Lossy Networks. That generic protocol requires a specific Objective Function to establish a desired routing topology. This specification defines a basic Objective Function that operates solely with the protocol elements defined in the generic protocol specification. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on October 7, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Thubert Expires October 7, 2011 [Page 1] Internet-Draft draft-ietf-roll-of0 April 2011 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Objective Function 0 Overview . . . . . . . . . . . . . . . . 4 4. Selection of the Preferred Parent . . . . . . . . . . . . . . 6 5. Selection of the backup feasible successor . . . . . . . . . . 7 6. Abstract Interface with RPL core . . . . . . . . . . . . . . . 7 7. OF0 Constants and Variables . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Thubert Expires October 7, 2011 [Page 2] Internet-Draft draft-ietf-roll-of0 April 2011 1. Introduction The IETF ROLL Working Group has defined application-specific routing requirements for a Low Power and Lossy Network (LLN) routing protocol, specified in [RFC5548], [RFC5673], [RFC5826], and [RFC5867]. The Routing Protocol for Low Power and Lossy Networks [I-D.ietf-roll-rpl] was designed as a generic core that is agnostic to metrics and that is adapted to a given problem using Objective Functions (OF). This separation of Objective Functions from the core protocol specification allows RPL to adapt to meet the different optimization criteria the wide range of use cases requires. PC> s/the wide range of use cases requires/required by the wide range of use cases/ RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) within instances of the protocol. Each instance is associated with an Objective Function that is designed to solve the problem that is addressed by that instance. PC> remove "that is designed to solve the problem that is addressed by that instance". Sounds almost like a tautology. An Objective Function selects the DODAG Version that a device joins, and a number of neighbor routers within that Version as parents or feasible successors. The OF generates the Rank of the device, that represents an abstract distance to the root within the DODAG. In turn, the Rank is used by the generic RPL core to enable a degree of loop avoidance and verify forward progression towards a destination, as specified in [I-D.ietf-roll-rpl]. PC> Do you intend to capitalize "Rank" and "Version" here? The Objective Function 0 (OF0) corresponds to the Objective Code Point 0 (OCP0). OF0 only requires the information in the RPL DIO base container, such as Rank and the DODAGPreference field that describes an administrative preference [I-D.ietf-roll-rpl]. The Rank of a node is obtained by adding a normalized scalar Rank-increase to PC> s/Rank-increase/, Rank-increase,/ the Rank of a selected preferred parent. OF0 uses a unit of Rank- increase of 0x100 so that Rank value can be stored in one octet. This allows up to at least 28 hops even when default settings are used and each hop has the worst Rank-increase of 9. Since there is no default OF or metric container in the RPL main specification, it might happen that, unless given two implementations PC> s/given two/two given/ follow a same guidance for a specific problem or environment, those PC> s/a same/the same/ implementations will not support a common OF with which they could interoperate. OF0 is designed to be used as a common denominator PC> I'm not sure what you mean by "common denominator" here. Are you just trying to say that OF0 must be supported by all implementations of RPL? What is a "generic implementation"? between all generic implementations. This is why it is very abstract as to how the link properties are transformed into a Rank-increase and leaves that responsibility to implementation; rather, OF0 enforces normalized values for the Rank-increase of a normal link and its acceptable range, as opposed to formulating the details of the PC> s/details of the/details of/ its computation. This is also why OF0 ignores metric containers. Thubert Expires October 7, 2011 [Page 3] Internet-Draft draft-ietf-roll-of0 April 2011 2. Terminology The terminology used in this document is consistent with and incorporates that described in `Terminology in Low power And Lossy Networks' [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. The term feasible successor is used to refer to a neighbor that can possibly be used as a next-hop for upwards traffic following the loop avoidance and forwarding rules that the nodes implements and that are defined outside of this specification, in particular in the RPL specification. PC> Remove "that the nodes implements and that are defined outside of this specification, in particular" 3. Objective Function 0 Overview The core RPL specification describes constraints on how nodes select potential parents, called a parent set, from their neighbors. All parents are feasible successors for upgoing traffic (towards the root). Additionally, RPL allows the use of parents in a subsequent Version of a same DODAG as feasible successors, in which case this PC> again, capitalize Version? node acts as a leaf in the subsequent DODAG Version. Further specifications might extend the set of feasible successors, for instance to nodes of a same Rank, aka siblings. The Goal of the OF0 is for a node to join a DODAG Version that offers connectivity to a specific set of nodes or to a larger routing infrastructure. For the purpose of OF0, Grounded thus means that the root provides such connectivity. How that connectivity is asserted and maintained is out of scope. Objective Function 0 is designed to find the nearest Grounded root. This can be achieved if the Rank of a node represents closely its distance to the root. This need is balanced with the other need of maintaining some path diversity. In the absence of a Grounded root, LLN inner connectivity is still desirable and floating DAGs will form, rooted at the nodes with the highest administrative preference. PC> the above two paragraphs can be combined. OF0 selects a preferred parent and a backup feasible successor if one is available. All the upward traffic is normally routed via the preferred parent. When the link conditions do not let an upward packet through the preferred parent, the packet is passed to the backup feasible successor. PC> Replace "When the link conditions do not let an upward PC> packet through the preferred parent" PC> with PC> "When a node is unable to send a packet trough the preferred parent". OF0 assigns a Step-of-Rank to each link to another node that it PC> remove "to another node" monitors. The exact method for computing the Step-of-Rank is implementation-dependent. Thubert Expires October 7, 2011 [Page 4] Internet-Draft draft-ietf-roll-of0 April 2011 One trivial OF0 implementation might compute the Step-of-Rank from as PC> remove "as" a classical administrative cost that is assigned to the link. Using a metric similar to hop count implies that the OF0 implementation PC> "classical administrative cost" refers to "hop count" here? It's not clear from the writing. only considers neighbors with good enough connectivity, for instance neighbors that are reachable over an Ethernet link, or a WIFI link in PC> s/WIFI/WiFi/ infrastructure mode. In most wireless networks, a Rank that is analogous to an unweighted hop count favors paths with long distance links and poor connectivity properties. Other link properties such as the expected transmission count metric (ETX) [DeCouto03] should be used instead to compute the Step-of-Rank. For instance, the Minimum Rank Objective Function with Hysteresis [I-D.ietf-roll-minrank-hysteresis-of] provides guidance on how link cost can be computed and on how hysteresis can improve Rank stability. An implementation MAY allow to stretch the Step-of-Rank with a Stretch-of-Rank up to no more than MAXIMUM_RANK_STRETCH in order to enable the selection of a feasible successor in order to maintain some path diversity. The use of a Stretch-of-Rank augments the apparent distance from the node to the root and distorts the DODAG; it should be used with care so as to avoid instabilities due to greedy behaviours. The Step-of-Rank is expressed in units of MINIMUM_STEP_OF_RANK. As a result, the least significant octet in the RPL Rank is not used. The default Step-of-Rank is DEFAULT_STEP_OF_RANK for each hop. An implementation MUST maintain the stretched Step-of-Rank between MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK, which allows to reflect a large variation of link quality. PC> Remove ", which allows to reflect a large variation of link PC> quality." If you wish to point out that stretch of rank may be PC> computed from link quality, this should be mentioned earlier where PC> you point out that the exact method for computing it is PC> implementation-dependent. The gap between MINIMUM_STEP_OF_RANK and MAXIMUM_RANK_STRETCH may not be sufficient in every case to strongly distinguish links of different types or categories in order to favor, say, powered over battery-operated or wired over wireless, within a same DAG. An PC> s/a same DAG/the same DAG/ implementation SHOULD allow a configurable factor called Rank-factor and to apply the factor on all links and peers. An implementation MAY recognizes sub-categories of peers and links, such as different MAC types, in which case it SHOULD be able to configure a more specific Rank-factor to those categories. The Rank- factor SHOULD be set between MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR. The Step-of-Rank Sp that is computed for that PC> I though "Sp" was a typo. s/Sp that is computed/, Sp, computed/ link s multiplied by the Rank-factor Rf and then possibly stretched PC> s/Rf/,Rf,/; s/link s/link is/ by a Stretch-of-Rank Sr. The resulting Rank-increase Ri is added to PC> s/ Sr/, Sr/; s/ Ri/, Ri,/; And so forth below, you get the idea. the Rank of preferred parent R(P) to obtain that of this node R(N): PC> s/obtain that of this node/obtain the rank of the current node/ R(N) = R(P) + Ri where Ri = Rf*Sp + Sr. PC> Insert comma and space for readability, PC> R(N) = R(P) + Ri, where Ri = Rf*Sp + Sr. Thubert Expires October 7, 2011 [Page 5] Internet-Draft draft-ietf-roll-of0 April 2011 Optionally, the administrative preference of a root MAY be configured to supersede the goal to join a Grounded DODAG. In that case, nodes will associate to the root with the highest preference available, regardless of whether that root is Grounded or not. Compared to a deployment with a multitude of Grounded roots that would result in a same multitude of DODAGs, such a configuration may result in possibly PC> remove "same" less but larger DODAGs, as many as roots configured with the highest priority in the reachable vicinity. PC> I don't understand "as many as roots configured with the highest PC> priority in the reachable vicinity." Is that necessary? 4. Selection of the Preferred Parent As it scans all the candidate neighbors, OF0 keeps the parent that is the best for the following criteria (in order): 1. [I-D.ietf-roll-rpl] spells out the generic rules for a node to reparent and in particular the boundaries to augment its Rank within a DODAG Version. A candidate that would not satisfy those rules MUST NOT be considered. 2. An implementation should validate a router prior to selecting it as preferred. This validation process is implementation and link type dependent, and is out of scope. A router that has been validated is preferable. 3. When multiple interfaces are available, a policy might be locally configured to prioritize them and that policy applies first; that is a router on a higher order interface is preferable. 4. If the administrative preference of the root is configured to supersede the goal to join a Grounded DODAG, a router that offers connectivity to a more preferable root SHOULD be preferred. 5. A router that offers connectivity to a grounded DODAG Version SHOULD be preferred over one that does not. 6. A router that offers connectivity to a more preferable root SHOULD be preferred. 7. When comparing 2 routers that belong to the same DODAG, a router that offers connectivity to the freshest Version SHOULD be preferred. 8. The parent that causes the lesser resulting Rank for this node SHOULD be preferred. Thubert Expires October 7, 2011 [Page 6] Internet-Draft draft-ietf-roll-of0 April 2011 9. A DODAG Version for which there is an alternate parent SHOULD be preferred. This check is optional. It is performed by computing the backup feasible successor while assuming that the router that is currently examined is finally selected as preferred parent. 10. The preferred parent that was in use already SHOULD be preferred. 11. A router that has announced a DIO message more recently SHOULD be preferred. 5. Selection of the backup feasible successor When selecting a backup feasible successor, the OF performs in order the following checks: 1. When multiple interfaces are available, a router on a higher order interface is preferable. 2. The backup feasible successor MUST NOT be the preferred parent. 3. The backup feasible successor MUST be either in the same DODAG Version as this node or in an subsequent Version. 4. Along with RPL rules, a Router in the same DODAG Version as this node and with a Rank that is higher than the Rank computed for this node MUST NOT be selected as a feasible successor. 5. A router with a lesser Rank SHOULD be preferred. 6. A router that has been validated as usable by an implementation dependant validation process SHOULD be preferred. 7. The backup feasible successor that was in use already SHOULD be preferred. 6. Abstract Interface with RPL core Objective Function 0 interacts with the core RPL in the following PC> s/core RPL/RPL core/ ways: Processing DIO: This core RPL triggers the OF when a new DIO was PC> s/This core RPL/The RPL core/ received. OF0 analyses the information in the DIO and may select the source as a parent or sibling. Thubert Expires October 7, 2011 [Page 7] Internet-Draft draft-ietf-roll-of0 April 2011 Providing DAG information The OF0 support can be required to provide PC> s/information/information:/ PC> s/The OF0 support can be required to/OF0 SHOULD/ the DAG information for a given instance to the RPL core. This includes the material that is contained in a DIO base header. PC> what is "material" referring to here? all the information PC> contained in a DIO base header? I suppose OF0 is tasked with PC> keeping all that information, not the RPL core? Providing a Parent List The OF0 support can be required to provide PC> s/List/List:/ PC> s/The OF0 support can be required to/OF0 SHOULD/ the ordered list of the parents and feasible successors for a given instance to the RPL core. This includes the material that is contained in the transit option for each entry. PC> same comment, maybe replace "material" with "all the information" Trigger The OF0 support may trigger the RPL core to inform it that PC> s/Trigger/Trigger:/ PC> s/The OF0 support may/OF0 SHOULD/ a change occurred. This can be used to indicate whether the change requires a new DIO to be fired or whether trickle timers need to be reset. 7. OF0 Constants and Variables OF0 uses the following constants: MinHopRankIncrease: 256 DEFAULT_STEP_OF_RANK: 3 * MinHopRankIncrease MINIMUM_STEP_OF_RANK: 1 * MinHopRankIncrease MAXIMUM_STEP_OF_RANK: 9 * MinHopRankIncrease MAXIMUM_RANK_STRETCH: 5 * MinHopRankIncrease DEFAULT_RANK_FACTOR: 1 MINIMUM_RANK_FACTOR: 1 MAXIMUM_RANK_FACTOR: 4 8. IANA Considerations This specification requires the assignment of an OCP for OF0. The value of 0 is suggested. 9. Security Considerations Security Considerations for OCP/OF are to be developed in accordance with recommendations laid out in, for example, Thubert Expires October 7, 2011 [Page 8] Internet-Draft draft-ietf-roll-of0 April 2011 [I-D.tsao-roll-security-framework]. 10. Acknowledgements Most specific thanks to Philip Levis for his help in finalizing this document, in particular WRT wireless links, to Tim Winter, JP PC> s/WRT/with respect to/ Vasseur, Julien Abeille, Mathilde Durvy, Teco Boot, Navneet Agarwal and Henning Rogge for in-depth review and first hand implementer's feedback. 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 11.2. Informative References [DeCouto03] De Couto, Aguayo, Bicket, and Morris, "A High-Throughput Path Metric for Multi-Hop Wireless Routing", MobiCom '03 The 9th ACM International Conference on Mobile Computing and Networking, San Diego, California,, 2003, . [I-D.ietf-roll-minrank-hysteresis-of] Gnawali, O. and P. Levis, "The Minimum Rank Objective Function with Hysteresis", draft-ietf-roll-minrank-hysteresis-of-01 (work in progress), February 2011. [I-D.ietf-roll-routing-metrics] Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. Barthel, "Routing Metrics used for Path Calculation in Low Power and Lossy Networks", draft-ietf-roll-routing-metrics-19 (work in progress), March 2011. [I-D.ietf-roll-rpl] Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., and J. Vasseur, "RPL: IPv6 Routing Protocol for Low power and Lossy Networks", draft-ietf-roll-rpl-19 (work in progress), March 2011. Thubert Expires October 7, 2011 [Page 9] Internet-Draft draft-ietf-roll-of0 April 2011 [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", draft-ietf-roll-terminology-05 (work in progress), March 2011. [I-D.tsao-roll-security-framework] Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A Security Framework for Routing over Low Power and Lossy Networks", draft-tsao-roll-security-framework-02 (work in progress), March 2010. [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, "Routing Requirements for Urban Low-Power and Lossy Networks", RFC 5548, May 2009. [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, "Industrial Routing Requirements in Low-Power and Lossy Networks", RFC 5673, October 2009. [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5826, April 2010. [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, "Building Automation Routing Requirements in Low-Power and Lossy Networks", RFC 5867, June 2010. Author's Address Pascal Thubert (editor) Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis 06410 FRANCE Phone: +33 497 23 26 34 Email: pthubert@cisco.com Thubert Expires October 7, 2011 [Page 10] From phoebus@ieee.org Mon Apr 11 11:38:53 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 833543A6A5C for ; Mon, 11 Apr 2011 11:38:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.424 X-Spam-Level: X-Spam-Status: No, score=-106.424 tagged_above=-999 required=5 tests=[AWL=-0.175, BAYES_00=-2.599, HELO_EQ_SE=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 YLFYkoc4BaFW for ; Mon, 11 Apr 2011 11:38:52 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by core3.amsl.com (Postfix) with ESMTP id D3ED53A69A0 for ; Mon, 11 Apr 2011 11:38:51 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id C52B914EA2C; Mon, 11 Apr 2011 20:38:21 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id Kcw6+ryOcVS5; Mon, 11 Apr 2011 20:38:20 +0200 (CEST) X-KTH-Auth: phoebus [2001:6b0:1:12b0:223:dfff:fe92:5e5c] X-KTH-mail-from: phoebus@ieee.org Received: from dhcp-50-7.s3.kth.se (unknown [IPv6:2001:6b0:1:12b0:223:dfff:fe92:5e5c]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 4B28214EA27; Mon, 11 Apr 2011 20:38:17 +0200 (CEST) Message-ID: <4DA34A99.3050508@ieee.org> Date: Mon, 11 Apr 2011 20:38:17 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Omprakash Gnawali References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <4D95E56C.9070009@ieee.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "roll@ietf.org" Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Apr 2011 18:38:53 -0000 Omprakash, I just realized when writing my last email to Pascal that maybe it would necessary to specify the messages for configuring the parameters Section 4, MRHOF Variables and Parameters? I presume it can be configured from the root. Also, depending on Pascal's response to my last email, maybe it would be nice to also have an "Interface with RPL core" section in MRHOF. Unless you both decide there is no need for that section. Following the format in (Section 6, draft-ietf-roll-of0-10), maybe you also need a "Provide Metrics" interface? (my last email was for version 9 of OF0, before I noticed version 10 was posted, but I think these comments still apply). -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 4/10/11 6:40 AM, Omprakash Gnawali wrote: > On Fri, Apr 1, 2011 at 7:47 AM, Phoebus Chen wrote: >> JP, >> >> I suppose draft-ietf-roll-minrank-hysteresis-of-02 will be made >> available online soon? Or is this a last call regarding >> draft-ietf-roll-minrank-hysteresis-of-01? > > The last call is on -01. > > > >> 1) As I understand from Table 1 and the mention of node metrics in the >> second paragraph of the introduction, MRHOF also supports node metrics. >> However, in various places throughout the document, you refer to the >> "selected metric for the link..." . I point out where I spot this below. >> When using node metrics, I presume the node adds it's own node metric value >> to the advertised metric from its candidate neighbor to get the path cost? > > Yes. Would it be better to say near the top that the discussion uses > the phrase link metric but all the discussions also apply to node > metric or use the phrase link or node metric throughout the text? > > > >> 2) In Section 3, you write "MRHOF cannot be used if the routing objective is >> to maximize the metric." Those from the optimization community may be a >> little puzzled, because you can just negate the objective function to >> convert it from a maximization problem to a minimization problem. >> >> Let's assume you wish to maximizing the product of link probabilities along >> a path. Then, you can use log(p) which results in only negative link >> metrics (so still monotonic). And instead of MIN_PATH_COST, you start with >> a MAX_PATH_REWARD of 0 and add the negative link metrics. I don't see any >> of the MRHOF mechanisms breaking here (with some minor tweaks of switching >> "minimize" to "maximize"). Am I missing something? >> >> As I understand, limiting MRHOF to minimization makes the explanations >> easier and the terminology / constant names more consistent. But are you >> restricting the scope of the OF too much here? > > > Yes. Another way way converting maximization to minimization is by > computing a reciprocal of the metric. Would it be adequate to include > a subsection that describes how to convert maximization metric to a > minimization metric so that we can use mrhof? I think the most common > use of mrhof will be with something like etx so I hesitate to make the > draft too general which will make force the implementers of the most > common case to have to read a lot of generalizations. > > If we want to use mrhof with maximization metrics by converting them > to minimization, we need to standardize how to do this conversion so > that two mrhof implementations can interoperate. One option is to use > negative metric another is computing a reciprocal. We need to pick > one. > > >> 3) Are the parent selection rules in any way affected by minHopRankIncrease, >> mentioned in (draft-ietf-roll-rpl-19, Section 3.5.2. Rank Relationships)? >> Should minHopRankIncrease always be set to 1 for MRHOF? In Table 1, you >> discuss how to convert various metrics into rank, but make no mention of >> minHopRankIncrease. (draft-ietf-roll-rpl-19, Section 3.5.1 Rank Comparison >> (DAGRank()) ) says: >> >> "MinHopRankIncrease is the minimum increase in rank between a node and any >> of its DODAG parents." > > Good point. We should put a requirement saying RPL minHopRankIncrease > should be 1 because depending on the metric, mrhof computes the rank > at the granularity of 1. What is the best section to put such > requirements? > > > >> As I understand, PARENT_SWITCH_THRESHOLD plays the role of "coarsening" the >> metric, which was originally done by the DAGRank() function for rank >> comparisons. The way I understand the properties of rank described in >> (draft-ietf-roll-rpl-19, Section 3.5. Rank Properties) and from earlier >> discussions on the mailing list, coarsening the rank is for stability. >> DAGRank() may not do such a good job when two path-cost-to-root's advertised >> by candidate neighbors are less than PARENT_SWITCH_THRESHOLD apart but they >> result in different rank (e.g., DAGRank(A)> DAGRank(B)). This is why we >> have MRHOF, right? > > MRHOF will compute the rank based on the metrics. I believe the rank > you are talking about is more like hop-count Rank? > > I processed all your editorial comments. > > Thanks for all the comments. > > - om_p From jpv@cisco.com Wed Apr 13 00:39:43 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 980F0E0732 for ; Wed, 13 Apr 2011 00:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vocQhgCVeywa for ; Wed, 13 Apr 2011 00:39:42 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 32C74E067E for ; Wed, 13 Apr 2011 00:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4878; q=dns/txt; s=iport; t=1302680382; x=1303889982; h=from:subject:date:references:to:message-id:mime-version; bh=WThMYNGbvp9CF6r/cMrwYTCeqMFctlL8BNffyhUnheE=; b=O7wW9Rndu8Q+9wACAtb20bvUbn9QXA89UrO/h684N59T6bV5zX9S1j/1 H9UdIzAIaYVbIIzyuwfV7Ti1cRClQKiwbryKI5AqmaIp/LpTlxLdaiv3z k0dxrxOKPCg+sbyzdKU9IdFRzZAyGdRy4Gnvmvy2oawkn5pMFXtFt+gJB s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: As8EAPpSpU2Q/khMgWdsb2JhbACmBxQBARYmJYh6nhSdAoVuBI1sg28H X-IronPort-AV: E=Sophos;i="4.64,203,1301875200"; d="scan'208,217";a="25504517" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 13 Apr 2011 07:39:41 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3D7dNn7000911 for ; Wed, 13 Apr 2011 07:39:41 GMT Received: from xfe-bgl-412.cisco.com ([72.163.129.200]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 13:09:38 +0530 Received: from [10.60.114.229] ([10.60.114.229]) by xfe-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 13:09:37 +0530 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-12-103146034 Date: Wed, 13 Apr 2011 09:39:36 +0200 References: <5217938C-A4F0-4EBA-ADC1-6F0CC8D5FA6D@ietf.org> To: ROLL WG Message-Id: <2551ED54-B341-4FD0-879C-38D27FF57216@cisco.com> Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 13 Apr 2011 07:39:37.0725 (UTC) FILETIME=[F0F222D0:01CBF9AD] Subject: [Roll] Fwd: New I-D Submission Tool Installed X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 07:39:43 -0000 --Apple-Mail-12-103146034 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Begin forwarded message: > From: IETF Chair > Date: April 12, 2011 8:43:14 PM GMT+02:00 > To: IETF Announce > Cc: IETF > Subject: New I-D Submission Tool Installed >=20 > A major update to the Internet-Draft Submission Tool has just been = installed. For those of you that have experienced trouble in the past, = we expect this update to solve your problems. All of the I-Ds that have = required manual processing by the Secretariat over the past few months = were used for testing, and they were all processed properly. >=20 > This update integrates the Internet-Draft upload functionality with = the datatracker. It improves I-D submission handling and security, and = it fixes database inconsistencies caused by the older implementation. = Yaco did this work under a contract managed by the IAOC. In addition, = major improvements in author extraction from I-D text was provided by = Henrik. >=20 > If you encounter any problems with the upgraded Internet-Draft = Submission Tool, please write to ietf-action@ietf.org to let us know. >=20 > Thanks to all of the people that worked to make this happen. > Russ > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf --Apple-Mail-12-103146034 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
From: IETF Chair <chair@ietf.org>
Date: April 12, 2011 = 8:43:14 PM GMT+02:00
To: IETF Announce <ietf-announce@ietf.org>
<= /span>
Cc: IETF <ietf@ietf.org>
Subject: New I-D = Submission Tool Installed

A major update to = the Internet-Draft Submission Tool has just been installed.  For = those of you that have experienced trouble in the past, we expect this = update to solve your problems.  All of the I-Ds that have required = manual processing by the Secretariat over the past few months were used = for testing, and they were all processed properly.

This update = integrates the Internet-Draft upload functionality with the datatracker. =  It improves I-D submission handling and security, and it fixes =  database inconsistencies caused by the older implementation. =  Yaco did this work under a contract managed by the IAOC.  In = addition, major improvements in author extraction from I-D text was = provided by Henrik.

If you encounter any problems with the = upgraded Internet-Draft Submission Tool, please write to ietf-action@ietf.org to let us = know.

Thanks to all of the people that worked to make this = happen.
=  Russ
_______________________________________________
Ietf = mailing list
Ietf@ietf.org
https://www.ietf.org/ma= ilman/listinfo/ietf

= --Apple-Mail-12-103146034-- From zach@sensinode.com Wed Apr 13 01:38:08 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B0385E06A1 for ; Wed, 13 Apr 2011 01:38:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.197 X-Spam-Level: X-Spam-Status: No, score=-3.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XQZV+m-3es4b for ; Wed, 13 Apr 2011 01:38:07 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfc.amsl.com (Postfix) with ESMTP id 6DEA3E065F for ; Wed, 13 Apr 2011 01:38:07 -0700 (PDT) Received: from [62.145.172.52] ([62.145.172.52]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p3D8bwwX007186 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 13 Apr 2011 11:37:58 +0300 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-77-106648999; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <43AEA790-8199-4A86-A318-4963713CD991@cisco.com> Date: Wed, 13 Apr 2011 11:37:59 +0300 Message-Id: <7E3F64B9-368C-4F80-9D6E-A2D8517C26C1@sensinode.com> References: <43AEA790-8199-4A86-A318-4963713CD991@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1082) Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 08:38:08 -0000 --Apple-Mail-77-106648999 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii JP, Although I agree that route metric measurement is necessary for p2p, why = in the world is this a separate document from the base p2p = specification? Furthermore there seems to be plenty of inefficiency in = creating a separate mechanism, and it should be explored how this could = be integrated into the same message exchange for setting up the p2p DAG.=20= Therefore I would be opposed to have a separate WG document for the = measurement mechanism, instead I think this work should be better = integrated into the base p2p specification.=20 Authors, please kick me if I missed something here. Zach On Apr 1, 2011, at 7:56 AM, JP Vasseur wrote: > Dear all, >=20 > draft-goyal-roll-p2p-measurement has been discussed on the mailing = list and is a normative > reference of the P2P document. >=20 > Could you tell us if you are in favor/opposed to adopt = draft-goyal-roll-p2p-measurement-01 as=20 > a ROLL Working Group document ? >=20 > Thanks. >=20 > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-77-106648999 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQxMzA4Mzc2 MFowIwYJKoZIhvcNAQkEMRYEFKFQjz8B/CNXFEWwr/lmBkwqJ8I4MIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAEdR9z1k13Jn4bTewGvUWRSmvg45pm0m1h0XpvAtZ0CgcOiFFqnWTTK/ ESxRkFcv/7tjacjrC9QfCsnLfDN+ehFC89aFhIMEYV4XrRCNkaSVt6EaRRBBB5QFa1126hfak6Ix v74jWYsJtG+0poJ0QXbTE0ITrtzyPdEBf0P9dsabE3tedy032suC+1N1E5Z762HAzdBEsDbsa3dL ROspxm0tGoSoymdOICLc6zKwIiulIAgd5eBPVeochdhjtTFAAG8ll6Is2VDxKpJyRDPkqdygG+8n n5dodWuweldFJbSo8iIx0LCOoLvUYfyhrU98Hs0mi3rnilBMsvMkJGho1BAAAAAAAAA= --Apple-Mail-77-106648999-- From jpv@cisco.com Wed Apr 13 01:41:16 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C66A7E06DB for ; Wed, 13 Apr 2011 01:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.556 X-Spam-Level: X-Spam-Status: No, score=-110.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YdYY5PYPvtHy for ; Wed, 13 Apr 2011 01:41:16 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by ietfc.amsl.com (Postfix) with ESMTP id EF700E06A1 for ; Wed, 13 Apr 2011 01:41:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=1595; q=dns/txt; s=iport; t=1302684076; x=1303893676; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zjDqsLY+AHjXDDXyOaaf588ZdjxSDUaApuVBNXnuyT4=; b=HA+zEijNDEBkSvztb7PA6iWLlCTLUPCLdAvbZPyvySgolvMBRZj0CqmO 0krikcHFB1cZdVSpOAkoBkeoEZF0GszBEiMjXT62iRLzZ/DlOtgr2KTns vOXDCxmrZGXqfCsqhatJ8k6bfr/yKxm0/ZyAJ4iio3YXnK8U7HYzbhsK9 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIthpU2rRDoG/2dsb2JhbACmB3eIep1InHWFbgSNbINvBw X-IronPort-AV: E=Sophos;i="4.64,203,1301875200"; d="scan'208";a="428821888" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-1.cisco.com with ESMTP; 13 Apr 2011 08:41:11 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3D8fBWU017358; Wed, 13 Apr 2011 08:41:11 GMT Received: from xfe-sjc-231.amer.cisco.com ([128.107.191.114]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 01:41:11 -0700 Received: from [10.60.114.229] ([10.60.114.229]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 13 Apr 2011 01:41:10 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <7E3F64B9-368C-4F80-9D6E-A2D8517C26C1@sensinode.com> Date: Wed, 13 Apr 2011 10:41:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <43AEA790-8199-4A86-A318-4963713CD991@cisco.com> <7E3F64B9-368C-4F80-9D6E-A2D8517C26C1@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 13 Apr 2011 08:41:10.0693 (UTC) FILETIME=[8A205550:01CBF9B6] Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 08:41:16 -0000 Hi Zach, On Apr 13, 2011, at 10:37 AM, Zach Shelby wrote: > JP, >=20 > Although I agree that route metric measurement is necessary for p2p, = why in the world is this a separate document from the base p2p = specification? Furthermore there seems to be plenty of inefficiency in = creating a separate mechanism, and it should be explored how this could = be integrated into the same message exchange for setting up the p2p DAG.=20= >=20 > Therefore I would be opposed to have a separate WG document for the = measurement mechanism, instead I think this work should be better = integrated into the base p2p specification.=20 >=20 This is clearly an option. I'll answer with my point of view, but I'd = like the authors to first chime in. > Authors, please kick me if I missed something here. >=20 > Zach >=20 > On Apr 1, 2011, at 7:56 AM, JP Vasseur wrote: >=20 >> Dear all, >>=20 >> draft-goyal-roll-p2p-measurement has been discussed on the mailing = list and is a normative >> reference of the P2P document. >>=20 >> Could you tell us if you are in favor/opposed to adopt = draft-goyal-roll-p2p-measurement-01 as=20 >> a ROLL Working Group document ? >>=20 >> Thanks. >>=20 >> JP. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 From thomas@thomasclausen.org Wed Apr 13 01:48:48 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B7AEAE06CA for ; Wed, 13 Apr 2011 01:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jOJNO6sOBUFK for ; Wed, 13 Apr 2011 01:48:48 -0700 (PDT) Received: from hgblob.out.tigertech.net (hgblob.out.tigertech.net [74.114.88.71]) by ietfc.amsl.com (Postfix) with ESMTP id 0C1ACE065F for ; Wed, 13 Apr 2011 01:48:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id 64E783244521; Wed, 13 Apr 2011 01:48:47 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.0.1.5] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 88B0032444DF; Wed, 13 Apr 2011 01:48:46 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Thomas Heide Clausen In-Reply-To: <7E3F64B9-368C-4F80-9D6E-A2D8517C26C1@sensinode.com> Date: Wed, 13 Apr 2011 10:48:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <43AEA790-8199-4A86-A318-4963713CD991@cisco.com> <7E3F64B9-368C-4F80-9D6E-A2D8517C26C1@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1084) Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 08:48:48 -0000 On Apr 13, 2011, at 10:37 , Zach Shelby wrote: > JP, >=20 > Although I agree that route metric measurement is necessary for p2p, = why in the world is this a separate document from the base p2p = specification? Furthermore there seems to be plenty of inefficiency in = creating a separate mechanism, and it should be explored how this could = be integrated into the same message exchange for setting up the p2p DAG.=20= >=20 > Therefore I would be opposed to have a separate WG document for the = measurement mechanism, instead I think this work should be better = integrated into the base p2p specification.=20 >=20 +1 from me, I have been asking myself this question too... Thomas > Authors, please kick me if I missed something here. >=20 > Zach >=20 > On Apr 1, 2011, at 7:56 AM, JP Vasseur wrote: >=20 >> Dear all, >>=20 >> draft-goyal-roll-p2p-measurement has been discussed on the mailing = list and is a normative >> reference of the P2P document. >>=20 >> Could you tell us if you are in favor/opposed to adopt = draft-goyal-roll-p2p-measurement-01 as=20 >> a ROLL Working Group document ? >>=20 >> Thanks. >>=20 >> JP. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > --=20 > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From ulrich@herberg.name Wed Apr 13 04:37:38 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DC133E06D9 for ; Wed, 13 Apr 2011 04:37:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.203 X-Spam-Level: X-Spam-Status: No, score=-2.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZ+qdXMdL9Au for ; Wed, 13 Apr 2011 04:37:38 -0700 (PDT) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfc.amsl.com (Postfix) with ESMTP id 2B3D6E0682 for ; Wed, 13 Apr 2011 04:37:37 -0700 (PDT) Received: by iye19 with SMTP id 19so669214iye.31 for ; Wed, 13 Apr 2011 04:37:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=7V/THcpF11GNE6xUQtnsH7Qo4mdNq4Kb4hCnXQWrUdY=; b=emssd9s1ykToJfT4vfgrgtCqdQRnG6OYE4BEKUaPiSZXktUtmwXG7a/jLpsJI64aIj wdJbyy28rZsjGhTSsEbtxp8L+9pMc5KxrSeqJmZH4jUj2uKuSog+gzs+3Fr8snRLH8iO e0wM1/MWDIxuAg9rDhcfSUVhdvN8/zb3evHng= DomainKey-Signature: a=rsa-sha1; c=nofws; d=herberg.name; s=dkim; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=mkl6VGqyXzojFJYTexKA+m2gOl5Hwgc3ZHBq4YD72boWaTUE5UrMm0mjgqd4jwviX6 vDUCO0uX+QZ7FEjusmMcE8Dh9LYDVUWlI+j7bVkEM5Pzg3TfnT4Y3Jne6tsHhB/hvjTs 0sPlOD3RWt1Pf0HrGE6kmC/hDVw2zg7tku0Sw= Received: by 10.43.58.15 with SMTP id wi15mr3309563icb.411.1302694657209; Wed, 13 Apr 2011 04:37:37 -0700 (PDT) Received: from [59.24.56.188] ([59.24.56.188]) by mx.google.com with ESMTPS id t1sm388119ibm.21.2011.04.13.04.37.32 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 13 Apr 2011 04:37:35 -0700 (PDT) References: <43AEA790-8199-4A86-A318-4963713CD991@cisco.com> <7E3F64B9-368C-4F80-9D6E-A2D8517C26C1@sensinode.com> In-Reply-To: Mime-Version: 1.0 (iPad Mail 8F191) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <4194F59C-B9C2-426A-8E80-FD2EE8F1C386@herberg.name> X-Mailer: iPad Mail (8F191) From: Ulrich Herberg Date: Wed, 13 Apr 2011 20:37:40 +0900 To: JP Vasseur Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 11:37:39 -0000 Hi, I also do not see the point in having an additional specification, rather th= an integrating the mechanism in the p2p draft. Maybe the authors could expla= in why this is required. Ulrich On Apr 13, 2011, at 17:41, JP Vasseur wrote: > Hi Zach, >=20 > On Apr 13, 2011, at 10:37 AM, Zach Shelby wrote: >=20 >> JP, >>=20 >> Although I agree that route metric measurement is necessary for p2p, why i= n the world is this a separate document from the base p2p specification? Fur= thermore there seems to be plenty of inefficiency in creating a separate mec= hanism, and it should be explored how this could be integrated into the same= message exchange for setting up the p2p DAG.=20 >>=20 >> Therefore I would be opposed to have a separate WG document for the measu= rement mechanism, instead I think this work should be better integrated into= the base p2p specification.=20 >>=20 >=20 > This is clearly an option. I'll answer with my point of view, but I'd like= the authors to first chime in. >=20 >> Authors, please kick me if I missed something here. >>=20 >> Zach >>=20 >> On Apr 1, 2011, at 7:56 AM, JP Vasseur wrote: >>=20 >>> Dear all, >>>=20 >>> draft-goyal-roll-p2p-measurement has been discussed on the mailing list a= nd is a normative >>> reference of the P2P document. >>>=20 >>> Could you tell us if you are in favor/opposed to adopt draft-goyal-roll-= p2p-measurement-01 as=20 >>> a ROLL Working Group document ? >>>=20 >>> Thanks. >>>=20 >>> JP. >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> --=20 >> Zach Shelby, Chief Nerd, Sensinode Ltd. >> http://zachshelby.org - My blog "On the Internet of Things" >> http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" >> Mobile: +358 40 7796297 >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=077c36615=mukul@uwm.edu Wed Apr 13 05:16:51 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 71361E06D9 for ; Wed, 13 Apr 2011 05:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.227 X-Spam-Level: X-Spam-Status: No, score=-3.227 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jSpcSs822Bbv for ; Wed, 13 Apr 2011 05:16:50 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfc.amsl.com (Postfix) with ESMTP id E48BEE06D4 for ; Wed, 13 Apr 2011 05:16:43 -0700 (PDT) Received: from mta02.pantherlink.uwm.edu ([129.89.7.133]) by ip2mta.uwm.edu with ESMTP; 13 Apr 2011 07:16:43 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 482F512E3B3; Wed, 13 Apr 2011 07:16:43 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnQfQgcLUKnm; Wed, 13 Apr 2011 07:16:42 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 9C90512E3B0; Wed, 13 Apr 2011 07:16:42 -0500 (CDT) Date: Wed, 13 Apr 2011 07:16:42 -0500 (CDT) From: Mukul Goyal To: Zach Shelby Message-ID: <776532039.24589.1302697002159.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <7E3F64B9-368C-4F80-9D6E-A2D8517C26C1@sensinode.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 - SAF3 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 12:16:51 -0000 Zach As I tried to convey to you in an earlier message, the measurement draft specifies a mechanism to measure the cost of an "existing" route between two nodes. Before I invoke the P2P mechanism to discover a "new" route between two nodes, I may want to measure the cost of any "existing" route (this could be a DAG-based route or an earlier established P2P route) between those nodes. I will invoke potentially expensive P2P route discovery only if I am not happy with the cost of the existing route. Also, the cost of the existing route will tell me what constraints must/should be satisfied by the route to be discovered. My understanding is that you would like the cost measurement of any existing route to be integrated with the discovery of new P2P route. It will be great if you could also indicate how this should be done. Thanks Mukul ----- Original Message ----- From: "Zach Shelby" To: "JP Vasseur" Cc: "ROLL WG" Sent: Wednesday, April 13, 2011 3:37:59 AM Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document JP, Although I agree that route metric measurement is necessary for p2p, why in the world is this a separate document from the base p2p specification? Furthermore there seems to be plenty of inefficiency in creating a separate mechanism, and it should be explored how this could be integrated into the same message exchange for setting up the p2p DAG. Therefore I would be opposed to have a separate WG document for the measurement mechanism, instead I think this work should be better integrated into the base p2p specification. Authors, please kick me if I missed something here. Zach On Apr 1, 2011, at 7:56 AM, JP Vasseur wrote: > Dear all, > > draft-goyal-roll-p2p-measurement has been discussed on the mailing list and is a normative > reference of the P2P document. > > Could you tell us if you are in favor/opposed to adopt draft-goyal-roll-p2p-measurement-01 as > a ROLL Working Group document ? > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Wed Apr 13 05:23:26 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 77C72E0710 for ; Wed, 13 Apr 2011 05:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Pga6Bj3Djza for ; Wed, 13 Apr 2011 05:23:25 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfc.amsl.com (Postfix) with ESMTP id D2DE0E06B6 for ; Wed, 13 Apr 2011 05:23:25 -0700 (PDT) Received: from 213-153-45-187.stat.salzburg-online.at ([213.153.45.187] helo=[192.168.0.180]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Q9z6S-0000H2-Fx; Wed, 13 Apr 2011 05:23:24 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <7E3F64B9-368C-4F80-9D6E-A2D8517C26C1@sensinode.com> Date: Wed, 13 Apr 2011 14:23:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <765151CB-F024-4181-98C0-2765FA0C16BE@cs.stanford.edu> References: <43AEA790-8199-4A86-A318-4963713CD991@cisco.com> <7E3F64B9-368C-4F80-9D6E-A2D8517C26C1@sensinode.com> To: Zach Shelby X-Mailer: Apple Mail (2.1084) X-Scan-Signature: 5e15904e367bf57319d290d73554c551 Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 12:23:26 -0000 On Apr 13, 2011, at 10:37 AM, Zach Shelby wrote: > JP, >=20 > Although I agree that route metric measurement is necessary for p2p, = why in the world is this a separate document from the base p2p = specification? Furthermore there seems to be plenty of inefficiency in = creating a separate mechanism, and it should be explored how this could = be integrated into the same message exchange for setting up the p2p DAG.=20= >=20 > Therefore I would be opposed to have a separate WG document for the = measurement mechanism, instead I think this work should be better = integrated into the base p2p specification.=20 Zach, I agree that currently the two seem tightly entwined, in that p2p needs = the measurement mechanism. But it might be that measurement is useful = independently of p2p, and so keeping their specifications separate will = prevent false coupling. It might be that once we are further along it = makes sense to merge them, but in my opinion keeping them separate for = now will lead to simpler and cleaner designs. Phil From prvs=077c36615=mukul@uwm.edu Wed Apr 13 05:37:50 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D5AF9E075B for ; Wed, 13 Apr 2011 05:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.351 X-Spam-Level: X-Spam-Status: No, score=-3.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xc3Et4mZr7gY for ; Wed, 13 Apr 2011 05:37:50 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfc.amsl.com (Postfix) with ESMTP id F3B60E0720 for ; Wed, 13 Apr 2011 05:37:49 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 13 Apr 2011 07:37:49 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id EFDCE2B3F2D; Wed, 13 Apr 2011 07:34:48 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KlHgsRvonxVZ; Wed, 13 Apr 2011 07:34:48 -0500 (CDT) Received: from mail05.pantherlink.uwm.edu (mail05.pantherlink.uwm.edu [129.89.7.165]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 8A3EA2B3F5E; Wed, 13 Apr 2011 07:34:48 -0500 (CDT) Date: Wed, 13 Apr 2011 07:37:49 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <797683570.24667.1302698268981.JavaMail.root@mail05.pantherlink.uwm.edu> In-Reply-To: <765151CB-F024-4181-98C0-2765FA0C16BE@cs.stanford.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 - SAF3 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 12:37:51 -0000 Phil >I agree that currently the two seem tightly entwined, in that p2p needs the measurement mechanism. But it might be that measurement is useful independently of p2p, and so keeping their specifications separate will prevent false coupling. It might be that once we are further along it makes sense to merge them, but in my opinion keeping them separate for now will lead to simpler and cleaner designs. The measurement mechanism was originally in the P2P draft itself. It was suggested to us that this mechanism should be its own draft precisely for the reasons you have described above. However, it could be that Zach is not referring to simply putting the two mechanisms together in the same draft. Thanks Mukul ----- Original Message ----- From: "Philip Levis" To: "Zach Shelby" Cc: "ROLL WG" Sent: Wednesday, April 13, 2011 7:23:20 AM Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document On Apr 13, 2011, at 10:37 AM, Zach Shelby wrote: > JP, > > Although I agree that route metric measurement is necessary for p2p, why in the world is this a separate document from the base p2p specification? Furthermore there seems to be plenty of inefficiency in creating a separate mechanism, and it should be explored how this could be integrated into the same message exchange for setting up the p2p DAG. > > Therefore I would be opposed to have a separate WG document for the measurement mechanism, instead I think this work should be better integrated into the base p2p specification. Zach, I agree that currently the two seem tightly entwined, in that p2p needs the measurement mechanism. But it might be that measurement is useful independently of p2p, and so keeping their specifications separate will prevent false coupling. It might be that once we are further along it makes sense to merge them, but in my opinion keeping them separate for now will lead to simpler and cleaner designs. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From abr@sdesigns.dk Wed Apr 13 07:04:03 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 89F65E06FC for ; Wed, 13 Apr 2011 07:04:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sVQUPGA7VtjH for ; Wed, 13 Apr 2011 07:04:02 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by ietfc.amsl.com (Postfix) with ESMTP id A1A25E06C6 for ; Wed, 13 Apr 2011 07:04:02 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 13 Apr 2011 16:04:01 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD8B0@zensys17.zensys.local> In-Reply-To: <797683570.24667.1302698268981.JavaMail.root@mail05.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as aROLL WG document Thread-Index: Acv5150P/mpozzRjSWORg+XS44YsuwACp4dg References: <765151CB-F024-4181-98C0-2765FA0C16BE@cs.stanford.edu> <797683570.24667.1302698268981.JavaMail.root@mail05.pantherlink.uwm.edu> From: "Anders Brandt" To: "Mukul Goyal" , "Philip Levis" Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as aROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2011 14:04:03 -0000 And then there is the option in most cost optimized environments that one is happy with the P2P discovered routes as long as they are not causing many retransmissions and the round-trip delay is acceptable. The measurement mechanism is a useful optimization tool, but not necessary for making P2P implementations work on a basic level. Thus, they should be in separate docs. Cheers, Anders -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul Goyal Sent: 13. april 2011 14:38 To: Philip Levis Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as aROLL WG document Phil >I agree that currently the two seem tightly entwined, in that p2p needs the measurement mechanism. But it might be that measurement is useful independently of p2p, and so keeping their specifications separate will prevent false coupling. It might be that once we are further along it makes sense to merge them, but in my opinion keeping them separate for now will lead to simpler and cleaner designs. The measurement mechanism was originally in the P2P draft itself. It was suggested to us that this mechanism should be its own draft precisely for the reasons you have described above. However, it could be that Zach is not referring to simply putting the two mechanisms together in the same draft. Thanks Mukul ----- Original Message ----- From: "Philip Levis" To: "Zach Shelby" Cc: "ROLL WG" Sent: Wednesday, April 13, 2011 7:23:20 AM Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document On Apr 13, 2011, at 10:37 AM, Zach Shelby wrote: > JP, >=20 > Although I agree that route metric measurement is necessary for p2p, why in the world is this a separate document from the base p2p specification? Furthermore there seems to be plenty of inefficiency in creating a separate mechanism, and it should be explored how this could be integrated into the same message exchange for setting up the p2p DAG. >=20 > Therefore I would be opposed to have a separate WG document for the measurement mechanism, instead I think this work should be better integrated into the base p2p specification.=20 Zach, I agree that currently the two seem tightly entwined, in that p2p needs the measurement mechanism. But it might be that measurement is useful independently of p2p, and so keeping their specifications separate will prevent false coupling. It might be that once we are further along it makes sense to merge them, but in my opinion keeping them separate for now will lead to simpler and cleaner designs. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From zach@sensinode.com Thu Apr 14 06:47:56 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E8337E0718 for ; Thu, 14 Apr 2011 06:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHQExfhItcNy for ; Thu, 14 Apr 2011 06:47:56 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfc.amsl.com (Postfix) with ESMTP id AC223E06B8 for ; Thu, 14 Apr 2011 06:47:55 -0700 (PDT) Received: from [192.168.1.44] (a91-156-92-242.elisa-laajakaista.fi [91.156.92.242]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id p3EDlfGi020824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Apr 2011 16:47:42 +0300 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/signed; boundary=Apple-Mail-175-211632805; protocol="application/pkcs7-signature"; micalg=sha1 From: Zach Shelby In-Reply-To: <797683570.24667.1302698268981.JavaMail.root@mail05.pantherlink.uwm.edu> Date: Thu, 14 Apr 2011 16:47:43 +0300 Message-Id: References: <797683570.24667.1302698268981.JavaMail.root@mail05.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1082) Cc: ROLL WG Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 13:47:57 -0000 --Apple-Mail-175-211632805 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Thanks Mukul and Phil for the explanation. I definitely missed that the = main purpose of this mechanism is to measure the current route before = invoking a P2P DAG. Anders also had a good point that P2P works just = fine without the measurement mechanism. So JP, I can support this as a WG document. But I do encourage the WG to = explore better integration in cases when the mechanisms are used = together.=20 Zach On Apr 13, 2011, at 3:37 PM, Mukul Goyal wrote: > Phil >=20 >> I agree that currently the two seem tightly entwined, in that p2p = needs the measurement mechanism. But it might be that measurement is = useful independently of p2p, and so keeping their specifications = separate will prevent false coupling. It might be that once we are = further along it makes sense to merge them, but in my opinion keeping = them separate for now will lead to simpler and cleaner designs. >=20 > The measurement mechanism was originally in the P2P draft itself. It = was suggested to us that this mechanism should be its own draft = precisely for the reasons you have described above. However, it could be = that Zach is not referring to simply putting the two mechanisms together = in the same draft. >=20 > Thanks > Mukul >=20 >=20 > ----- Original Message ----- > From: "Philip Levis" > To: "Zach Shelby" > Cc: "ROLL WG" > Sent: Wednesday, April 13, 2011 7:23:20 AM > Subject: Re: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a = ROLL WG document >=20 >=20 > On Apr 13, 2011, at 10:37 AM, Zach Shelby wrote: >=20 >> JP, >>=20 >> Although I agree that route metric measurement is necessary for p2p, = why in the world is this a separate document from the base p2p = specification? Furthermore there seems to be plenty of inefficiency in = creating a separate mechanism, and it should be explored how this could = be integrated into the same message exchange for setting up the p2p DAG.=20= >>=20 >> Therefore I would be opposed to have a separate WG document for the = measurement mechanism, instead I think this work should be better = integrated into the base p2p specification.=20 >=20 > Zach, >=20 > I agree that currently the two seem tightly entwined, in that p2p = needs the measurement mechanism. But it might be that measurement is = useful independently of p2p, and so keeping their specifications = separate will prevent false coupling. It might be that once we are = further along it makes sense to merge them, but in my opinion keeping = them separate for now will lead to simpler and cleaner designs. >=20 > Phil >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-175-211632805 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTExMDQxNDEzNDc0 M1owIwYJKoZIhvcNAQkEMRYEFDDWm9FlWv82ib8pt/l6cg4cIjQHMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAI2I2T9f4vWopyqnQhYF4rYyBaCP1IYjd0MWPZq1HjFO5DV2uJ4tG5IT tgx+qSzjvpqvuKfoPgwSRBxC8XHHgsKptpQ37Md+zlS5iO5fBptnxDxOICzX6Zk0Bb09a6rlyAuO HVAdYCAIf0P8tK+le3GKy97bqoVVReKEDhov9EOo1YSVzg14LcnFP4ni8ZZllv/rKBj8kyGT6P2D GqHYLMimgL0YhZFGHDR9vwYbwUAik42ZB/l9ddCtwcfy/vFJ92zW1bO2G4pkXexzGTNEB3C525hP ZOJqXraCZWfQCf7DgnVHJNA/ZPQB6Yvc7SPRgDwG52eigJgf2wPRCUUuezcAAAAAAAA= --Apple-Mail-175-211632805-- From gnawali@cs.stanford.edu Thu Apr 14 16:30:53 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 383AFE0794 for ; Thu, 14 Apr 2011 16:30:53 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u27JiCJVCEIm for ; Thu, 14 Apr 2011 16:30:52 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfc.amsl.com (Postfix) with ESMTP id 12192E065C for ; Thu, 14 Apr 2011 16:30:40 -0700 (PDT) Received: from mail-pv0-f172.google.com ([74.125.83.172]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1QAVzh-0006fg-FK for roll@ietf.org; Thu, 14 Apr 2011 16:30:39 -0700 Received: by pvh1 with SMTP id 1so997429pvh.31 for ; Thu, 14 Apr 2011 16:30:37 -0700 (PDT) Received: by 10.68.46.231 with SMTP id y7mr882332pbm.359.1302823837057; Thu, 14 Apr 2011 16:30:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Thu, 14 Apr 2011 16:30:17 -0700 (PDT) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> From: Omprakash Gnawali Date: Thu, 14 Apr 2011 16:30:17 -0700 Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 866f53e0e2528d6d10d4c38b759870b4 Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 23:30:53 -0000 On Mon, Apr 11, 2011 at 3:04 AM, Pascal Thubert (pthubert) wrote: > Hi Om: > >> > Yes, MrHof uses metrics containers, whereas OF0 does not. But can a Mr >> > Hof implementation refrain from using containers and connect to an OF0 >> > network? IOW, what =A0does it take for an MrHof implementation be able >> > to attach to an OF0 network? What needs to be done - is it a simple >> > tuning, complete rewrite? >> >> We can change mrhof to use the rank advertised by of0 as the advertised >> path cost if there is no metric container. Then the network with mrhof c= an > > [Pascal] Yes. > =A0I think that when there is no metric container, Mr Hof should operate = within the OF0 frame, and then: > - explain that by default F(ETX) of the link is used for step-of-rank. > - describe F() > - add the hysteresis logic I need one clarification - did we decide that OF0 is the default OF? At some point, you had mentioned that "0" in OF0 does not imply default OF. In that case, I am not sure how MRHOF can assume it can operate within the OF0 frame when there is no metric container. I am trying to understand if "no metric container" case is different from "no of0" case. > > Which means that we need to agree of the constants in OF0 section 7. Righ= t now: > > - OF0 has a =A0MAXIMUM_STEP_OF_RANK of 9 while =A0Mr Hof has =A0MAX_LINK_= METRIC of =A010 > > - OF0 allows up to 28 hops even when default settings are =A0used and eac= h hop has the worst Rank-increase of 9, while MrHof has only 10 hops (MAX_P= ATH_METRIC: 100). Note that this comes from Phil's comment that 16 was not = enough. > > - Mr Hof does not have a =A0MINIMUM_STEP_OF_RANK > > - Mr Hof does not have a =A0Rank Factor > > I think you should align all these constants to OF0 and point onto OF0 fo= r their definitions. I can still change MAXIMUM_STEP_OF_RANK to 10 in OF0 i= f that's important for your use cases. I think it is the metrics used (called selected metric in the draft) that dictate these constants so it is hard to say what should be the minimum step or the maximum step for MRHOF in general. The values you cite are given as examples (not as default or standard values) for one specific metric (ETX). I am hesitant to prescribe these constants because I have no idea if these constants work with the other metrics listed on the draft. >> compute additive metric based on that base cost. of0 would have no >> difficulty using the rank computed by mrhof. So, with that little tweak = above, >> we can make mrhof and of0 networks interoperate. The interoperation, > > [Pascal] It is not about interoperation between a Mr Hof DAG and an OF0 D= AG. Right now we do not really try to do that. > It is about the fact that an implementation of Mr Hof can claim complianc= e to OF0, which is a MUST in RPL. =A0As opposed to having to implement 2dif= ferent OFs. Maybe the text describes the scope of this compliance requirement, which you state as a MUST. Can you please point me to the text? >> > Also I wonder, should a Mr Hof implementation support all the metrics >> > that are listed? If not, then how does a node know if it can actually >> > work with the metrics in use in a Mr Hof network? >> >> I have this text for now: >> >> " =A0 Node rank is undefined for these node/link metrics: Node state and >> =A0 =A0attributes, throughput, and link color." >> >> We can set the rank to max rank in case of =A0unsupported metrics? > > [Pascal] No I think that you need to > - MUST support certain metric =A0containers (give the list) I don't see a reason why we should require routing decisions based on specific metrics. Some platforms will have one metric, some will have another. The routing decisions are made on some subset of metrics available on those platforms. > - MAY/SHOULD others to hint an implementation that they are considered us= eful to support It is hard to make that recommendation without knowing more about what are all the metrics available on that platform. > - MUST not switch containers in flight. Root decides, routers propagate t= he same containers with updated metrics, leaves are free to ignore There is a sentence: "The value of the cur_min_path_cost is carried in the metric container whenever ..." I can change that to: "The value of the cur_min_path_cost is carried in the metric container corresponding to the selected metric whenever..." > - MUST act as a leaf when not supporting the container that's decided by = the root We have this text right now: "If the node does not have metrics to compute the path cost through any of the candidate neighbors, it SHOULD join one of the candidate neighbors as a leaf node." We can change that to a MUST. - om_p From gnawali@cs.stanford.edu Thu Apr 14 16:45:38 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 095ACE0683 for ; Thu, 14 Apr 2011 16:45:38 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQ6FA3BHrE2O for ; Thu, 14 Apr 2011 16:45:37 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs3.Stanford.EDU [171.64.64.27]) by ietfc.amsl.com (Postfix) with ESMTP id 2D25FE067C for ; Thu, 14 Apr 2011 16:45:37 -0700 (PDT) Received: from mail-px0-f182.google.com ([209.85.212.182]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1QAWEC-0006OJ-G2 for roll@ietf.org; Thu, 14 Apr 2011 16:45:36 -0700 Received: by pxi20 with SMTP id 20so1356199pxi.27 for ; Thu, 14 Apr 2011 16:45:36 -0700 (PDT) Received: by 10.68.19.163 with SMTP id g3mr950214pbe.292.1302824736121; Thu, 14 Apr 2011 16:45:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Thu, 14 Apr 2011 16:45:16 -0700 (PDT) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D044F835A@XMB-AMS-107.cisco.com> References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F835A@XMB-AMS-107.cisco.com> From: Omprakash Gnawali Date: Thu, 14 Apr 2011 16:45:16 -0700 Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: dcedbbeaec314583a5a6d4e37e27e533 Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 23:45:38 -0000 On Mon, Apr 11, 2011 at 3:24 AM, Pascal Thubert (pthubert) wrote: > Parent set size and STRETCH of Rank are antagonistic goals. > > OF0 started with the conservative approach to allow a stretch only to > get a sibling, but did not allow a node A to stop being a potential next > hop for a node B by stretching below that node B. Which is in essence > the greediness problem. This goes along the general recommendation in > RPL section 14. > > Phil convinced me that we need OF0 to be more generic and allow a > stretch. But then the implementation has to be very careful to make sure > that when A stretches its rank, it does not cause B to be deprived of a > (its 3rd in your case) parent. It's the same problem as the > MaxRankIncrease in RPL. It is fine for A to go down to attach to B if B > is not in A's subdag, but harmful and source of Count to Infinity if B > is in A's subdag. > > Trouble is that A does not know. The STRETCH of Rank and the > MaxRankIncrease are both mechanism to control how deep the CTI goes; but > it is still a bad idea when it happens and we allow deployments to turn > it off. > > In any case you probably have to choose between making a number of > parent a desirable goal for the OF, and allow stretch. Otherwise you're > prone to see domino effects. > > To judge that I'll need to see how you word the equivalent of OF 0 > section 4/5. Right now it is a bit unclear to me: do you inherit them > from OF0, if not what's the delta? I plan to say: - PARENT_SET_SIZE number of next hops - Advertise the rank corresponding to the worst path in the set - Suggest a value of 3 for PARENT_SET_SIZE for ETX metric - If the rank corresponding to the best and the worst path in the set differ by a large amount (what is large depends on the metric so hard to have a constant), consider using a smaller PARENT_SET_SIZE - om_p From gnawali@cs.stanford.edu Thu Apr 14 16:58:23 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EDE65E06D0 for ; Thu, 14 Apr 2011 16:58:23 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5klARfhySDTE for ; Thu, 14 Apr 2011 16:58:23 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfc.amsl.com (Postfix) with ESMTP id 2E258E05F5 for ; Thu, 14 Apr 2011 16:58:23 -0700 (PDT) Received: from mail-pv0-f172.google.com ([74.125.83.172]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1QAWQY-0000kb-H8 for roll@ietf.org; Thu, 14 Apr 2011 16:58:22 -0700 Received: by pvh1 with SMTP id 1so1007888pvh.31 for ; Thu, 14 Apr 2011 16:58:22 -0700 (PDT) Received: by 10.68.7.231 with SMTP id m7mr1018804pba.91.1302825502085; Thu, 14 Apr 2011 16:58:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Thu, 14 Apr 2011 16:58:02 -0700 (PDT) In-Reply-To: <4DA2D799.8090005@ieee.org> References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <4D95E56C.9070009@ieee.org> <4DA2D799.8090005@ieee.org> From: Omprakash Gnawali Date: Thu, 14 Apr 2011 16:58:02 -0700 Message-ID: To: phoebus@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 3e263c829a24e9e508d860775f9d44fb Cc: "roll@ietf.org" Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Apr 2011 23:58:24 -0000 On Mon, Apr 11, 2011 at 3:27 AM, Phoebus Chen wrote: .... > On related note, I'm wondering if it's necessary to emphasize in the > introduction that a node adds its own node metric to the aggregate before > checking for parent selection (basically, emphasize that the steps in the > subsections of section 3 MUST be followed in that order). Just for > consistency amongst the nodes if they come from different vendors. =A0An > implementor might think it doesn't matter since the addition of the node'= s > own metric doesn't change the parent selection. What do you think? Yes, the current description adds the unnecessary dependency between those steps. I will remove that dependency. >>> 2) In Section 3, you write "MRHOF cannot be used if the routing objecti= ve >>> is >>> to maximize the metric." =A0Those from the optimization community may b= e a >>> little puzzled, because you can just negate the objective function to >>> convert it from a maximization problem to a minimization problem. ... > Yes, I think your suggestion about writing a subsection describing how to > convert the maximization metric to a minimization metric is the best > approach, rather what I had written above. =A0Maybe you can mention that = the > key point for determining whether you can convert the maximization proble= m > to a minimization problem that MRHOF can handle is that there is a known, > fixed bound on the optimum that is the value taken on by the root > (corresponding to MIN_PATH_COST), and the additive link (node) costs are = all > the same sign (negative in the maximization problem, positive in the > minimization problem). > > I would certainly prefer negating the metric. =A0Taking the reciprocal of= the > entire path metric is more complicated to describe (you are advertising t= he > denominator in the DIO messages so you don't have round off / quantizatio= n > errors, and then you take the reciprocal for comparisons for parent > selection). I will suggest this approach in the new subsection on using mrhof with maximization metrics. - om_p From gnawali@cs.stanford.edu Thu Apr 14 17:00:39 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EBDD6E076F for ; Thu, 14 Apr 2011 17:00:39 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIbtAF1oUMMw for ; Thu, 14 Apr 2011 17:00:39 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs3.Stanford.EDU [171.64.64.27]) by ietfc.amsl.com (Postfix) with ESMTP id 410C5E06D0 for ; Thu, 14 Apr 2011 17:00:39 -0700 (PDT) Received: from mail-pv0-f172.google.com ([74.125.83.172]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1QAWSk-00078u-HO for roll@ietf.org; Thu, 14 Apr 2011 17:00:38 -0700 Received: by pvh1 with SMTP id 1so1008668pvh.31 for ; Thu, 14 Apr 2011 17:00:38 -0700 (PDT) Received: by 10.68.7.231 with SMTP id m7mr1021502pba.91.1302825638144; Thu, 14 Apr 2011 17:00:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Thu, 14 Apr 2011 17:00:18 -0700 (PDT) In-Reply-To: <4DA34A99.3050508@ieee.org> References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <4D95E56C.9070009@ieee.org> <4DA34A99.3050508@ieee.org> From: Omprakash Gnawali Date: Thu, 14 Apr 2011 17:00:18 -0700 Message-ID: To: phoebus@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: f219e97bb238ccbb8ed40879dafdba3c Cc: "roll@ietf.org" Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 00:00:40 -0000 On Mon, Apr 11, 2011 at 11:38 AM, Phoebus Chen wrote: > Omprakash, > > =A0 =A0 =A0 =A0I just realized when writing my last email to Pascal that = maybe it > would necessary to specify the messages for configuring the parameters > Section 4, MRHOF Variables and Parameters? =A0I presume it can be configu= red > from the root. Lets make sure we use consistent messaging for of0 and mrhof if we decide to list those configuration messages. > =A0 =A0 =A0 =A0Also, depending on Pascal's response to my last email, may= be it would > be nice to also have an "Interface with RPL core" section in MRHOF. Unles= s > you both decide there is no need for that section. =A0Following the forma= t in > (Section 6, draft-ietf-roll-of0-10), maybe you also need a "Provide Metri= cs" > interface? > > (my last email was for version 9 of OF0, before I noticed version 10 was > posted, but I think these comments still apply). We need a consistent place to list MinHopRankIncrease at least. - om_p From jpv@cisco.com Thu Apr 14 23:33:29 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 56279E06FC for ; Thu, 14 Apr 2011 23:33:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.916 X-Spam-Level: X-Spam-Status: No, score=-109.916 tagged_above=-999 required=5 tests=[AWL=0.683, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+UpLZnQV2z0 for ; Thu, 14 Apr 2011 23:33:28 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id BA37BE0697 for ; Thu, 14 Apr 2011 23:33:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=5300; q=dns/txt; s=iport; t=1302849207; x=1304058807; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cNOS5YqWP48KQhsVnvZCsxUfdBJfhDN0UV3NQ1ITyUA=; b=mIQ/Qt84kNAZ1VvTY/qACoHErRP+cXV4oIRqmcammQbHFheDwu7yH+/p E86Js/3VOHLMYOukv0EdSPWZYVOM7Cb7WG1j/4aB6Wk5Rv3y+TUiycqrJ iNuH31JU863j4GHovbpIGaLw3BH+pIzCV9kNHt86Ql8tMqTiMk4HFeAvW Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocEAInlp02Q/khRgWdsb2JhbACmAhQBARYmJYhvnxudAYVuBI14g3uJMA X-IronPort-AV: E=Sophos;i="4.64,217,1301875200"; d="scan'208";a="25804860" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 15 Apr 2011 06:33:26 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3F6XQFl001642; Fri, 15 Apr 2011 06:33:26 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 08:33:26 +0200 Received: from ams-jvasseur-8913.cisco.com ([10.61.91.176]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 08:33:26 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: Date: Fri, 15 Apr 2011 08:33:25 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 15 Apr 2011 06:33:26.0176 (UTC) FILETIME=[068B5A00:01CBFB37] Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 06:33:29 -0000 On Apr 15, 2011, at 1:30 AM, Omprakash Gnawali wrote: > On Mon, Apr 11, 2011 at 3:04 AM, Pascal Thubert (pthubert) > wrote: >> Hi Om: >>=20 >>>> Yes, MrHof uses metrics containers, whereas OF0 does not. But can a = Mr >>>> Hof implementation refrain from using containers and connect to an = OF0 >>>> network? IOW, what does it take for an MrHof implementation be = able >>>> to attach to an OF0 network? What needs to be done - is it a simple >>>> tuning, complete rewrite? >>>=20 >>> We can change mrhof to use the rank advertised by of0 as the = advertised >>> path cost if there is no metric container. Then the network with = mrhof can >>=20 >> [Pascal] Yes. >> I think that when there is no metric container, Mr Hof should = operate within the OF0 frame, and then: >> - explain that by default F(ETX) of the link is used for = step-of-rank. >> - describe F() >> - add the hysteresis logic >=20 > I need one clarification - did we decide that OF0 is the default OF? > At some point, you had mentioned that "0" in OF0 does not imply > default OF. In that case, I am not sure how MRHOF can assume it can > operate within the OF0 frame when there is no metric container. I am > trying to understand if "no metric container" case is different from > "no of0" case. OF0 is not the default OF but just one OF among others. RPL = implementation do not have to support OF0 if they do not need to. >=20 >=20 >=20 >>=20 >> Which means that we need to agree of the constants in OF0 section 7. = Right now: >>=20 >> - OF0 has a MAXIMUM_STEP_OF_RANK of 9 while Mr Hof has = MAX_LINK_METRIC of 10 >>=20 >> - OF0 allows up to 28 hops even when default settings are used and = each hop has the worst Rank-increase of 9, while MrHof has only 10 hops = (MAX_PATH_METRIC: 100). Note that this comes from Phil's comment that 16 = was not enough. >>=20 >> - Mr Hof does not have a MINIMUM_STEP_OF_RANK >>=20 >> - Mr Hof does not have a Rank Factor >>=20 >> I think you should align all these constants to OF0 and point onto = OF0 for their definitions. I can still change MAXIMUM_STEP_OF_RANK to 10 = in OF0 if that's important for your use cases. >=20 > I think it is the metrics used (called selected metric in the draft) > that dictate these constants so it is hard to say what should be the > minimum step or the maximum step for MRHOF in general. The values you > cite are given as examples (not as default or standard values) for one > specific metric (ETX). I am hesitant to prescribe these constants > because I have no idea if these constants work with the other metrics > listed on the draft. >=20 >=20 >=20 >>> compute additive metric based on that base cost. of0 would have no >>> difficulty using the rank computed by mrhof. So, with that little = tweak above, >>> we can make mrhof and of0 networks interoperate. The interoperation, >>=20 >> [Pascal] It is not about interoperation between a Mr Hof DAG and an = OF0 DAG. Right now we do not really try to do that. >> It is about the fact that an implementation of Mr Hof can claim = compliance to OF0, which is a MUST in RPL. As opposed to having to = implement 2different OFs. >=20 > Maybe the text describes the scope of this compliance requirement, > which you state as a MUST. Can you please point me to the text? >=20 >=20 >=20 >=20 >=20 >>>> Also I wonder, should a Mr Hof implementation support all the = metrics >>>> that are listed? If not, then how does a node know if it can = actually >>>> work with the metrics in use in a Mr Hof network? >>>=20 >>> I have this text for now: >>>=20 >>> " Node rank is undefined for these node/link metrics: Node state = and >>> attributes, throughput, and link color." >>>=20 >>> We can set the rank to max rank in case of unsupported metrics? >>=20 >> [Pascal] No I think that you need to >> - MUST support certain metric containers (give the list) >=20 > I don't see a reason why we should require routing decisions based on > specific metrics. Some platforms will have one metric, some will have > another. The routing decisions are made on some subset of metrics > available on those platforms. >=20 >=20 >> - MAY/SHOULD others to hint an implementation that they are = considered useful to support >=20 > It is hard to make that recommendation without knowing more about what > are all the metrics available on that platform. >=20 >=20 >> - MUST not switch containers in flight. Root decides, routers = propagate the same containers with updated metrics, leaves are free to = ignore >=20 > There is a sentence: "The value of the cur_min_path_cost is carried in > the metric container whenever ..." >=20 > I can change that to: "The value of the cur_min_path_cost is carried > in the metric container corresponding to the selected metric > whenever..." >=20 >> - MUST act as a leaf when not supporting the container that's decided = by the root >=20 > We have this text right now: >=20 > "If the node does not have > metrics to compute the path cost through any of the candidate > neighbors, it SHOULD join one of the candidate neighbors as a leaf > node." >=20 > We can change that to a MUST. >=20 > - om_p From jpv@cisco.com Fri Apr 15 00:07:55 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8C1E6E0686 for ; Fri, 15 Apr 2011 00:07:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.992 X-Spam-Level: X-Spam-Status: No, score=-109.992 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fwaSY0Rk4d1 for ; Fri, 15 Apr 2011 00:07:54 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 74714E067D for ; Fri, 15 Apr 2011 00:07:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=1346; q=dns/txt; s=iport; t=1302851274; x=1304060874; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=zaC4U91rHX3lTijbHaDOk8Hfn7zomLnN3+6U9rodElY=; b=kHJ+aFOY2o7KoXeYuKIPFqWOF0XbMGdFBvQKIVPB8Z5aQYTlJ5ieq1d2 PLBNy5c8roZDEFo55qjNbnxNtMjeJ1yDfwGiLtGgMfukMU5u2NM3mzqmZ DMhtG5NyVkJBVb+gIL9ve4ldWQYQ7X96mG9DKeJgqY5soQ17MF4yoVtFk M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocEADXup02Q/khLgWdsb2JhbACmAhQBARYmJYhvnnCcf4VuBI14g3uJMA X-IronPort-AV: E=Sophos;i="4.64,217,1301875200"; d="scan'208";a="83688399" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2011 07:07:53 +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 p3F77rmh012513; Fri, 15 Apr 2011 07:07:53 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); Fri, 15 Apr 2011 09:07:53 +0200 Received: from ams-jvasseur-8913.cisco.com ([10.61.91.176]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 09:07:53 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: Date: Fri, 15 Apr 2011 09:07:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <4D95E56C.9070009@ieee.org> <4DA34A99.3050508@ieee.org> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 15 Apr 2011 07:07:53.0280 (UTC) FILETIME=[D6A26400:01CBFB3B] Cc: "roll@ietf.org" , phoebus@ieee.org Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 07:07:55 -0000 On Apr 15, 2011, at 2:00 AM, Omprakash Gnawali wrote: > On Mon, Apr 11, 2011 at 11:38 AM, Phoebus Chen = wrote: >> Omprakash, >>=20 >> I just realized when writing my last email to Pascal that = maybe it >> would necessary to specify the messages for configuring the = parameters >> Section 4, MRHOF Variables and Parameters? I presume it can be = configured >> from the root. They all can be configured from the root. >=20 > Lets make sure we use consistent messaging for of0 and mrhof if we > decide to list those configuration messages. VERY good point ! Thanks. >=20 >=20 >> Also, depending on Pascal's response to my last email, maybe = it would >> be nice to also have an "Interface with RPL core" section in MRHOF. = Unless >> you both decide there is no need for that section. Following the = format in >> (Section 6, draft-ietf-roll-of0-10), maybe you also need a "Provide = Metrics" >> interface? >>=20 >> (my last email was for version 9 of OF0, before I noticed version 10 = was >> posted, but I think these comments still apply). >=20 > We need a consistent place to list MinHopRankIncrease at least. >=20 > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From phoebus@ieee.org Fri Apr 15 01:46:28 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id DAA35E070D for ; Fri, 15 Apr 2011 01:46:28 -0700 (PDT) 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_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cNo2Kw6MLvr for ; Fri, 15 Apr 2011 01:46:28 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by ietfc.amsl.com (Postfix) with ESMTP id D406CE0694 for ; Fri, 15 Apr 2011 01:46:27 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 766D414DC4B; Fri, 15 Apr 2011 10:45:56 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id 0mWtY61Gz+s2; Fri, 15 Apr 2011 10:45:55 +0200 (CEST) X-KTH-Auth: phoebus [2001:6b0:1:12b0:223:dfff:fe92:5e5c] X-KTH-mail-from: phoebus@ieee.org Received: from dhcp-50-7.s3.kth.se (unknown [IPv6:2001:6b0:1:12b0:223:dfff:fe92:5e5c]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 4BE5B14C113; Fri, 15 Apr 2011 10:45:51 +0200 (CEST) Message-ID: <4DA805BE.1030303@ieee.org> Date: Fri, 15 Apr 2011 10:45:50 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: Omprakash Gnawali References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <4D95E56C.9070009@ieee.org> <4DA2D799.8090005@ieee.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "roll@ietf.org" Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 08:46:29 -0000 On 4/15/11 1:58 AM, Omprakash Gnawali wrote: > On Mon, Apr 11, 2011 at 3:27 AM, Phoebus Chen wrote: > .... >> On related note, I'm wondering if it's necessary to emphasize in the >> introduction that a node adds its own node metric to the aggregate before >> checking for parent selection (basically, emphasize that the steps in the >> subsections of section 3 MUST be followed in that order). Just for >> consistency amongst the nodes if they come from different vendors. An >> implementor might think it doesn't matter since the addition of the node's >> own metric doesn't change the parent selection. What do you think? > > Yes, the current description adds the unnecessary dependency between > those steps. I will remove that dependency. I should have worded my comment above more very carefully, because I think you misunderstood what I meant. I was in *favor* of specifying that the order of the steps in section 3 MUST be followed. Just in case the nodes from one of the vendors decides (for node metrics) to do parent selection on the advertised metric, while the nodes from another vendor decides to do parent selection on the advertised metric + its own node metric. In that sense, the dependency of the steps, which I interpret as following the steps in the same order, is necessary. Anyhow, my question to you was whether the order of the steps were emphasized enough, or whether we should emphasize the steps more explicitly. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus From pthubert@cisco.com Fri Apr 15 02:04:12 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id C8D4DE070D for ; Fri, 15 Apr 2011 02:04:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.086 X-Spam-Level: X-Spam-Status: No, score=-10.086 tagged_above=-999 required=5 tests=[AWL=0.513, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YU2+jutwl5SE for ; Fri, 15 Apr 2011 02:04:12 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id D733FE06FC for ; Fri, 15 Apr 2011 02:04:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1245; q=dns/txt; s=iport; t=1302858251; x=1304067851; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ew72liuotC0ghIjECVX8HvLFavOQu+GbGf85gd2ay5A=; b=W781DB7OoeZl7R9mZI0OJjXsynGR1t0FnkbsGdMDh2SKVg4t+GH7m7xx 99JNPENUoaEmHmntOf6U48PstXxg1fBPIoKJxvXm0lx8EE5/R4FOPCA0k ilvulXgb7d82AJN73aDk6dtPi3ODr1sFsocSiAwwzM4YgpNxDE9hzvI0o E=; X-IronPort-AV: E=Sophos;i="4.64,217,1301875200"; d="scan'208";a="83709627" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2011 09:04:11 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p3F94BjM016598; Fri, 15 Apr 2011 09:04:11 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 11:04:10 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Apr 2011 11:04:06 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 Thread-Index: Acv7NwdihtEnj0p0T1GBl/YOb+hpTgAFCwgw References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur" , "Omprakash Gnawali" X-OriginalArrivalTime: 15 Apr 2011 09:04:10.0957 (UTC) FILETIME=[15A767D0:01CBFB4C] Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 09:04:12 -0000 > > I need one clarification - did we decide that OF0 is the default OF? > > At some point, you had mentioned that "0" in OF0 does not imply > > default OF. In that case, I am not sure how MRHOF can assume it can > > operate within the OF0 frame when there is no metric container. I am > > trying to understand if "no metric container" case is different from > > "no of0" case. >=20 > OF0 is not the default OF but just one OF among others. RPL implementation > do not have to support OF0 if they do not need to. [Pascal] I agree that default is not the right wording. RPL now says: " If further guidance is not available then a RPL Router implementation MUST at least support the metric-less OF0 [I-D.ietf-roll-of0]. " Which means that OF0 has the special role of least common denominator for generic implementations. This is why it has to be quite abstract and container-less. That comes from an IESG DISCUSS by Jari.=20 I'm advocating that an Mr Hof implementation should be usable as an OF0 so that same implementation can be used outside of the limited scope where "further guidance" is given that does not require OF0. Unless operation with no metric container is not doable with Mr Hof? Pascal From jpv@cisco.com Fri Apr 15 02:10:14 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id CFE9AE06D6 for ; Fri, 15 Apr 2011 02:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.053 X-Spam-Level: X-Spam-Status: No, score=-110.053 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8e+s+6NR46g for ; Fri, 15 Apr 2011 02:10:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 4C9E9E065A for ; Fri, 15 Apr 2011 02:10:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=1842; q=dns/txt; s=iport; t=1302858613; x=1304068213; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=XoiwHruNZX+kq0euUv31k7ajRRDngawaNtNdXaO4emQ=; b=ApDVb8rANfVNt9CnN9494bgumar7E9OyaGKJDlKZ+3HvePVIANWNSjcJ /N06BHxfkS0KEHl4C7l2HUq6/Ra46TNCFdE7I7Xosj7quZZPPa4YJivkX l1Rv3crE2eZDKpa7FYSZGGTZnoAYzfyDO0UUDezMBZun9GA+obM2WO+p7 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AocEAGUKqE2Q/khMgWdsb2JhbACmABQBARYmJYhvnXKcd4VuBI14g3s X-IronPort-AV: E=Sophos;i="4.64,217,1301875200"; d="scan'208";a="83710545" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2011 09:10:12 +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 p3F9ABiI017953; Fri, 15 Apr 2011 09:10:11 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 11:10:11 +0200 Received: from ams-jvasseur-8913.cisco.com ([10.61.91.176]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 11:10:10 +0200 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com> Date: Fri, 15 Apr 2011 11:10:10 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <01F11D56-CC97-4523-A644-0DBB07F00790@cisco.com> References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 15 Apr 2011 09:10:10.0815 (UTC) FILETIME=[EC2560F0:01CBFB4C] Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 09:10:15 -0000 On Apr 15, 2011, at 11:04 AM, Pascal Thubert (pthubert) wrote: >>> I need one clarification - did we decide that OF0 is the default OF? >>> At some point, you had mentioned that "0" in OF0 does not imply >>> default OF. In that case, I am not sure how MRHOF can assume it can >>> operate within the OF0 frame when there is no metric container. I am >>> trying to understand if "no metric container" case is different from >>> "no of0" case. >>=20 >> OF0 is not the default OF but just one OF among others. RPL > implementation >> do not have to support OF0 if they do not need to. >=20 > [Pascal] I agree that default is not the right wording. >=20 > RPL now says: >=20 > " > If further guidance is not available then a RPL Router = implementation > MUST at least support the metric-less OF0 [I-D.ietf-roll-of0]. > " >=20 > Which means that OF0 has the special role of least common denominator > for generic implementations. This is why it has to be quite abstract = and > container-less. That comes from an IESG DISCUSS by Jari.=20 Just to make sure that there is no ambiguity this does not mean that = implementations=20 must at least support OF0. You can have a network with all nodes only = supporting MrHof or other OF >=20 > I'm advocating that an Mr Hof implementation should be usable as an = OF0 > so that same implementation can be used outside of the limited scope > where "further guidance" is given that does not require OF0. >=20 > Unless operation with no metric container is not doable with Mr Hof? >=20 Let's make things simple ... we have OF0 and Mrhof so far. An = implementation may choose to support one or the other. > Pascal > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From matteo.paris@ember.com Fri Apr 15 07:31:48 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id E7574E0796 for ; Fri, 15 Apr 2011 07:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbuNTstBVN8H for ; Fri, 15 Apr 2011 07:31:48 -0700 (PDT) Received: from p01c12o143.mxlogic.net (p01c12o143.mxlogic.net [208.65.145.66]) by ietfc.amsl.com (Postfix) with ESMTP id EE459E06EC for ; Fri, 15 Apr 2011 07:31:46 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO EMPIRE.hq.ember.com) by p01c12o143.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 2d658ad4.0.7396.00-368.15419.p01c12o143.mxlogic.net (envelope-from ); Fri, 15 Apr 2011 08:31:47 -0600 (MDT) X-MXL-Hash: 4da856d35c1b9bf4-74089769171c6b5ec1aca395759eec2a6c008a51 Received: from [192.168.81.65] ([192.168.81.65]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 10:31:19 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F835A@XMB-AMS-107.cisco.com> Date: Fri, 15 Apr 2011 10:30:31 -0400 To: Omprakash Gnawali , "Pascal Thubert (pthubert)" From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 15 Apr 2011 14:31:19.0347 (UTC) FILETIME=[C9160830:01CBFB79] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=YR9CI1MVwOMA:10 a=saA6nF2ZJaAA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=NG] X-AnalysisOut: [NZFoXzq7SRXHBDwxsA:9 a=CjuIK1q_8ugA:10] Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 14:31:49 -0000 Hi Omprakash, At 4:45 PM -0700 4/14/11, Omprakash Gnawali wrote: >I plan to say: > >- PARENT_SET_SIZE number of next hops >- Advertise the rank corresponding to the worst path in the set >- Suggest a value of 3 for PARENT_SET_SIZE for ETX metric >- If the rank corresponding to the best and the worst path in the set >differ by a large amount (what is large depends on the metric so hard >to have a constant), consider using a smaller PARENT_SET_SIZE Computing rank as the worst path cost in the parent set is a natural thing to try, but it creates a problem (originally pointed out to me by Joseph Reddy). Suppose A is the root (rank 1) and B joins but has a poor link to A, say link cost 9, giving it a rank of 10. Now suppose C joins and has good links (cost 1) to both A and B. It places them both in its parent set and advertises a rank of 11. This prevents B from finding the good route through C, which it would have found had C joined first. Your final bullet point could remedy this problem, but it seems reversed. It would be more straightforward to compute the rank as the best path in the parent set, plus a RANK_FUZZ factor which depends on the metric. Matteo From pthubert@cisco.com Fri Apr 15 09:07:33 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 57A65E0777 for ; Fri, 15 Apr 2011 09:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.129 X-Spam-Level: X-Spam-Status: No, score=-10.129 tagged_above=-999 required=5 tests=[AWL=0.470, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNHlWQQTd9VE for ; Fri, 15 Apr 2011 09:07:29 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id CCAD2E06BA for ; Fri, 15 Apr 2011 09:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2316; q=dns/txt; s=iport; t=1302883648; x=1304093248; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=eiJ0eaRKmxOn1QaM6FuxvalthHFgE5IQBoyT7BT8LXo=; b=kf7X1/KTlXMs7Rdnkl2CiL8MGKMPZkX8oGIUEJZ0tykR2eMwCAjTF9Wo IukykNcyIHYstX3YYuV6XLpTUBlMSOKRLKKlZpzNohq90TXnIBNnQA6X3 VTCVJa7zewichLfpml3WtuBEMVB4jOtgyjdB2SjWBjV77U2E7c543Uolv I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjcBAMJsqE2Q/khMgWdsb2JhbACYBY1/FAEBFiYlp1+cfoVuBJFziTI X-IronPort-AV: E=Sophos;i="4.64,219,1301875200"; d="scan'208";a="83787259" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2011 16:07:28 +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 p3FG7SlN007178; Fri, 15 Apr 2011 16:07:28 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 18:07:27 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 15 Apr 2011 18:07:23 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0464F5CE@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 Thread-Index: Acv7edDyNqzribeZTGu96S7debNv+wAC7EOA References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F835A@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Matteo Paris" , "Omprakash Gnawali" X-OriginalArrivalTime: 15 Apr 2011 16:07:27.0870 (UTC) FILETIME=[3764C9E0:01CBFB87] Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 16:07:33 -0000 Hi Matteo: I agree with you.=20 This was the spirit from the start & I'm surprised this keeps on coming back. Just like the stretch, Computing rank as the worst path cost in the parent set is a trick that leads the DAG to be less and less true to the metric to the point that you illustrate. Let's face it, there's no way in a DAG that all nodes have 2 parents. People might hide that truth through complex behaviors and large datasets, but it comes back with a revenge. An OF could theoretically play games with metrics from multiple parents, but in the end, if forwarding is to take place mostly over the preferred parent, the metrics that the node advertises should be true to that. Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Matteo Paris [mailto:matteo@ember.com] > Sent: Friday, April 15, 2011 4:31 PM > To: Omprakash Gnawali; Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 >=20 >=20 > Hi Omprakash, >=20 > At 4:45 PM -0700 4/14/11, Omprakash Gnawali wrote: > >I plan to say: > > > >- PARENT_SET_SIZE number of next hops > >- Advertise the rank corresponding to the worst path in the set > >- Suggest a value of 3 for PARENT_SET_SIZE for ETX metric > >- If the rank corresponding to the best and the worst path in the set > >differ by a large amount (what is large depends on the metric so hard > >to have a constant), consider using a smaller PARENT_SET_SIZE >=20 > Computing rank as the worst path cost in the parent set is a natural thing to > try, but it creates a problem (originally pointed out to me by Joseph Reddy). > Suppose A is the root (rank 1) and B joins but has a poor link to A, say link cost > 9, giving it a rank of 10. Now suppose C joins and has good links (cost 1) to > both A and B. It places them both in its parent set and advertises a rank of > 11. This prevents B from finding the good route through C, which it would > have found had C joined first. >=20 > Your final bullet point could remedy this problem, but it seems reversed. It > would be more straightforward to compute the rank as the best path in the > parent set, plus a RANK_FUZZ factor which depends on the metric. >=20 > Matteo From pal@cs.stanford.edu Fri Apr 15 10:06:21 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id D6C16130084 for ; Fri, 15 Apr 2011 10:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GhBKdbsvzCJd for ; Fri, 15 Apr 2011 10:06:21 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs3.Stanford.EDU [171.64.64.27]) by ietfc.amsl.com (Postfix) with ESMTP id CE44A130083 for ; Fri, 15 Apr 2011 10:06:20 -0700 (PDT) Received: from [50.12.161.7] (helo=50-12-161-7.sfo.clearwire-wmx.net) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1QAmTI-00006a-BY; Fri, 15 Apr 2011 10:06:20 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Fri, 15 Apr 2011 10:06:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F835A@XMB-AMS-107.cisco.com> To: Matteo Paris X-Mailer: Apple Mail (2.1084) X-Scan-Signature: f9929892efd47015c544d6ca2fb551e9 Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 17:06:22 -0000 On Apr 15, 2011, at 7:30 AM, Matteo Paris wrote: >=20 > Hi Omprakash, >=20 > At 4:45 PM -0700 4/14/11, Omprakash Gnawali wrote: >> I plan to say: >>=20 >> - PARENT_SET_SIZE number of next hops >> - Advertise the rank corresponding to the worst path in the set >> - Suggest a value of 3 for PARENT_SET_SIZE for ETX metric >> - If the rank corresponding to the best and the worst path in the set >> differ by a large amount (what is large depends on the metric so hard >> to have a constant), consider using a smaller PARENT_SET_SIZE >=20 > Computing rank as the worst path cost in the parent set is a natural = thing to try, but it creates a problem (originally pointed out to me by = Joseph Reddy). Suppose A is the root (rank 1) and B joins but has a = poor link to A, say link cost 9, giving it a rank of 10. Now suppose C = joins and has good links (cost 1) to both A and B. It places them both = in its parent set and advertises a rank of 11. This prevents B from = finding the good route through C, which it would have found had C joined = first. Yes, this is correct. The way that you prevent this is using MaxRankIncrease. If = MaxRankIncrease is 0, then if C places both A and B in its parent set it = must advertise 11. But C does not have to place B in its parent set: C = can have a parent set of just A and advertise a Rank of 2. With a = MaxRankIncrease of 0, however, if link CA fails, then C cannot fail over = to B until a new version. This is the tradeoff which I think all of = these discussions ignore: in order to prevent loops, low MaxRankIncrease = values force nodes to trade off between routing flexibility and routing = efficiency. There is no free lunch here (well, except datapath = validation, which while cheap is not free). Of course, the simplest solution to this problem is to have a = significant MaxRankIncrease. E.g., if MaxRankIncrease is 20, then C can = keep B as a neighbor but not a member of the parent set. If link CA = fails, then C can fail over to link CB and advertise a Rank of 11. Phil= From matteo.paris@ember.com Fri Apr 15 13:03:17 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3A8BCE073F for ; Fri, 15 Apr 2011 13:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzZCWzU7u2-T for ; Fri, 15 Apr 2011 13:03:16 -0700 (PDT) Received: from p01c11o149.mxlogic.net (p01c11o149.mxlogic.net [208.65.144.72]) by ietfc.amsl.com (Postfix) with ESMTP id 2D865E06D8 for ; Fri, 15 Apr 2011 13:03:16 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO EMPIRE.hq.ember.com) by p01c11o149.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 384a8ad4.0.39424.00-343.90716.p01c11o149.mxlogic.net (envelope-from ); Fri, 15 Apr 2011 14:03:16 -0600 (MDT) X-MXL-Hash: 4da8a48449ae693a-2dea41485f2115d1d214a06fad840905c1178099 Received: from [10.7.6.5] ([192.168.81.65]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 16:03:12 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F835A@XMB-AMS-107.cisco.com> Date: Fri, 15 Apr 2011 16:03:13 -0400 To: Philip Levis From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 15 Apr 2011 20:03:12.0472 (UTC) FILETIME=[263BC580:01CBFBA8] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=YR9CI1MVwOMA:10 a=saA6nF2ZJaAA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=wT] X-AnalysisOut: [MVT0soePqTtBQcZmcA:9 a=CjuIK1q_8ugA:10 a=7VfW9dk9HecSzygk:] X-AnalysisOut: [21 a=fzVUGf_X8dGODQd4:21] Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 20:03:17 -0000 At 4:45 PM -0700 4/14/11, Omprakash Gnawali wrote: > >> I plan to say: >>> >>> - PARENT_SET_SIZE number of next hops >>> - Advertise the rank corresponding to the worst path in the set >>> - Suggest a value of 3 for PARENT_SET_SIZE for ETX metric >>> - If the rank corresponding to the best and the worst path in the set >>> differ by a large amount (what is large depends on the metric so hard > >> to have a constant), consider using a smaller PARENT_SET_SIZE On Apr 15, 2011, at 7:30 AM, Matteo Paris wrote: >Computing rank as the worst path cost in the parent set is a natural >thing to try, but it creates a problem (originally pointed out to me >by Joseph Reddy). Suppose A is the root (rank 1) and B joins but >has a poor link to A, say link cost 9, giving it a rank of 10. Now >suppose C joins and has good links (cost 1) to both A and B. It >places them both in its parent set and advertises a rank of 11. >This prevents B from finding the good route through C, which it >would have found had C joined first. At 10:06 AM -0700 4/15/11, Philip Levis wrote: > >Yes, this is correct. > >The way that you prevent this is using MaxRankIncrease. > >If MaxRankIncrease is 0, then if C places both A and B in its parent >set it must advertise 11. But C does not have to place B in its >parent set: C can have a parent set of just A and advertise a Rank >of 2. With a MaxRankIncrease of 0, however, if link CA fails, then C >cannot fail over to B until a new version. This is the tradeoff >which I think all of these discussions ignore: in order to prevent >loops, low MaxRankIncrease values force nodes to trade off between >routing flexibility and routing efficiency. There is no free lunch >here (well, except datapath validation, which while cheap is not >free). > >Of course, the simplest solution to this problem is to have a >significant MaxRankIncrease. E.g., if MaxRankIncrease is 20, then C >can keep B as a neighbor but not a member of the parent set. If link >CA fails, then C can fail over to link CB and advertise a Rank of 11. Hi Phil, what you say about MaxRankIncrease is true, but I don't see on how it relates to preventing the problem caused by the parent selection strategy above. You say "C does not have to place B in its parent set", but my reading of the bullets above is that C would indeed put B in its parent set (PARENT_SET_SIZE is 3) and set its rank to 11, regardless of the value of MaxRankIncrease. It seems that we are interpreting the selection strategy differently. Omprakash? Matteo From pal@cs.stanford.edu Fri Apr 15 13:50:15 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 95881E0682 for ; Fri, 15 Apr 2011 13:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9abS8mW9JZST for ; Fri, 15 Apr 2011 13:50:14 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfc.amsl.com (Postfix) with ESMTP id 7E785E0674 for ; Fri, 15 Apr 2011 13:50:14 -0700 (PDT) Received: from dn0a21011f.sunet ([10.33.1.31]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1QApy1-0000QJ-Kp; Fri, 15 Apr 2011 13:50:14 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Fri, 15 Apr 2011 13:50:13 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7874431C-EE85-406C-8D28-F45A130710A6@cs.stanford.edu> References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F835A@XMB-AMS-107.cisco.com> To: Matteo Paris X-Mailer: Apple Mail (2.1084) X-Scan-Signature: 26b8f8cb9d50f38c95a96ded60a4c5d6 Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 20:50:15 -0000 On Apr 15, 2011, at 1:03 PM, Matteo Paris wrote: >=20 > At 4:45 PM -0700 4/14/11, Omprakash Gnawali wrote: >> >> I plan to say: >>>>=20 >>>> - PARENT_SET_SIZE number of next hops >>>> - Advertise the rank corresponding to the worst path in the set >>>> - Suggest a value of 3 for PARENT_SET_SIZE for ETX metric >>>> - If the rank corresponding to the best and the worst path in the = set >>>> differ by a large amount (what is large depends on the metric so = hard >> >> to have a constant), consider using a smaller PARENT_SET_SIZE >=20 > On Apr 15, 2011, at 7:30 AM, Matteo Paris wrote: >> Computing rank as the worst path cost in the parent set is a natural = thing to try, but it creates a problem (originally pointed out to me by = Joseph Reddy). Suppose A is the root (rank 1) and B joins but has a = poor link to A, say link cost 9, giving it a rank of 10. Now suppose C = joins and has good links (cost 1) to both A and B. It places them both = in its parent set and advertises a rank of 11. This prevents B from = finding the good route through C, which it would have found had C joined = first. >=20 > At 10:06 AM -0700 4/15/11, Philip Levis wrote: >>=20 >> Yes, this is correct. >>=20 >> The way that you prevent this is using MaxRankIncrease. >>=20 >> If MaxRankIncrease is 0, then if C places both A and B in its parent = set it must advertise 11. But C does not have to place B in its parent = set: C can have a parent set of just A and advertise a Rank of 2. With a = MaxRankIncrease of 0, however, if link CA fails, then C cannot fail over = to B until a new version. This is the tradeoff which I think all of = these discussions ignore: in order to prevent loops, low MaxRankIncrease = values force nodes to trade off between routing flexibility and routing = efficiency. There is no free lunch here (well, except datapath = validation, which while cheap is not free). >>=20 >> Of course, the simplest solution to this problem is to have a = significant MaxRankIncrease. E.g., if MaxRankIncrease is 20, then C can = keep B as a neighbor but not a member of the parent set. If link CA = fails, then C can fail over to link CB and advertise a Rank of 11. >=20 > Hi Phil, what you say about MaxRankIncrease is true, but I don't see = on how it relates to preventing the problem caused by the parent = selection strategy above. You say "C does not have to place B in its = parent set", but my reading of the bullets above is that C would indeed = put B in its parent set (PARENT_SET_SIZE is 3) and set its rank to 11, = regardless of the value of MaxRankIncrease. It seems that we are = interpreting the selection strategy differently. Omprakash? I think what we're learning from this is that RPL should have, rather = than requiring a node advertise a Rank greater than all elements of its = parent set, should have to advertise a rank greater than both the rank = of the lowest rank member of the parent set as well as greater than the = rank of the highest rank member of the parent set *minus = MaxRankIncrease." The issue here is that a node might have valid potential parents in its = neighbor set that it does not want to include in the parent set because = of the Rank advertisement they would require. The draft should explain = this: perhaps we should cal them "potential parents." phil From gnawali@cs.stanford.edu Fri Apr 15 14:03:51 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id B999BE06D8 for ; Fri, 15 Apr 2011 14:03:51 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rj7hx4MzFT2n for ; Fri, 15 Apr 2011 14:03:50 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfc.amsl.com (Postfix) with ESMTP id 93C62E0674 for ; Fri, 15 Apr 2011 14:03:50 -0700 (PDT) Received: from mail-px0-f182.google.com ([209.85.212.182]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1QAqBB-0001b0-P8 for roll@ietf.org; Fri, 15 Apr 2011 14:03:50 -0700 Received: by pxi20 with SMTP id 20so2031738pxi.27 for ; Fri, 15 Apr 2011 14:03:49 -0700 (PDT) Received: by 10.68.7.231 with SMTP id m7mr2558225pba.91.1302901429386; Fri, 15 Apr 2011 14:03:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Fri, 15 Apr 2011 14:03:29 -0700 (PDT) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com> References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com> From: Omprakash Gnawali Date: Fri, 15 Apr 2011 14:03:29 -0700 Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: f9929892efd47015c544d6ca2fb551e9 Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Apr 2011 21:03:51 -0000 On Fri, Apr 15, 2011 at 2:04 AM, Pascal Thubert (pthubert) wrote: >> > I need one clarification - did we decide that OF0 is the default OF? >> > At some point, you had mentioned that "0" in OF0 does not imply >> > default OF. In that case, I am not sure how MRHOF can assume it can >> > operate within the OF0 frame when there is no metric container. I am >> > trying to understand if "no metric container" case is different from >> > "no of0" case. >> >> OF0 is not the default OF but just one OF among others. RPL > implementation >> do not have to support OF0 if they do not need to. > > [Pascal] I agree that default is not the right wording. > > RPL now says: > > " > =A0 If further guidance is not available then a RPL Router implementation > =A0 MUST at least support the metric-less OF0 [I-D.ietf-roll-of0]. > " > > Which means that OF0 has the special role of least common denominator > for generic implementations. This is why it has to be quite abstract and > container-less. That comes from an IESG DISCUSS by Jari. > > I'm advocating that an Mr Hof implementation should be usable as an OF0 > so that same implementation can be used outside of the limited scope > where "further guidance" is given that does not require OF0. > > Unless operation with no metric container is not doable with Mr Hof? Now that we are clear between no of0 and no metric container case, we can discuss what MRHOF should do when there is no metric container. Pascal has put in a lot of thought over the last several months on how to do routing without metric containers so it makes sense to use that work. I can state in MRHOF draft: "If there is no metric container, parent selection and rank computation is done according to the mechanisms mentioned in OF0." Does that work? - om_p From pal@cs.stanford.edu Fri Apr 15 17:43:55 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 740CEE0660 for ; Fri, 15 Apr 2011 17:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2KLvIpum3Fu for ; Fri, 15 Apr 2011 17:43:54 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs3.Stanford.EDU [171.64.64.27]) by ietfc.amsl.com (Postfix) with ESMTP id 77766E061E for ; Fri, 15 Apr 2011 17:43:54 -0700 (PDT) Received: from dn5221ai.sunet ([10.33.5.82]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1QAtc9-00028Y-Gf; Fri, 15 Apr 2011 17:43:53 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Fri, 15 Apr 2011 17:43:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2264C018-90CD-4253-B80C-DD0FAD5BB404@cs.stanford.edu> References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1084) X-Scan-Signature: f52b81a2b0b1468c47a83f31a7d93b0f Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 00:43:55 -0000 On Apr 15, 2011, at 2:03 PM, Omprakash Gnawali wrote: > On Fri, Apr 15, 2011 at 2:04 AM, Pascal Thubert (pthubert) > wrote: >>>> I need one clarification - did we decide that OF0 is the default = OF? >>>> At some point, you had mentioned that "0" in OF0 does not imply >>>> default OF. In that case, I am not sure how MRHOF can assume it can >>>> operate within the OF0 frame when there is no metric container. I = am >>>> trying to understand if "no metric container" case is different = from >>>> "no of0" case. >>>=20 >>> OF0 is not the default OF but just one OF among others. RPL >> implementation >>> do not have to support OF0 if they do not need to. >>=20 >> [Pascal] I agree that default is not the right wording. >>=20 >> RPL now says: >>=20 >> " >> If further guidance is not available then a RPL Router = implementation >> MUST at least support the metric-less OF0 [I-D.ietf-roll-of0]. >> " >>=20 >> Which means that OF0 has the special role of least common denominator >> for generic implementations. This is why it has to be quite abstract = and >> container-less. That comes from an IESG DISCUSS by Jari. >>=20 >> I'm advocating that an Mr Hof implementation should be usable as an = OF0 >> so that same implementation can be used outside of the limited scope >> where "further guidance" is given that does not require OF0. >>=20 >> Unless operation with no metric container is not doable with Mr Hof? >=20 > Now that we are clear between no of0 and no metric container case, we > can discuss what MRHOF should do when there is no metric container. > Pascal has put in a lot of thought over the last several months on how > to do routing without metric containers so it makes sense to use that > work. I can state in MRHOF draft: >=20 > "If there is no metric container, parent selection and rank > computation is done according to the mechanisms mentioned in OF0." I think Rank computation makes sense -- but parent selection is actually = quite a bit different. So I would just say Rank computation. Phil= From matteo.paris@ember.com Fri Apr 15 18:46:37 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9C16FE0679 for ; Fri, 15 Apr 2011 18:46:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SNl5TSL8O131 for ; Fri, 15 Apr 2011 18:46:37 -0700 (PDT) Received: from p01c11o145.mxlogic.net (p01c11o145.mxlogic.net [208.65.144.68]) by ietfc.amsl.com (Postfix) with ESMTP id BC319E061E for ; Fri, 15 Apr 2011 18:46:36 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO EMPIRE.hq.ember.com) by p01c11o145.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id cf4f8ad4.0.59314.00-257.129943.p01c11o145.mxlogic.net (envelope-from ); Fri, 15 Apr 2011 19:46:36 -0600 (MDT) X-MXL-Hash: 4da8f4fc44be8515-9d273fc85be162d85a11768fcb9dc188fe82ed02 Received: from [10.7.6.5] ([192.168.90.52]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 15 Apr 2011 21:46:32 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <7874431C-EE85-406C-8D28-F45A130710A6@cs.stanford.edu> References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F835A@XMB-AMS-107.cisco.com> <7874431C-EE85-406C-8D28-F45A130710A6@cs.stanford.edu> Date: Fri, 15 Apr 2011 21:46:34 -0400 To: Philip Levis From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 16 Apr 2011 01:46:32.0816 (UTC) FILETIME=[1CFECF00:01CBFBD8] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=YR9CI1MVwOMA:10 a=saA6nF2ZJaAA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=mA] X-AnalysisOut: [hCyt7xTLQGFxD1RCAA:9 a=CjuIK1q_8ugA:10] Cc: ROLL WG Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 01:46:37 -0000 At 1:50 PM -0700 4/15/11, Philip Levis wrote: >I think what we're learning from this is that RPL should have, >rather than requiring a node advertise a Rank greater than all >elements of its parent set, should have to advertise a rank greater >than both the rank of the lowest rank member of the parent set as >well as greater than the rank of the highest rank member of the >parent set *minus MaxRankIncrease." Hi Phil, I'm sorry but I am not following you. It seems to me that with that definition, a node could choose a rank lower than the rank of one of its parents. For example, suppose MaxRankIncrease is 255. Then a node could choose to have two parents with ranks 10 and 20, but set its own rank to 11. MaxRankIncrease was introduced to (optionally) shorten the distance to infinity, to avoid lengthy counts-to-infinity. I think your concern can be addressed by setting MaxRankIncrease to a sufficiently high value. My concern with Omprakash's most recent parent selection proposal is not directly related to MaxRankIncrease. Matteo From richard.kelsey@ember.com Sat Apr 16 03:44:36 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id AC928E0694 for ; Sat, 16 Apr 2011 03:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KI7aEJYTjRs9 for ; Sat, 16 Apr 2011 03:44:35 -0700 (PDT) Received: from p01c12o142.mxlogic.net (p01c12o142.mxlogic.net [208.65.145.65]) by ietfc.amsl.com (Postfix) with ESMTP id 60D12E066E for ; Sat, 16 Apr 2011 03:44:35 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO EMPIRE.hq.ember.com) by p01c12o142.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 21379ad4.0.8816.00-398.14697.p01c12o142.mxlogic.net (envelope-from ); Sat, 16 Apr 2011 04:44:35 -0600 (MDT) X-MXL-Hash: 4da9731376ef403e-58f69ec5b5592fa492f4fdf564311005f1ffdae0 Received: from kelsey-ws.hq.ember.com ([192.168.81.75]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 16 Apr 2011 06:44:31 -0400 Date: Sat, 16 Apr 2011 06:44:54 -0400 Message-Id: <878vvav5jt.fsf@kelsey-ws.hq.ember.com> To: Omprakash Gnawali In-reply-to: (message from Omprakash Gnawali on Fri, 15 Apr 2011 14:03:29 -0700) From: Richard Kelsey References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 16 Apr 2011 10:44:31.0042 (UTC) FILETIME=[44513A20:01CBFC23] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=YR9CI1MVwOMA:10 a=saA6nF2ZJaAA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=YpqjVgFN_2_vFA9RnXYA] X-AnalysisOut: [:9] Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 10:44:36 -0000 > From: Omprakash Gnawali > Date: Fri, 15 Apr 2011 14:03:29 -0700 > > Now that we are clear between no of0 and no metric container case, we > can discuss what MRHOF should do when there is no metric container. > Pascal has put in a lot of thought over the last several months on how > to do routing without metric containers so it makes sense to use that > work. I can state in MRHOF draft: > > "If there is no metric container, parent selection and rank > computation is done according to the mechanisms mentioned in OF0." > > Does that work? I would like to be able to use ETX as the rank directly, without the additional overhead of a metric container. It seems silly to send the same value twice, once as the rank and once wrapped in a metric container. -Richard From gnawali@cs.stanford.edu Sat Apr 16 08:55:01 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4DE64E066B for ; Sat, 16 Apr 2011 08:55:01 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAjJ8OLjZO0T for ; Sat, 16 Apr 2011 08:55:00 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfc.amsl.com (Postfix) with ESMTP id B12E7E0669 for ; Sat, 16 Apr 2011 08:55:00 -0700 (PDT) Received: from mail-px0-f182.google.com ([209.85.212.182]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1QB7pr-0002Es-JN for roll@ietf.org; Sat, 16 Apr 2011 08:54:59 -0700 Received: by pxi20 with SMTP id 20so2402310pxi.27 for ; Sat, 16 Apr 2011 08:54:59 -0700 (PDT) Received: by 10.68.66.40 with SMTP id c8mr3900894pbt.493.1302969299076; Sat, 16 Apr 2011 08:54:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Sat, 16 Apr 2011 08:54:39 -0700 (PDT) In-Reply-To: <878vvav5jt.fsf@kelsey-ws.hq.ember.com> References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com> <878vvav5jt.fsf@kelsey-ws.hq.ember.com> From: Omprakash Gnawali Date: Sat, 16 Apr 2011 08:54:39 -0700 Message-ID: To: Richard Kelsey Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 980022258218d8e0da9e8fd80fb6777b Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 15:55:01 -0000 On Sat, Apr 16, 2011 at 3:44 AM, Richard Kelsey wrote: >> From: Omprakash Gnawali >> Date: Fri, 15 Apr 2011 14:03:29 -0700 >> >> Now that we are clear between no of0 and no metric container case, we >> can discuss what MRHOF should do when there is no metric container. >> Pascal has put in a lot of thought over the last several months on how >> to do routing without metric containers so it makes sense to use that >> work. I can state in MRHOF draft: >> >> "If there is no metric container, parent selection and rank >> computation is done according to the mechanisms mentioned in OF0." >> >> Does that work? > > I would like to be able to use ETX as the rank directly, > without the additional overhead of a metric container. =A0It > seems silly to send the same value twice, once as the rank > and once wrapped in a metric container. Sure it is redundant for this particular metric but according to RPL, OFs are supposed to convert metrics to Rank. MRHOF is written within that framework. - om_p From pal@cs.stanford.edu Sat Apr 16 09:54:21 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8ED67E00BE for ; Sat, 16 Apr 2011 09:54:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WzW-WyeeaEXN for ; Sat, 16 Apr 2011 09:54:20 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs3.Stanford.EDU [171.64.64.27]) by ietfc.amsl.com (Postfix) with ESMTP id 759E9E06CA for ; Sat, 16 Apr 2011 09:54:20 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.100]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1QB8lH-0001Pq-Lx; Sat, 16 Apr 2011 09:54:19 -0700 In-Reply-To: <878vvav5jt.fsf@kelsey-ws.hq.ember.com> References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com> <878vvav5jt.fsf@kelsey-ws.hq.ember.com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0C0EDF1F-114A-4D0C-A680-25A379A8012A@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Sat, 16 Apr 2011 09:54:19 -0700 To: Richard Kelsey X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: b64bce576883819501cf77c9371f4538 Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 16:54:21 -0000 On Apr 16, 2011, at 3:44 AM, Richard Kelsey wrote: >> From: Omprakash Gnawali >> Date: Fri, 15 Apr 2011 14:03:29 -0700 >> >> Now that we are clear between no of0 and no metric container case, we >> can discuss what MRHOF should do when there is no metric container. >> Pascal has put in a lot of thought over the last several months on >> how >> to do routing without metric containers so it makes sense to use that >> work. I can state in MRHOF draft: >> >> "If there is no metric container, parent selection and rank >> computation is done according to the mechanisms mentioned in OF0." >> >> Does that work? > > I would like to be able to use ETX as the rank directly, > without the additional overhead of a metric container. It > seems silly to send the same value twice, once as the rank > and once wrapped in a metric container. This raises a good question -- would it be preferable for, in the absence of a metric container, for MRHOF to calculate Rank as in OF0, or to use ETX? Phil From richard.kelsey@ember.com Sat Apr 16 13:55:00 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 8A283E06A4 for ; Sat, 16 Apr 2011 13:55:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOJqxpnNs-ym for ; Sat, 16 Apr 2011 13:55:00 -0700 (PDT) Received: from p01c11o141.mxlogic.net (p01c11o141.mxlogic.net [208.65.144.64]) by ietfc.amsl.com (Postfix) with ESMTP id B0C73E0687 for ; Sat, 16 Apr 2011 13:54:59 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO EMPIRE.hq.ember.com) by p01c11o141.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 3220aad4.0.52346.00-379.103538.p01c11o141.mxlogic.net (envelope-from ); Sat, 16 Apr 2011 14:54:59 -0600 (MDT) X-MXL-Hash: 4daa022316aa4a3b-4761e492cb1e6ca6f677f39f53baa611c7c7de43 Received: from kelsey-ws.hq.ember.com ([192.168.81.75]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 16 Apr 2011 16:54:58 -0400 Date: Sat, 16 Apr 2011 16:55:20 -0400 Message-Id: <87y639rk5j.fsf@kelsey-ws.hq.ember.com> To: Omprakash Gnawali In-reply-to: (message from Omprakash Gnawali on Sat, 16 Apr 2011 08:54:39 -0700) From: Richard Kelsey References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com> <878vvav5jt.fsf@kelsey-ws.hq.ember.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Apr 2011 20:54:58.0218 (UTC) FILETIME=[8BD0C0A0:01CBFC78] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=YR9CI1MVwOMA:10 a=saA6nF2ZJaAA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=IkcTkHD0fZMA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=OQ] X-AnalysisOut: [_ktunLAAAA:8 a=6OfRjau3wRLApYFbNucA:9 a=QEXdDO2ut3YA:10 a=] X-AnalysisOut: [AuRza0os8rYA:10] Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 20:55:00 -0000 > From: Omprakash Gnawali > Date: Sat, 16 Apr 2011 08:54:39 -0700 > > On Sat, Apr 16, 2011 at 3:44 AM, Richard Kelsey > wrote: > > > > I would like to be able to use ETX as the rank directly, > > without the additional overhead of a metric container.  It > > seems silly to send the same value twice, once as the rank > > and once wrapped in a metric container. > > Sure it is redundant for this particular metric but according to RPL, > OFs are supposed to convert metrics to Rank. MRHOF is written within > that framework. I understand that in general the metric and rank are different values and need to be sent separately. But when the conversion to rank is the identity function, it would be simpler and more efficient to leave off the metric container. -Richard From richard.kelsey@ember.com Sat Apr 16 15:01:08 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 3297DE0738 for ; Sat, 16 Apr 2011 15:01:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A06gZ9mePzBV for ; Sat, 16 Apr 2011 15:01:07 -0700 (PDT) Received: from p01c11o149.mxlogic.net (p01c11o149.mxlogic.net [208.65.144.72]) by ietfc.amsl.com (Postfix) with ESMTP id 4BA91E0673 for ; Sat, 16 Apr 2011 15:01:07 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO EMPIRE.hq.ember.com) by p01c11o149.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 2a11aad4.0.53783.00-381.103652.p01c11o149.mxlogic.net (envelope-from ); Sat, 16 Apr 2011 16:01:07 -0600 (MDT) X-MXL-Hash: 4daa11a36597d69a-2ffbec4045c98823012b5658fd3aa05164234a61 Received: from kelsey-ws.hq.ember.com ([192.168.81.75]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 16 Apr 2011 18:00:42 -0400 Date: Sat, 16 Apr 2011 18:01:04 -0400 Message-Id: <87writrh3z.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: <0C0EDF1F-114A-4D0C-A680-25A379A8012A@cs.stanford.edu> (message from Philip Levis on Sat, 16 Apr 2011 09:54:19 -0700) From: Richard Kelsey References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com> <878vvav5jt.fsf@kelsey-ws.hq.ember.com> <0C0EDF1F-114A-4D0C-A680-25A379A8012A@cs.stanford.edu> X-OriginalArrivalTime: 16 Apr 2011 22:00:42.0171 (UTC) FILETIME=[BA9838B0:01CBFC81] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=YR9CI1MVwOMA:10 a=saA6nF2ZJaAA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=B85tiQNdJmw8VD_khPMA] X-AnalysisOut: [:9] Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 22:01:08 -0000 > From: Philip Levis > Date: Sat, 16 Apr 2011 09:54:19 -0700 > > This raises a good question -- would it be preferable for, in the > absence of a metric container, for MRHOF to calculate Rank as in OF0, > or to use ETX? Would it be possible to allow both? While many devices may need to delay the choice of metric or objective function until RPL is actually running, for many embedded devices these have to be built in at the factory. Perhaps the MRHOF document could say that in the absence of a metric container the default is Rank as in OF0, but that other options, such as using Rank == ETX, may be configured out of band. -Richard From pal@cs.stanford.edu Sat Apr 16 15:06:19 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 4034AE0738 for ; Sat, 16 Apr 2011 15:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pLaEP28B4UM5 for ; Sat, 16 Apr 2011 15:06:18 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfc.amsl.com (Postfix) with ESMTP id 7CFD4E0674 for ; Sat, 16 Apr 2011 15:06:18 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.104]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1QBDd6-0006Gu-VQ; Sat, 16 Apr 2011 15:06:17 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <87writrh3z.fsf@kelsey-ws.hq.ember.com> Date: Sat, 16 Apr 2011 15:06:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com> <878vvav5jt.fsf@kelsey-ws.hq.ember.com> <0C0EDF1F-114A-4D0C-A680-25A379A8012A@cs.stanford.edu> <87writrh3z.fsf@kelsey-ws.hq.ember.com> To: Richard Kelsey X-Mailer: Apple Mail (2.1084) X-Scan-Signature: f219e97bb238ccbb8ed40879dafdba3c Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Apr 2011 22:06:19 -0000 On Apr 16, 2011, at 3:01 PM, Richard Kelsey wrote: >> From: Philip Levis >> Date: Sat, 16 Apr 2011 09:54:19 -0700 >>=20 >> This raises a good question -- would it be preferable for, in the =20 >> absence of a metric container, for MRHOF to calculate Rank as in OF0, = =20 >> or to use ETX? >=20 > Would it be possible to allow both? While many devices may > need to delay the choice of metric or objective function > until RPL is actually running, for many embedded devices > these have to be built in at the factory. >=20 > Perhaps the MRHOF document could say that in the absence of > a metric container the default is Rank as in OF0, but that > other options, such as using Rank =3D=3D ETX, may be configured > out of band. I don't understand -- one could certainly configure a node to use ETX = for Rank if there is no metric container provided: OF0 is quite explicit = that one could do this. The issue is not what a node uses, but rather = what it can assume other nodes use. Or are you suggesting some = additional protocol exchange for a node to query another node on how = it's computing Rank with OF0? I don't think that's a good idea. Phil From pthubert@cisco.com Sun Apr 17 23:58:09 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 19304E0655 for ; Sun, 17 Apr 2011 23:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.165 X-Spam-Level: X-Spam-Status: No, score=-0.165 tagged_above=-999 required=5 tests=[AWL=-9.566, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, URIBL_BLACK=20] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ScJ6dV0+LWPs for ; Sun, 17 Apr 2011 23:58:04 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 3FFA4E0771 for ; Sun, 17 Apr 2011 23:58:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2854; q=dns/txt; s=iport; t=1303109884; x=1304319484; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=pTUZBzqtIDGUlcHstVjKsblZo7CSLFafPYaffyMLftU=; b=QkbedwbGKulIRirjlIRRF6B/xe+f9WeGPTcnk7RChdAAmYBwvPhWgWqI fk9URoS9S6dcYZkDQIRWBRmlaTbN0ACDiXVv2+zi7Gu5Kvc3wkFkiC6hx YLTs9L2/GmJm67SdZohicQLhDvqycTzTHkZT/BHKRRNN1lhAXCI3NM6ht M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4AABzgq02Q/khNgWdsb2JhbACXWI4AFAEBFiYlpmmbOoVxBJF+iTg X-IronPort-AV: E=Sophos;i="4.64,231,1301875200"; d="scan'208";a="26058874" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 18 Apr 2011 06:58:03 +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 p3I6w3EN032398; Mon, 18 Apr 2011 06:58:03 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); Mon, 18 Apr 2011 08:58:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Apr 2011 08:58:00 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0464F759@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 Thread-Index: Acv8goohqTiK538cRZ6Ih6bHi9InSgBEhrWQ References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com><6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com><878vvav5jt.fsf@kelsey-ws.hq.ember.com><0C0EDF1F-114A-4D0C-A680-25A379A8012A@cs.stanford.edu><87writrh3z.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Richard Kelsey" X-OriginalArrivalTime: 18 Apr 2011 06:58:03.0352 (UTC) FILETIME=[F63FC580:01CBFD95] Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 06:58:09 -0000 I think I agree with Phil here; Richard, we specifically wanted to allow what you also ask for, that is that OF0 can use with ETX to compute Rank. But we had to leave some room for people who'd do it differently, probably for other types of links. Eg, a wire could use a static cost, wifi infra mode could transform the current data rate into Rank, etc... We leave the exact formula for ETX to Rank to the implementation, but we recommend taking a look at how Mr Hof does it. In turn, I'd have expected that when Mr Hof does not have a container, it recommends ETX within the OF0 contraints so that Mr Hof can actually present itself as an OF0. I my mind, this means providing a more specific formula for Rank -> ETX, and obeying the various normalization rules in OF0. This being said, I still have to answer Phoebus ' long email, and one of the topics is whether we want a config container. Like Phil below, I cannot see that container explaining OF0 how to compute Rank, but I can see a container passing a default value for the stretch for instance. We'll see what people think about that. Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Philip Levis > Sent: Sunday, April 17, 2011 12:06 AM > To: Richard Kelsey > Cc: roll@ietf.org > Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 >=20 >=20 > On Apr 16, 2011, at 3:01 PM, Richard Kelsey wrote: >=20 > >> From: Philip Levis > >> Date: Sat, 16 Apr 2011 09:54:19 -0700 > >> > >> This raises a good question -- would it be preferable for, in the > >> absence of a metric container, for MRHOF to calculate Rank as in OF0, > >> or to use ETX? > > > > Would it be possible to allow both? While many devices may need to > > delay the choice of metric or objective function until RPL is actually > > running, for many embedded devices these have to be built in at the > > factory. > > > > Perhaps the MRHOF document could say that in the absence of a metric > > container the default is Rank as in OF0, but that other options, such > > as using Rank =3D=3D ETX, may be configured out of band. >=20 > I don't understand -- one could certainly configure a node to use ETX for Rank > if there is no metric container provided: OF0 is quite explicit that one could > do this. The issue is not what a node uses, but rather what it can assume > other nodes use. Or are you suggesting some additional protocol exchange > for a node to query another node on how it's computing Rank with OF0? I > don't think that's a good idea. >=20 > Phil >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Apr 18 01:13:11 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id A7637E06FA for ; Mon, 18 Apr 2011 01:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.482 X-Spam-Level: X-Spam-Status: No, score=-9.482 tagged_above=-999 required=5 tests=[AWL=1.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CppDxQpJfmjw for ; Mon, 18 Apr 2011 01:13:07 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 7458BE067F for ; Mon, 18 Apr 2011 01:13:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=537; q=dns/txt; s=iport; t=1303114387; x=1304323987; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=TRhpMknzuBw8pQmE0aDEFCpjUQIdFENKSNVnflCEhs4=; b=R+r4cgsx6bjM3SQDVdxJiqmqSBFG1xXW3fMTDAxqsnYYFNa+NsbdmTQS dP1BmIAuTCS6sCXBNaLFbPd3atNZNxYgACjn3SKnkqbnRuvtLfSjo1Fb8 yh2bA4RC9tewP/BZs5e9xG+aFtueHaC/5lnm4diycY5n+7OC1zoT0MBMo I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: An8EAK3xq02Q/khNgWdsb2JhbAClWRQBARYmJaYFm1GFcQSRfok4 X-IronPort-AV: E=Sophos;i="4.64,231,1301875200"; d="scan'208";a="26070595" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 18 Apr 2011 08:13:06 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3I8D6sO020309; Mon, 18 Apr 2011 08:13:06 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); Mon, 18 Apr 2011 10:13:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 18 Apr 2011 10:13:03 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0464F79C@XMB-AMS-107.cisco.com> In-Reply-To: <0C0EDF1F-114A-4D0C-A680-25A379A8012A@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 Thread-Index: Acv8VvQ3zTPUCTA4TAq8WYpKxrUbSQBSTbdw References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com><6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com><878vvav5jt.fsf@kelsey-ws.hq.ember.com> <0C0EDF1F-114A-4D0C-A680-25A379A8012A@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Richard Kelsey" X-OriginalArrivalTime: 18 Apr 2011 08:13:06.0621 (UTC) FILETIME=[726816D0:01CBFDA0] Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 08:13:11 -0000 > > > > I would like to be able to use ETX as the rank directly, without the > > additional overhead of a metric container. It seems silly to send the > > same value twice, once as the rank and once wrapped in a metric > > container. >=20 > This raises a good question -- would it be preferable for, in the absence of a > metric container, for MRHOF to calculate Rank as in OF0, or to use ETX? >=20 [Pascal] OF0 does not calculate Rank. =20 Is there something that prevents it an OF0 to use ETX? Rounding error? Pascal From richard.kelsey@ember.com Mon Apr 18 04:03:29 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7433EE07BC for ; Mon, 18 Apr 2011 04:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EqUzfekUgrXo for ; Mon, 18 Apr 2011 04:03:28 -0700 (PDT) Received: from p01c11o149.mxlogic.net (p01c11o149.mxlogic.net [208.65.144.72]) by ietfc.amsl.com (Postfix) with ESMTP id 87977E07BB for ; Mon, 18 Apr 2011 04:03:28 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO EMPIRE.hq.ember.com) by p01c11o149.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id f7a1cad4.0.10398.00-387.20872.p01c11o149.mxlogic.net (envelope-from ); Mon, 18 Apr 2011 05:03:28 -0600 (MDT) X-MXL-Hash: 4dac1a8079b95cbd-8baa52e92aed0d4cb7e59344adc9c0c475e9f587 Received: from kelsey-ws.hq.ember.com ([192.168.81.75]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 18 Apr 2011 07:03:24 -0400 Date: Mon, 18 Apr 2011 07:03:50 -0400 Message-Id: <87oc43q0rt.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: (message from Philip Levis on Sat, 16 Apr 2011 15:06:12 -0700) From: Richard Kelsey References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com> <878vvav5jt.fsf@kelsey-ws.hq.ember.com> <0C0EDF1F-114A-4D0C-A680-25A379A8012A@cs.stanford.edu> <87writrh3z.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 18 Apr 2011 11:03:24.0683 (UTC) FILETIME=[3CD89DB0:01CBFDB8] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=YR9CI1MVwOMA:10 a=saA6nF2ZJaAA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=xmqIokwICcerlA4kA6IA] X-AnalysisOut: [:9] Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Apr 2011 11:03:29 -0000 > From: Philip Levis > Date: Sat, 16 Apr 2011 15:06:12 -0700 > > I don't understand -- one could certainly configure a node to use ETX > for Rank if there is no metric container provided: OF0 is quite > explicit that one could do this. The issue is not what a node uses, > but rather what it can assume other nodes use. Or are you suggesting > some additional protocol exchange for a node to query another node on > how it's computing Rank with OF0? I don't think that's a good idea. What I would like to do is to make sending configuration information optional, the way RPL security is optional. For the kind of systems I work with, small embedded devices that go into autonomous, multi-vendor networks, the protocols versions, options and so forth must be determined ahead of time. This makes most over-the-air configuration redundant. In most cases the redundant overhead isn't much, so we do it anyway. When using ETX, or in any other case where the metric value can be derived from the Rank, it would be nice not to have to send the metric container. -Richard From jpv@cisco.com Tue Apr 19 12:24:36 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 0AA5CE0761 for ; Tue, 19 Apr 2011 12:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.102 X-Spam-Level: X-Spam-Status: No, score=-110.102 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzH5zlHQYKAT for ; Tue, 19 Apr 2011 12:24:35 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfc.amsl.com (Postfix) with ESMTP id 2D9ECE072D for ; Tue, 19 Apr 2011 12:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=1890; q=dns/txt; s=iport; t=1303241075; x=1304450675; h=from:subject:date:message-id:to:mime-version; bh=g6EB+GIOaAWj2kf9LJbuuI38aASTYmHNnAxN4GYPZ3k=; b=Sk7FYVwKqDZuByO8beAHBI674x8q2Whk7AfSEH0GoJJIS3SKPkFTKLan kNY1sbG/gqZ+WjQNrDvYnLRaCaR5/uhBfH5QgblKvjPOKhxa/IJ1/2GVS tl2EBQvoPJpvKtkg+XT0IZWM37vZly1I2v6tYTiclRH9DTgoLP301B4/c 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkMEADngrU2Q/khNgWdsb2JhbAClLhQBARYmJag4nG+FcQSOB4N8Bw X-IronPort-AV: E=Sophos;i="4.64,241,1301875200"; d="scan'208,217";a="26334720" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 19 Apr 2011 19:24:34 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p3JJOYXA022890 for ; Tue, 19 Apr 2011 19:24:34 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 21:24:34 +0200 Received: from [10.112.135.6] ([10.61.104.119]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Apr 2011 21:24:34 +0200 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-113-663834012 Date: Tue, 19 Apr 2011 21:24:24 +0200 Message-Id: To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-OriginalArrivalTime: 19 Apr 2011 19:24:34.0068 (UTC) FILETIME=[6A026540:01CBFEC7] Subject: [Roll] Organizing our Applicability Statement Work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 19:24:36 -0000 --Apple-Mail-113-663834012 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, As you know, we have updated our milestones with two main WG items that = we need to finish: 1) The P2P work: good progress, the authors mentioned that they were = making good progress. 2) The applicability statements: a number of you mentioned that they = were willing to work on=20 applicability statements on smart metering, industrial automation, home = and building automation. If you are willing to work on them, it is a good time to chime in ! I'll send a proposal so that all applicability statements adopt an = identical template (Adrian also=20 provided very useful feed-back). More soon. Cheers. JP.= --Apple-Mail-113-663834012 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Dear all,

As you know, we have updated our milestones with two main WG items that we need to finish:

1) The P2P work: good progress, the authors mentioned that they were making good progress.

2) The applicability statements: a number of you mentioned that they were willing to work on 
applicability statements on smart metering, industrial automation, home and building automation.
If you are willing to work on them, it is a good time to chime in !

I'll send a proposal so that all applicability statements adopt an identical template (Adrian also 
provided very useful feed-back).

More soon.

Cheers.

JP.
--Apple-Mail-113-663834012-- From gnawali@cs.stanford.edu Tue Apr 19 12:34:07 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 7010CE0761 for ; Tue, 19 Apr 2011 12:34:07 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3hHACPMXBCcL for ; Tue, 19 Apr 2011 12:34:05 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfc.amsl.com (Postfix) with ESMTP id 0BECAE084A for ; Tue, 19 Apr 2011 12:34:04 -0700 (PDT) Received: from mail-pv0-f172.google.com ([74.125.83.172]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1QCGgU-0006If-Fd for roll@ietf.org; Tue, 19 Apr 2011 12:34:02 -0700 Received: by pvh1 with SMTP id 1so11275pvh.31 for ; Tue, 19 Apr 2011 12:34:02 -0700 (PDT) Received: by 10.68.7.231 with SMTP id m7mr9212508pba.91.1303241642039; Tue, 19 Apr 2011 12:34:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Tue, 19 Apr 2011 12:33:42 -0700 (PDT) In-Reply-To: <87oc43q0rt.fsf@kelsey-ws.hq.ember.com> References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com> <878vvav5jt.fsf@kelsey-ws.hq.ember.com> <0C0EDF1F-114A-4D0C-A680-25A379A8012A@cs.stanford.edu> <87writrh3z.fsf@kelsey-ws.hq.ember.com> <87oc43q0rt.fsf@kelsey-ws.hq.ember.com> From: Omprakash Gnawali Date: Tue, 19 Apr 2011 12:33:42 -0700 Message-ID: To: Richard Kelsey Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 67f4a389e065da33eb5969ecb4726704 Cc: roll@ietf.org Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Apr 2011 19:34:07 -0000 On Mon, Apr 18, 2011 at 4:03 AM, Richard Kelsey wrote: >> From: Philip Levis >> Date: Sat, 16 Apr 2011 15:06:12 -0700 >> >> I don't understand -- one could certainly configure a node to use ETX >> for Rank if there is no metric container provided: OF0 is quite >> explicit that one could do this. The issue is not what a node uses, >> but rather what it can assume other nodes use. Or are you suggesting >> some additional protocol exchange for a node to query another node on >> how it's computing Rank with OF0? I don't think that's a good idea. > > What I would like to do is to make sending configuration > information optional, the way RPL security is optional. =A0For > the kind of systems I work with, small embedded devices that > go into autonomous, multi-vendor networks, the protocols > versions, options and so forth must be determined ahead of > time. =A0This makes most over-the-air configuration redundant. > In most cases the redundant overhead isn't much, so we do it > anyway. =A0When using ETX, or in any other case where the > metric value can be derived from the Rank, it would be nice > not to have to send the metric container. I am fine with doing routing based on ETX if there are no metric containers. The way it would work is - you compute the Rank based on ETX, which is an identity function. Then you just advertise that Rank. The receiving nodes, in the absence of metric container, can convert the Rank to ETX, which is an identity function, and compute their path cost, convert that to Rank and advertise that. This mechanism will allow simple and efficient implementation for the most likely use case. Richard - is this what you had in mind? - om_p From gnawali@cs.stanford.edu Tue Apr 19 19:19:57 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id EF8A2E0814 for ; Tue, 19 Apr 2011 19:19:57 -0700 (PDT) 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 ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZmfL9fZjoQ4 for ; Tue, 19 Apr 2011 19:19:57 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfc.amsl.com (Postfix) with ESMTP id 686DAE0730 for ; Tue, 19 Apr 2011 19:19:57 -0700 (PDT) Received: from mail-pw0-f44.google.com ([209.85.160.44]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1QCN1I-00084A-Gw for roll@ietf.org; Tue, 19 Apr 2011 19:19:56 -0700 Received: by pwi5 with SMTP id 5so217461pwi.31 for ; Tue, 19 Apr 2011 19:19:56 -0700 (PDT) Received: by 10.68.7.231 with SMTP id m7mr9748886pba.91.1303265996086; Tue, 19 Apr 2011 19:19:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Tue, 19 Apr 2011 19:19:36 -0700 (PDT) In-Reply-To: <87y6353dxc.fsf@kelsey-ws.hq.ember.com> References: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0444111E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D044F832E@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D0459F454@XMB-AMS-107.cisco.com> <878vvav5jt.fsf@kelsey-ws.hq.ember.com> <0C0EDF1F-114A-4D0C-A680-25A379A8012A@cs.stanford.edu> <87writrh3z.fsf@kelsey-ws.hq.ember.com> <87oc43q0rt.fsf@kelsey-ws.hq.ember.com> <87y6353dxc.fsf@kelsey-ws.hq.ember.com> From: Omprakash Gnawali Date: Tue, 19 Apr 2011 19:19:36 -0700 Message-ID: To: Richard Kelsey , ROLL WG Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 764eb63bb4c91aa8ddbf2de6f9e489d2 Subject: Re: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 02:19:58 -0000 On Tue, Apr 19, 2011 at 6:32 PM, Richard Kelsey wrote: >> From: Omprakash Gnawali >> Date: Tue, 19 Apr 2011 12:33:42 -0700 >> >> I am fine with doing routing based on ETX if there are no metric >> containers. The way it would work is - you compute the Rank based on >> ETX, which is an identity function. Then you just advertise that Rank. >> The receiving nodes, in the absence of metric container, can convert >> the Rank to ETX, which is an identity function, and compute their path >> cost, convert that to Rank and advertise that. This mechanism will >> allow simple and efficient implementation for the most likely use >> case. >> >> Richard - is this what you had in mind? > > Yes, that is exactly what I was thinking of. Perfect. I will update the draft accordingly. - om_p From pthubert@cisco.com Tue Apr 19 23:31:24 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9E6C3E076D for ; Tue, 19 Apr 2011 23:31:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.004 X-Spam-Level: * X-Spam-Status: No, score=1.004 tagged_above=-999 required=5 tests=[AWL=-8.398, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, URIBL_BLACK=20] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HI+AZVsEPxAx for ; Tue, 19 Apr 2011 23:31:23 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id D8464E075D for ; Tue, 19 Apr 2011 23:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=6894; q=dns/txt; s=iport; t=1303281083; x=1304490683; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=kmhicqk0aBZi9QNJmgyw+1mBP3/z8loAJCMx/ISfoAc=; b=iRi2qjaeOJYxScZIAHR4dTmH+gNT4ALqTyBNqJ4krtd1l3WDIAHTvQ5O fEomuB7pqlwA9IO2UxZeOmm4rw8O6QbHM3EZhnWd/lN49BsfcGnFoqdIK bnKHODpbZh2/qCdFOWL7Tjvs3KMLpheFRBFcz4Io334FgIMFo39JM1mSr Y=; X-IronPort-AV: E=Sophos;i="4.64,244,1301875200"; d="scan'208,217";a="84325996" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 20 Apr 2011 06:31:22 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p3K6VMkr010111; Wed, 20 Apr 2011 06:31:22 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 20 Apr 2011 08:31:21 +0200 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_01CBFF24.9037812E" Date: Wed, 20 Apr 2011 08:31:19 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0464FE81@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Organizing our Applicability Statement Work Thread-Index: Acv+x9cEoFF1J+fLSgaWEb7iF+GRmgAXHKKQ References: From: "Pascal Thubert (pthubert)" To: "JP Vasseur" , "ROLL WG" X-OriginalArrivalTime: 20 Apr 2011 06:31:21.0960 (UTC) FILETIME=[90923E80:01CBFF24] Cc: tom.phinney@COX.NET, Robert Assimiti Subject: Re: [Roll] Organizing our Applicability Statement Work X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Apr 2011 06:31:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBFF24.9037812E Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi JP: =20 Tom Phinney, Robert Assimiti and I have started work on industrial. The template will be much appreciated. =20 Cheers, =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Tuesday, April 19, 2011 9:24 PM To: ROLL WG Subject: [Roll] Organizing our Applicability Statement Work =20 Dear all, =20 As you know, we have updated our milestones with two main WG items that we need to finish: =20 1) The P2P work: good progress, the authors mentioned that they were making good progress. =20 2) The applicability statements: a number of you mentioned that they were willing to work on=20 applicability statements on smart metering, industrial automation, home and building automation. If you are willing to work on them, it is a good time to chime in ! =20 I'll send a proposal so that all applicability statements adopt an identical template (Adrian also=20 provided very useful feed-back). =20 More soon. =20 Cheers. =20 JP. ------_=_NextPart_001_01CBFF24.9037812E Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi JP:

 

Tom Phinney, Robert Assimiti and I have started work on industrial. = The template will be much appreciated.

 

Cheers,

 

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur
Sent: Tuesday, April 19, 2011 9:24 = PM
To: ROLL WG
Subject: [Roll] Organizing our = Applicability Statement Work

 

Dear = all,

 

As you know, we have updated our milestones with two = main WG items that we need to finish:

 

1) The P2P work: good progress, the authors mentioned = that they were making good progress.

 

2) The applicability statements: a number of you = mentioned that they were willing to work = on 

applicability = statements on smart metering, industrial automation, home and building = automation.

If you = are willing to work on them, it is a good time to chime in = !

 

I'll send a proposal so that all applicability = statements adopt an identical template (Adrian = also 

provided very = useful feed-back).

 

More soon.

 

Cheers.

 

JP.

------_=_NextPart_001_01CBFF24.9037812E-- From pthubert@cisco.com Thu Apr 21 01:41:16 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 9DC86E0698 for ; Thu, 21 Apr 2011 01:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.423 X-Spam-Level: X-Spam-Status: No, score=-9.423 tagged_above=-999 required=5 tests=[AWL=2.576, BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k+wkJhb7-NZr for ; Thu, 21 Apr 2011 01:41:13 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfc.amsl.com (Postfix) with ESMTP id 5C5C6E0696 for ; Thu, 21 Apr 2011 01:41:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=33300; q=dns/txt; s=iport; t=1303375272; x=1304584872; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=tWJtD4vRnBVaXMWchPhh/N2NKCBJJ+svB03qECw3R2w=; b=AdsTeiQ8GsXiSx6oQT5GOekYHMsY+xMn9+CLEFp7Zssz3zY8L1mtJ378 4wOZJHlBSkAHwAQnnYx2cORDFpjjIgiDbg1kxHQZoppGmFeU3Vb6jbYYz 4MW+X1bLFVLaM64IS2tXXLjJTV8uiqMCHcy/dCUggDNpdv1x/AIYFw93Q w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEEAFrsr02Q/khLgWdsb2JhbAAwpRgUAQEWJiWIcJ8enF0ChXQEkjc X-IronPort-AV: E=Sophos;i="4.64,250,1301875200"; d="scan'208";a="84536416" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 21 Apr 2011 08:41:11 +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 p3L8fBqt003027; Thu, 21 Apr 2011 08:41:11 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); Thu, 21 Apr 2011 10:41:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 21 Apr 2011 10:41:08 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D04650322@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments Thread-Index: Acv//9svxGeM+0OwQjGl153wVxtGvA== From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 21 Apr 2011 08:41:11.0104 (UTC) FILETIME=[DDAD0C00:01CBFFFF] Cc: roll@ietf.org Subject: Re: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 08:41:16 -0000 Hello Phoebus : ) Where have you been? We've been missing your excellent comments. > Sorry these comments are coming so late, after last call. I hope you > can at least incorporate some of them. [Pascal] That's beyond me. I suppose that the shepherd has to decide. Let's see: >=20 > My comments below are based on my current understanding that > Phil and you are no longer using hop-count as the rank increment. Instead, > each node will have an implementation specific way of converting a node or > link cost to a rank. I'm still unclear if there is a preference rule to try to stick > with using the same metrics as the metrics advertised in a received DIO, if > the current node has access to multiple types of metrics (energy, LQI, ETX, > etc.). That would allow the root node to specify a preferred type of metric to > use in the instance. >=20 >=20 > Major Points: > ************* > 1) I'm still hoping that the format for writing Objective Function specifications > can be more uniform, as I mentioned in an earlier comment (point number 7 > in http://www.ietf.org/mail-archive/web/roll/current/msg03240.html). > Comparing MRHOF and OF0, I think that the discussion on Step-of-Rank / > Stretch-of-Rank etc. can be moved to it's own subsection. >=20 > I suggest the following reorganization of sections: >=20 > 3. Objective Function 0 > 3.1. Computing Rank-increase > 3.2. Parent / Backup Successor Selection > 3.2.1. Selection of the Preferred Parent > 3.2.2. Selection of the backup feasible successor > 3.3. Advertising Rank-increase > 4. Interface with RPL core >=20 [Pascal] Looks good. That much is doc organization and I suppose I can accommodate it at this stage. It would certainly be beneficial if both OF drafts have a common structure. > If you are allowing the root to specified a preferred metric type, then Section > 3.3. should state how to propagate this preference. I would have assumed > it's by propagating an empty DAG/Metric Container, but in (Section 2.1, draft- > ietf-roll-routing-metrics-19) it says "The object body carries one or more sub- > objects defined later in this document" > which means you cannot have empty containers. [Pascal] OF0 does not have metric containers at all, so they do not need to be empty. That's because OF0 is generic, for the better or the worse. Because we want all implementations to interop with OF0, regardless of the medium etc... So the idea is to have no constraint on what the implementation uses to derive the Rank, no container, no configuration option, just the base RPL spec. Rather, we normalize the resulting values so they can compare between implementations.=20 Now, I understand that a configuration container could help make the OF more self-contained/autonomic.=20 > Maybe the overview in Section 3 should also state explicitly that the > processing rules of a DIO must do 3.1, then 3.2, then 3.3, in that order. [Pascal] Yes, and this is what we mean by " As it scans all the candidate neighbors, OF0 keeps the parent that is the best for the following criteria (in order):" the language may not be perfect but I hardly think the reader can be getting the text wrong. I'm open to an editorial change if the sense is conserved. >=20 >=20 > 2) There have been two variables and one parameter defined in the > overview section, but they are not mentioned in Section 7, OF0 Constants > and Variables. > Variables: Step-of-Rank, Stretch-of-Rank > Parameters: Rank-factor > (I noticed that there is no MINIMUM_RANK_STRETCH and > DEFAULT_RANK_STRETCH and presume this is intentional.) >=20 [Pascal] You're right. A stretch of 0 is acceptable so there is no MINIMUM. If there was a DEFAULT I expect it should be zero as well. By compliance with the main spec. I'm fine adding it. What do you think? > Also, it would be nice to use underscore instead of hyphen for > variables, like in MRHOF (and use capital letters for parameters). >=20 [Pascal] OK. I did not really mean those as variables, but why not. > Finally, how is Stretch-of-Rank computed? Implementation dependent? [Pascal] It is not computed. It is configured and can be left to 0. Does not have to be there at all in an implementation. I can clarify that. > 3) How does one configure the parameter(s) (Rank-Factor) from the root? > (I just realized that this same comment applies to the parameters in > MRHOF as well). Or is that not configurable from the root, but must be > configured before deployment of the nodes? [Pascal] The Rank factor has to be a per node policy, like the Stretch-of-Rank. Right now, we do not have config containers to distribute it. >=20 > 4) I think it would be nice to adopt the format of > draft-ietf-roll-rpl-19 and draft-ietf-roll-minrank-hysteresis-of for the > Terminology section. That is, write the word, then the definition (this > is not done for "feasible successor" in this section). Some other words > to define in this section are "Rank-increase," "RPL core," and "higher > order interface." Unless the last one is common IPv6 terminology that I > am unaware of... I was unable to tell if that meant the higher order > bits of the interface are higher, or if the interface is somehow preferred. I think that the RPL terminology is the place for having those in common. >=20 > 5) Just a reminder that the discussion on Rank-increase in the > introduction section > "OF0 uses a unit of Rank-increase of 0x100 so that Rank value can be > stored in one octet." > needs to be aligned with text in Section 3, > "Ri =3D Rf*Sp + Sr" > so that they are consistent. I see you are discussing this with Omprakash. Sp and Sr are expressed as units of 0x100 and Rf is integer, so they are consistent. Do I miss something? >=20 > 6) I like the "Abstract Interface with RPL core" section, but would it > be better to separate them into "Input" and "Output"? That would end up > splitting up "Providing DAG information" and "Providing a Parent List" > into two pieces though. >=20 >=20 > More minor editorial comments to follow below, preceded by PC>. Thanks for those. I'll include them in a rev. >=20 > -- > Phoebus Chen > Postdoctoral Researcher > Automatic Control Lab, KTH (Royal Institute of Technology) > http://www.ee.kth.se/~phoebus >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > ROLL P. Thubert, Ed. > Internet-Draft Cisco Systems > Intended status: Standards Track April 5, 2011 > Expires: October 7, 2011 >=20 >=20 > RPL Objective Function 0 > draft-ietf-roll-of0-09 >=20 > Abstract >=20 > The Routing Protocol for Low Power and Lossy Networks defines a > generic Distance Vector protocol for Low Power and Lossy Networks. > That generic protocol requires a specific Objective Function to > establish a desired routing topology. This specification defines a > basic Objective Function that operates solely with the protocol > elements defined in the generic protocol specification. >=20 > Requirements Language >=20 > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in > this > document are to be interpreted as described in RFC 2119 [RFC2119]. >=20 > Status of this Memo >=20 > This Internet-Draft is submitted in full conformance with the > provisions of BCP 78 and BCP 79. >=20 > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF). Note that other groups may also distribute > working documents as Internet-Drafts. The list of current Internet- > Drafts is at http://datatracker.ietf.org/drafts/current/. >=20 > Internet-Drafts are draft documents valid for a maximum of six months > and may be updated, replaced, or obsoleted by other documents at any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." >=20 > This Internet-Draft will expire on October 7, 2011. >=20 > Copyright Notice >=20 > Copyright (c) 2011 IETF Trust and the persons identified as the > document authors. All rights reserved. >=20 > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents >=20 >=20 >=20 > Thubert Expires October 7, 2011 [Page 1] >=20 > Internet-Draft draft-ietf-roll-of0 April 2011 >=20 >=20 > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with respect > to this document. Code Components extracted from this document must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the Simplified BSD License. >=20 >=20 > Table of Contents >=20 > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 3. Objective Function 0 Overview . . . . . . . . . . . . . . . . 4 > 4. Selection of the Preferred Parent . . . . . . . . . . . . . . 6 > 5. Selection of the backup feasible successor . . . . . . . . . . 7 > 6. Abstract Interface with RPL core . . . . . . . . . . . . . . . 7 > 7. OF0 Constants and Variables . . . . . . . . . . . . . . . . . 8 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 > 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 > 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 > 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 > 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 > 11.2. Informative References . . . . . . . . . . . . . . . . . 9 > Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Thubert Expires October 7, 2011 [Page 2] >=20 > Internet-Draft draft-ietf-roll-of0 April 2011 >=20 >=20 > 1. Introduction >=20 > The IETF ROLL Working Group has defined application-specific routing > requirements for a Low Power and Lossy Network (LLN) routing > protocol, specified in [RFC5548], [RFC5673], [RFC5826], and > [RFC5867]. >=20 > The Routing Protocol for Low Power and Lossy Networks > [I-D.ietf-roll-rpl] was designed as a generic core that is agnostic > to metrics and that is adapted to a given problem using Objective > Functions (OF). This separation of Objective Functions from the core > protocol specification allows RPL to adapt to meet the different > optimization criteria the wide range of use cases requires. >=20 > PC> s/the wide range of use cases requires/required by the wide range of > use cases/ >=20 > RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) > within instances of the protocol. Each instance is associated with > an Objective Function that is designed to solve the problem that is > addressed by that instance. >=20 > PC> remove "that is designed to solve the problem that is addressed by > that instance". Sounds almost like a tautology. >=20 >=20 > An Objective Function selects the DODAG Version that a device joins, > and a number of neighbor routers within that Version as parents or > feasible successors. The OF generates the Rank of the device, that > represents an abstract distance to the root within the DODAG. In > turn, the Rank is used by the generic RPL core to enable a degree of > loop avoidance and verify forward progression towards a destination, > as specified in [I-D.ietf-roll-rpl]. >=20 > PC> Do you intend to capitalize "Rank" and "Version" here? >=20 > The Objective Function 0 (OF0) corresponds to the Objective Code > Point 0 (OCP0). OF0 only requires the information in the RPL DIO > base container, such as Rank and the DODAGPreference field that > describes an administrative preference [I-D.ietf-roll-rpl]. The Rank > of a node is obtained by adding a normalized scalar Rank-increase to >=20 > PC> s/Rank-increase/, Rank-increase,/ >=20 > the Rank of a selected preferred parent. OF0 uses a unit of Rank- > increase of 0x100 so that Rank value can be stored in one octet. > This allows up to at least 28 hops even when default settings are > used and each hop has the worst Rank-increase of 9. >=20 > Since there is no default OF or metric container in the RPL main > specification, it might happen that, unless given two implementations >=20 > PC> s/given two/two given/ >=20 > follow a same guidance for a specific problem or environment, those >=20 > PC> s/a same/the same/ >=20 > implementations will not support a common OF with which they could > interoperate. OF0 is designed to be used as a common denominator >=20 > PC> I'm not sure what you mean by "common denominator" here. Are you > just trying to say that OF0 must be supported by all implementations of > RPL? What is a "generic implementation"? >=20 > between all generic implementations. This is why it is very abstract > as to how the link properties are transformed into a Rank-increase > and leaves that responsibility to implementation; rather, OF0 > enforces normalized values for the Rank-increase of a normal link and > its acceptable range, as opposed to formulating the details of the >=20 > PC> s/details of the/details of/ >=20 > its computation. This is also why OF0 ignores metric containers. >=20 >=20 >=20 > Thubert Expires October 7, 2011 [Page 3] >=20 > Internet-Draft draft-ietf-roll-of0 April 2011 >=20 >=20 > 2. Terminology >=20 > The terminology used in this document is consistent with and > incorporates that described in `Terminology in Low power And Lossy > Networks' [I-D.ietf-roll-terminology] and [I-D.ietf-roll-rpl]. >=20 > The term feasible successor is used to refer to a neighbor that can > possibly be used as a next-hop for upwards traffic following the loop > avoidance and forwarding rules that the nodes implements and that are > defined outside of this specification, in particular in the RPL > specification. >=20 > PC> Remove "that the nodes implements and that are defined outside of > this specification, in particular" >=20 >=20 > 3. Objective Function 0 Overview >=20 > The core RPL specification describes constraints on how nodes select > potential parents, called a parent set, from their neighbors. All > parents are feasible successors for upgoing traffic (towards the > root). Additionally, RPL allows the use of parents in a subsequent > Version of a same DODAG as feasible successors, in which case this >=20 > PC> again, capitalize Version? >=20 > node acts as a leaf in the subsequent DODAG Version. Further > specifications might extend the set of feasible successors, for > instance to nodes of a same Rank, aka siblings. >=20 > The Goal of the OF0 is for a node to join a DODAG Version that offers > connectivity to a specific set of nodes or to a larger routing > infrastructure. For the purpose of OF0, Grounded thus means that the > root provides such connectivity. How that connectivity is asserted > and maintained is out of scope. >=20 > Objective Function 0 is designed to find the nearest Grounded root. > This can be achieved if the Rank of a node represents closely its > distance to the root. This need is balanced with the other need of > maintaining some path diversity. >=20 > In the absence of a Grounded root, LLN inner connectivity is still > desirable and floating DAGs will form, rooted at the nodes with the > highest administrative preference. >=20 > PC> the above two paragraphs can be combined. >=20 > OF0 selects a preferred parent and a backup feasible successor if one > is available. All the upward traffic is normally routed via the > preferred parent. When the link conditions do not let an upward > packet through the preferred parent, the packet is passed to the > backup feasible successor. >=20 > PC> Replace "When the link conditions do not let an upward > PC> packet through the preferred parent" > PC> with > PC> "When a node is unable to send a packet trough the preferred parent". >=20 > OF0 assigns a Step-of-Rank to each link to another node that it >=20 > PC> remove "to another node" >=20 > monitors. The exact method for computing the Step-of-Rank is > implementation-dependent. >=20 >=20 >=20 > Thubert Expires October 7, 2011 [Page 4] >=20 > Internet-Draft draft-ietf-roll-of0 April 2011 >=20 >=20 > One trivial OF0 implementation might compute the Step-of-Rank from as >=20 > PC> remove "as" >=20 > a classical administrative cost that is assigned to the link. Using > a metric similar to hop count implies that the OF0 implementation >=20 > PC> "classical administrative cost" refers to "hop count" here? It's > not clear from the writing. >=20 > only considers neighbors with good enough connectivity, for instance > neighbors that are reachable over an Ethernet link, or a WIFI link in >=20 > PC> s/WIFI/WiFi/ >=20 > infrastructure mode. >=20 > In most wireless networks, a Rank that is analogous to an unweighted > hop count favors paths with long distance links and poor connectivity > properties. Other link properties such as the expected transmission > count metric (ETX) [DeCouto03] should be used instead to compute the > Step-of-Rank. For instance, the Minimum Rank Objective Function with > Hysteresis [I-D.ietf-roll-minrank-hysteresis-of] provides guidance on > how link cost can be computed and on how hysteresis can improve Rank > stability. >=20 > An implementation MAY allow to stretch the Step-of-Rank with a > Stretch-of-Rank up to no more than MAXIMUM_RANK_STRETCH in order > to > enable the selection of a feasible successor in order to maintain > some path diversity. The use of a Stretch-of-Rank augments the > apparent distance from the node to the root and distorts the DODAG; > it should be used with care so as to avoid instabilities due to > greedy behaviours. >=20 > The Step-of-Rank is expressed in units of MINIMUM_STEP_OF_RANK. As > a > result, the least significant octet in the RPL Rank is not used. The > default Step-of-Rank is DEFAULT_STEP_OF_RANK for each hop. An > implementation MUST maintain the stretched Step-of-Rank between > MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK, which > allows to > reflect a large variation of link quality. >=20 > PC> Remove ", which allows to reflect a large variation of link > PC> quality." If you wish to point out that stretch of rank may be > PC> computed from link quality, this should be mentioned earlier where > PC> you point out that the exact method for computing it is > PC> implementation-dependent. >=20 > The gap between MINIMUM_STEP_OF_RANK and > MAXIMUM_RANK_STRETCH may not > be sufficient in every case to strongly distinguish links of > different types or categories in order to favor, say, powered over > battery-operated or wired over wireless, within a same DAG. An >=20 > PC> s/a same DAG/the same DAG/ >=20 > implementation SHOULD allow a configurable factor called Rank-factor > and to apply the factor on all links and peers. >=20 > An implementation MAY recognizes sub-categories of peers and links, > such as different MAC types, in which case it SHOULD be able to > configure a more specific Rank-factor to those categories. The Rank- > factor SHOULD be set between MINIMUM_RANK_FACTOR and > MAXIMUM_RANK_FACTOR. The Step-of-Rank Sp that is computed for > that >=20 > PC> I though "Sp" was a typo. s/Sp that is computed/, Sp, computed/ >=20 > link s multiplied by the Rank-factor Rf and then possibly stretched >=20 > PC> s/Rf/,Rf,/; s/link s/link is/ >=20 > by a Stretch-of-Rank Sr. The resulting Rank-increase Ri is added to >=20 > PC> s/ Sr/, Sr/; s/ Ri/, Ri,/; And so forth below, you get the idea. >=20 > the Rank of preferred parent R(P) to obtain that of this node R(N): >=20 > PC> s/obtain that of this node/obtain the rank of the current node/ >=20 > R(N) =3D R(P) + Ri where Ri =3D Rf*Sp + Sr. >=20 > PC> Insert comma and space for readability, > PC> R(N) =3D R(P) + Ri, where Ri =3D Rf*Sp + Sr. >=20 >=20 >=20 > Thubert Expires October 7, 2011 [Page 5] >=20 > Internet-Draft draft-ietf-roll-of0 April 2011 >=20 >=20 > Optionally, the administrative preference of a root MAY be configured > to supersede the goal to join a Grounded DODAG. In that case, nodes > will associate to the root with the highest preference available, > regardless of whether that root is Grounded or not. Compared to a > deployment with a multitude of Grounded roots that would result in a > same multitude of DODAGs, such a configuration may result in possibly >=20 > PC> remove "same" >=20 > less but larger DODAGs, as many as roots configured with the highest > priority in the reachable vicinity. >=20 > PC> I don't understand "as many as roots configured with the highest > PC> priority in the reachable vicinity." Is that necessary? >=20 > 4. Selection of the Preferred Parent >=20 > As it scans all the candidate neighbors, OF0 keeps the parent that is > the best for the following criteria (in order): >=20 > 1. [I-D.ietf-roll-rpl] spells out the generic rules for a node to > reparent and in particular the boundaries to augment its Rank > within a DODAG Version. A candidate that would not satisfy > those rules MUST NOT be considered. >=20 > 2. An implementation should validate a router prior to selecting it > as preferred. This validation process is implementation and > link type dependent, and is out of scope. A router that has > been validated is preferable. >=20 > 3. When multiple interfaces are available, a policy might be > locally configured to prioritize them and that policy applies > first; that is a router on a higher order interface is > preferable. >=20 > 4. If the administrative preference of the root is configured to > supersede the goal to join a Grounded DODAG, a router that > offers connectivity to a more preferable root SHOULD be > preferred. >=20 > 5. A router that offers connectivity to a grounded DODAG Version > SHOULD be preferred over one that does not. >=20 > 6. A router that offers connectivity to a more preferable root > SHOULD be preferred. >=20 > 7. When comparing 2 routers that belong to the same DODAG, a router > that offers connectivity to the freshest Version SHOULD be > preferred. >=20 > 8. The parent that causes the lesser resulting Rank for this node > SHOULD be preferred. >=20 >=20 >=20 >=20 > Thubert Expires October 7, 2011 [Page 6] >=20 > Internet-Draft draft-ietf-roll-of0 April 2011 >=20 >=20 > 9. A DODAG Version for which there is an alternate parent SHOULD be > preferred. This check is optional. It is performed by > computing the backup feasible successor while assuming that the > router that is currently examined is finally selected as > preferred parent. >=20 > 10. The preferred parent that was in use already SHOULD be > preferred. >=20 > 11. A router that has announced a DIO message more recently SHOULD > be preferred. >=20 >=20 > 5. Selection of the backup feasible successor >=20 > When selecting a backup feasible successor, the OF performs in order > the following checks: >=20 > 1. When multiple interfaces are available, a router on a higher > order interface is preferable. >=20 > 2. The backup feasible successor MUST NOT be the preferred parent. >=20 > 3. The backup feasible successor MUST be either in the same DODAG > Version as this node or in an subsequent Version. >=20 > 4. Along with RPL rules, a Router in the same DODAG Version as this > node and with a Rank that is higher than the Rank computed for > this node MUST NOT be selected as a feasible successor. >=20 > 5. A router with a lesser Rank SHOULD be preferred. >=20 > 6. A router that has been validated as usable by an implementation > dependant validation process SHOULD be preferred. >=20 > 7. The backup feasible successor that was in use already SHOULD be > preferred. >=20 >=20 > 6. Abstract Interface with RPL core >=20 > Objective Function 0 interacts with the core RPL in the following >=20 > PC> s/core RPL/RPL core/ >=20 > ways: >=20 > Processing DIO: This core RPL triggers the OF when a new DIO was >=20 > PC> s/This core RPL/The RPL core/ >=20 > received. OF0 analyses the information in the DIO and may > select the source as a parent or sibling. >=20 >=20 >=20 >=20 > Thubert Expires October 7, 2011 [Page 7] >=20 > Internet-Draft draft-ietf-roll-of0 April 2011 >=20 >=20 > Providing DAG information The OF0 support can be required to provide >=20 > PC> s/information/information:/ > PC> s/The OF0 support can be required to/OF0 SHOULD/ >=20 > the DAG information for a given instance to the RPL core. > This includes the material that is contained in a DIO base > header. >=20 > PC> what is "material" referring to here? all the information > PC> contained in a DIO base header? I suppose OF0 is tasked with > PC> keeping all that information, not the RPL core? >=20 > Providing a Parent List The OF0 support can be required to provide >=20 > PC> s/List/List:/ > PC> s/The OF0 support can be required to/OF0 SHOULD/ >=20 > the ordered list of the parents and feasible successors > for a given instance to the RPL core. This includes the > material that is contained in the transit option for each > entry. >=20 > PC> same comment, maybe replace "material" with "all the information" >=20 > Trigger The OF0 support may trigger the RPL core to inform it that >=20 > PC> s/Trigger/Trigger:/ > PC> s/The OF0 support may/OF0 SHOULD/ >=20 > a change occurred. This can be used to indicate whether > the change requires a new DIO to be fired or whether > trickle timers need to be reset. >=20 >=20 > 7. OF0 Constants and Variables >=20 > OF0 uses the following constants: >=20 > MinHopRankIncrease: 256 >=20 > DEFAULT_STEP_OF_RANK: 3 * MinHopRankIncrease >=20 > MINIMUM_STEP_OF_RANK: 1 * MinHopRankIncrease >=20 > MAXIMUM_STEP_OF_RANK: 9 * MinHopRankIncrease >=20 > MAXIMUM_RANK_STRETCH: 5 * MinHopRankIncrease >=20 > DEFAULT_RANK_FACTOR: 1 >=20 > MINIMUM_RANK_FACTOR: 1 >=20 > MAXIMUM_RANK_FACTOR: 4 >=20 >=20 > 8. IANA Considerations >=20 > This specification requires the assignment of an OCP for OF0. The > value of 0 is suggested. >=20 >=20 > 9. Security Considerations >=20 > Security Considerations for OCP/OF are to be developed in accordance > with recommendations laid out in, for example, >=20 >=20 >=20 > Thubert Expires October 7, 2011 [Page 8] >=20 > Internet-Draft draft-ietf-roll-of0 April 2011 >=20 >=20 > [I-D.tsao-roll-security-framework]. >=20 >=20 > 10. Acknowledgements >=20 > Most specific thanks to Philip Levis for his help in finalizing this > document, in particular WRT wireless links, to Tim Winter, JP >=20 > PC> s/WRT/with respect to/ >=20 > Vasseur, Julien Abeille, Mathilde Durvy, Teco Boot, Navneet Agarwal > and Henning Rogge for in-depth review and first hand implementer's > feedback. >=20 >=20 > 11. References >=20 > 11.1. Normative References >=20 > [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, March 1997. >=20 > 11.2. Informative References >=20 > [DeCouto03] > De Couto, Aguayo, Bicket, and Morris, "A High-Throughput > Path Metric for Multi-Hop Wireless Routing", MobiCom > '03 The 9th ACM International Conference on Mobile > Computing and Networking, San Diego, California,, 2003, ttp://pdos.csail.mit.edu/papers/grid:mobicom03/paper.pdf>. >=20 > [I-D.ietf-roll-minrank-hysteresis-of] > Gnawali, O. and P. Levis, "The Minimum Rank Objective > Function with Hysteresis", > draft-ietf-roll-minrank-hysteresis-of-01 (work in > progress), February 2011. >=20 > [I-D.ietf-roll-routing-metrics] > Vasseur, J., Kim, M., Pister, K., Dejean, N., and D. > Barthel, "Routing Metrics used for Path Calculation in Low > Power and Lossy Networks", > draft-ietf-roll-routing-metrics-19 (work in progress), > March 2011. >=20 > [I-D.ietf-roll-rpl] > Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J., > Kelsey, R., Levis, P., Pister, K., Struik, R., and J. > Vasseur, "RPL: IPv6 Routing Protocol for Low power and > Lossy Networks", draft-ietf-roll-rpl-19 (work in > progress), March 2011. >=20 >=20 >=20 >=20 > Thubert Expires October 7, 2011 [Page 9] >=20 > Internet-Draft draft-ietf-roll-of0 April 2011 >=20 >=20 > [I-D.ietf-roll-terminology] > Vasseur, J., "Terminology in Low power And Lossy > Networks", draft-ietf-roll-terminology-05 (work in > progress), March 2011. >=20 > [I-D.tsao-roll-security-framework] > Tsao, T., Alexander, R., Daza, V., and A. Lozano, "A > Security Framework for Routing over Low Power and Lossy > Networks", draft-tsao-roll-security-framework-02 (work in > progress), March 2010. >=20 > [RFC5548] Dohler, M., Watteyne, T., Winter, T., and D. Barthel, > "Routing Requirements for Urban Low-Power and Lossy > Networks", RFC 5548, May 2009. >=20 > [RFC5673] Pister, K., Thubert, P., Dwars, S., and T. Phinney, > "Industrial Routing Requirements in Low-Power and Lossy > Networks", RFC 5673, October 2009. >=20 > [RFC5826] Brandt, A., Buron, J., and G. Porcu, "Home Automation > Routing Requirements in Low-Power and Lossy Networks", > RFC 5826, April 2010. >=20 > [RFC5867] Martocci, J., De Mil, P., Riou, N., and W. Vermeylen, > "Building Automation Routing Requirements in Low-Power and > Lossy Networks", RFC 5867, June 2010. >=20 >=20 > Author's Address >=20 > Pascal Thubert (editor) > Cisco Systems > Village d'Entreprises Green Side > 400, Avenue de Roumanille > Batiment T3 > Biot - Sophia Antipolis 06410 > FRANCE >=20 > Phone: +33 497 23 26 34 > Email: pthubert@cisco.com >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > Thubert Expires October 7, 2011 [Page 10] >=20 From phoebus@ieee.org Thu Apr 21 07:56:25 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5BDF7E07A1 for ; Thu, 21 Apr 2011 07:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.949 X-Spam-Level: X-Spam-Status: No, score=-106.949 tagged_above=-999 required=5 tests=[AWL=0.700, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ut4ym3DQMG9u for ; Thu, 21 Apr 2011 07:56:23 -0700 (PDT) Received: from smtp-2.sys.kth.se (smtp-2.sys.kth.se [130.237.32.160]) by ietfc.amsl.com (Postfix) with ESMTP id 89258E07B2 for ; Thu, 21 Apr 2011 07:56:23 -0700 (PDT) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 7D37C14D7D6; Thu, 21 Apr 2011 16:55:52 +0200 (CEST) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-2.sys.kth.se ([130.237.32.160]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id KlIv3gbICyvT; Thu, 21 Apr 2011 16:55:50 +0200 (CEST) X-KTH-Auth: phoebus [2001:6b0:1:12b0:223:dfff:fe92:5e5c] X-KTH-mail-from: phoebus@ieee.org Received: from dhcp-50-7.s3.kth.se (unknown [IPv6:2001:6b0:1:12b0:223:dfff:fe92:5e5c]) by smtp-2.sys.kth.se (Postfix) with ESMTP id 4DEEE14C12E; Thu, 21 Apr 2011 16:55:48 +0200 (CEST) Message-ID: <4DB04573.7060302@ieee.org> Date: Thu, 21 Apr 2011 16:55:47 +0200 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <6A2A459175DABE4BB11DE2026AA50A5D04650322@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D04650322@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "roll@ietf.org" Subject: Re: [Roll] OF0 draft v9: preferred metric, Stretch-of-Rank, configuring parameters, and editorial comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Apr 2011 14:56:25 -0000 Pascal, Thanks for your responses. I've replied inline below, preceded by PC>. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus On 4/21/11 10:41 AM, Pascal Thubert (pthubert) wrote: > Hello Phoebus : ) > > Where have you been? We've been missing your excellent comments. > >> Sorry these comments are coming so late, after last call. I > hope you >> can at least incorporate some of them. > > [Pascal] That's beyond me. I suppose that the shepherd has to decide. > Let's see: > > >> >> My comments below are based on my current understanding that >> Phil and you are no longer using hop-count as the rank increment. > Instead, >> each node will have an implementation specific way of converting a > node or >> link cost to a rank. I'm still unclear if there is a preference rule > to try to stick >> with using the same metrics as the metrics advertised in a received > DIO, if >> the current node has access to multiple types of metrics (energy, LQI, > ETX, >> etc.). That would allow the root node to specify a preferred type of > metric to >> use in the instance. >> >> >> Major Points: >> ************* >> 1) I'm still hoping that the format for writing Objective Function > specifications >> can be more uniform, as I mentioned in an earlier comment (point > number 7 >> in http://www.ietf.org/mail-archive/web/roll/current/msg03240.html). >> Comparing MRHOF and OF0, I think that the discussion on Step-of-Rank / >> Stretch-of-Rank etc. can be moved to it's own subsection. >> >> I suggest the following reorganization of sections: >> >> 3. Objective Function 0 >> 3.1. Computing Rank-increase >> 3.2. Parent / Backup Successor Selection >> 3.2.1. Selection of the Preferred Parent >> 3.2.2. Selection of the backup feasible successor >> 3.3. Advertising Rank-increase >> 4. Interface with RPL core >> > [Pascal] Looks good. That much is doc organization and I suppose I can > accommodate it at this stage. > It would certainly be beneficial if both OF drafts have a common > structure. > >> If you are allowing the root to specified a preferred metric type, > then Section >> 3.3. should state how to propagate this preference. I would have > assumed >> it's by propagating an empty DAG/Metric Container, but in (Section > 2.1, draft- >> ietf-roll-routing-metrics-19) it says "The object body carries one or > more sub- >> objects defined later in this document" >> which means you cannot have empty containers. > > [Pascal] OF0 does not have metric containers at all, so they do not need > to be empty. That's because OF0 is generic, for the better or the worse. > Because we want all implementations to interop with OF0, regardless of > the medium etc... > > So the idea is to have no constraint on what the implementation uses to > derive the Rank, no container, no configuration option, just the base > RPL spec. > > Rather, we normalize the resulting values so they can compare between > implementations. PC> OK. I thought allowing the root to specify a preferred metric would PC> be nice, but I see that it's not necessary for basic operations. > > Now, I understand that a configuration container could help make the OF > more self-contained/autonomic. > >> Maybe the overview in Section 3 should also state explicitly that the >> processing rules of a DIO must do 3.1, then 3.2, then 3.3, in that > order. > > [Pascal] Yes, and this is what we mean by > " As it scans all the candidate neighbors, OF0 keeps the parent that > is > the best for the following criteria (in order):" > the language may not be perfect but I hardly think the reader can be > getting the text wrong. > I'm open to an editorial change if the sense is conserved. > PC> I think the text you quoted above is very clear, but given its PC> location in the text (Section 4 of draft-ietf-roll-of0-10, or PC> Section 3.2.1 of the suggested new order), it applies to PC> parent selection. I'm saying there should be a sentence in the new PC> Section 3 (overview) saying that we first compute PC> Rank-Increase (Sec. 3.1), then select the preferred parent PC> (Sec. 3.2.1), then select the backup successor (Sec. 3.2.2), then PC> advertise Rank-Increase (Sec. 3.3). PC> PC> Maybe this is obvious, but I think it helps to state it explicitly. PC> Especially since the guidelines given in PC> (Section 14.1, draft-ietf-roll-rpl-19) are suggestions, PC> rather than MUSTs: PC> "Most Objective Functions are expected to follow..." PC> And these suggestions don't say the steps must be followed in PC> order either. >> >> >> 2) There have been two variables and one parameter defined in the >> overview section, but they are not mentioned in Section 7, OF0 > Constants >> and Variables. >> Variables: Step-of-Rank, Stretch-of-Rank >> Parameters: Rank-factor >> (I noticed that there is no MINIMUM_RANK_STRETCH and >> DEFAULT_RANK_STRETCH and presume this is intentional.) >> > [Pascal] You're right. A stretch of 0 is acceptable so there is no > MINIMUM. > If there was a DEFAULT I expect it should be zero as well. By > compliance with the main spec. > I'm fine adding it. What do you think? > PC> That would be nice for clarity. I think most implementors will PC> use default values in a spec without a second thought unless they PC> have a strong reason to do otherwise. >> Also, it would be nice to use underscore instead of hyphen for >> variables, like in MRHOF (and use capital letters for parameters). >> > [Pascal] OK. I did not really mean those as variables, but why not. > >> Finally, how is Stretch-of-Rank computed? Implementation dependent? > > [Pascal] It is not computed. It is configured and can be left to 0. Does > not have to be there at all in an implementation. > I can clarify that. > PC> OK. >> 3) How does one configure the parameter(s) (Rank-Factor) from the > root? >> (I just realized that this same comment applies to the parameters in >> MRHOF as well). Or is that not configurable from the root, but must > be >> configured before deployment of the nodes? > > [Pascal] The Rank factor has to be a per node policy, like the > Stretch-of-Rank. Right now, we do not have config containers to > distribute it. > > >> >> 4) I think it would be nice to adopt the format of >> draft-ietf-roll-rpl-19 and draft-ietf-roll-minrank-hysteresis-of for > the >> Terminology section. That is, write the word, then the definition > (this >> is not done for "feasible successor" in this section). Some other > words >> to define in this section are "Rank-increase," "RPL core," and "higher >> order interface." Unless the last one is common IPv6 terminology that > I >> am unaware of... I was unable to tell if that meant the higher order >> bits of the interface are higher, or if the interface is somehow > preferred. > > I think that the RPL terminology is the place for having those in > common. PC> Do you mean you or JP will add those terms and definitions to PC> (draft-ietf-roll-terminology-05) or PC> (Section 2, draft-ietf-roll-rpl-19)? I think the definition of PC> "Rank-increase" belongs in OF0. > >> >> 5) Just a reminder that the discussion on Rank-increase in the >> introduction section >> "OF0 uses a unit of Rank-increase of 0x100 so that Rank value can be >> stored in one octet." >> needs to be aligned with text in Section 3, >> "Ri = Rf*Sp + Sr" >> so that they are consistent. I see you are discussing this with > Omprakash. > > Sp and Sr are expressed as units of 0x100 and Rf is integer, so they are > consistent. Do I miss something? > PC> I see. I didn't realize that step_of_rank had to be a multiple of PC> 0x100. You only mention at the bottom of page 3 that "The exact PC> method for computing the Step-of-Rank is implementation-dependent" PC> and give bounds MINIMUM_STEP_OF_RANK and MAXIMUM_STEP_OF_RANK PC> that are multiples of MinHopRankIncrease. PC> PC> On a related note, there's a recent discussion of using the ETX PC> directly (identity) as the rank, which doesn't match this PC> requirement that step_of_rank be a multiple of 0x100 in OF0. In PC> (Section 4.3.1, draft-ietf-roll-routing-metrics-19) ETX is a PC> multiple of 128, not 256 (0x100). PC> PC> Is it actually necessary to mention "rank-increase" in the PC> introduction, before the terminology section? Can we remove "The Rank of a node is obtained by adding a normalized scalar Rank-increase to the Rank of a selected preferred parent. OF0 uses a unit of Rank- increase of 0x100 so that Rank value can be stored in one octet. This allows up to at least 28 hops even when default settings are used and each hop has the worst Rank-increase of 9." PC> Or move it some point later? It may be a bit confusing to bring up PC> so much detail at this point in the text. >> >> 6) I like the "Abstract Interface with RPL core" section, but would it >> be better to separate them into "Input" and "Output"? That would end > up >> splitting up "Providing DAG information" and "Providing a Parent List" >> into two pieces though. >> >> >> More minor editorial comments to follow below, preceded by PC>. > > Thanks for those. I'll include them in a rev. > >> >> -- >> Phoebus Chen >> Postdoctoral Researcher >> Automatic Control Lab, KTH (Royal Institute of Technology) >> http://www.ee.kth.se/~phoebus >> >> From prvs=0888b650b=Tzeta.Tsao@cooperindustries.com Sun Apr 24 15:41:08 2011 Return-Path: X-Original-To: roll@ietfc.amsl.com Delivered-To: roll@ietfc.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 6A8A4E070C for ; Sun, 24 Apr 2011 15:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.669 X-Spam-Level: X-Spam-Status: No, score=-5.669 tagged_above=-999 required=5 tests=[AWL=-0.930, BAYES_20=-0.74, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzRWYFe1d5ks for ; Sun, 24 Apr 2011 15:41:07 -0700 (PDT) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by ietfc.amsl.com (Postfix) with ESMTP id DD7FAE0679 for ; Sun, 24 Apr 2011 15:41:07 -0700 (PDT) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.64,264,1301889600"; d="scan'208,217";a="6881155" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 24 Apr 2011 18:41:06 -0400 Received: from EVS4.NAM.CI.ROOT ([10.132.108.172]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Sun, 24 Apr 2011 18:41:06 -0400 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_01CC02D0.B2917031" Date: Sun, 24 Apr 2011 18:41:05 -0400 Message-ID: <9BB070DB2D281946859EA89837931EEEBEEAAD@EVS4.nam.ci.root> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version I-D draft-ietf-roll-security-framework-05 Thread-Index: AcwC0LJsAKaoFGczRkS/jHO6LlB6Ng== From: "Tsao, Tzeta" To: X-OriginalArrivalTime: 24 Apr 2011 22:41:06.0760 (UTC) FILETIME=[B3112480:01CC02D0] Subject: [Roll] New Version I-D draft-ietf-roll-security-framework-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Apr 2011 22:41:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CC02D0.B2917031 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG, =20 We have uploaded a revision of the draft to address the comments we received during the IESG review; it is available from the repository now. =20 Regards, Tzeta ------_=_NextPart_001_01CC02D0.B2917031 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

WG,

 

We have = uploaded a revision of the draft to address the comments we received = during the IESG review; it is available from the repository = now.

 

Regards,

Tzeta

------_=_NextPart_001_01CC02D0.B2917031-- From Internet-Drafts@ietf.org Wed Apr 27 14:00:04 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE89DE062B; Wed, 27 Apr 2011 14:00:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.528 X-Spam-Level: X-Spam-Status: No, score=-102.528 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leVSFKvTkpdc; Wed, 27 Apr 2011 14:00:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E63D1E070B; Wed, 27 Apr 2011 14:00:03 -0700 (PDT) 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.52 Message-ID: <20110427210003.5554.67427.idtracker@ietfa.amsl.com> Date: Wed, 27 Apr 2011 14:00:03 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-minrank-hysteresis-of-02.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 21:00:04 -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-02.txt Pages : 10 Date : 2011-04-27 The Routing Protocol for Low Power and Lossy Networks (RPL) uses objective functions to construct routes that optimize or constrain the routes it selects and uses. This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with metrics that are additive along a route, and the metric it uses is determined by the metrics RPL Destination Information Object (DIO) messages advertise. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-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-minrank-hysteresis-of-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-04-27135943.I-D@ietf.org> --NextPart-- From gnawali@cs.stanford.edu Wed Apr 27 14:01:58 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 851D2E07DE for ; Wed, 27 Apr 2011 14:01:58 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6HRwl+I-Y81S for ; Wed, 27 Apr 2011 14:01:58 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 919BDE074D for ; Wed, 27 Apr 2011 14:01:57 -0700 (PDT) Received: from mail-pw0-f44.google.com ([209.85.160.44]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1QFBrw-0007M1-Dk for roll@ietf.org; Wed, 27 Apr 2011 14:01:56 -0700 Received: by pwi5 with SMTP id 5so1124689pwi.31 for ; Wed, 27 Apr 2011 14:01:56 -0700 (PDT) Received: by 10.68.35.65 with SMTP id f1mr503700pbj.292.1303938116068; Wed, 27 Apr 2011 14:01:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Wed, 27 Apr 2011 14:01:36 -0700 (PDT) In-Reply-To: <20110427205943.E3E32E0735@ietfa.amsl.com> References: <20110427205943.E3E32E0735@ietfa.amsl.com> From: Omprakash Gnawali Date: Wed, 27 Apr 2011 14:01:36 -0700 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: d3e02c565cd5ac634b2ff74b6ba3e13d Subject: [Roll] Fwd: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 21:01:58 -0000 I posted an updated draft based on your comments. Feedback welcome. The major changes are - parent set working without metric containers rpl parameter subsection - om_p ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Wed, Apr 27, 2011 at 1:59 PM Subject: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-02 To: gnawali@cs.stanford.edu Cc: pal@cs.stanford.edu A new version of I-D, draft-ietf-roll-minrank-hysteresis-of-02.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 =A002 Title: =A0 =A0 =A0 =A0 =A0 The Minimum Rank Objective Function with Hystere= sis Creation_date: =A0 2011-04-27 WG ID: =A0 =A0 =A0 =A0 =A0 roll Number_of_pages: 10 Abstract: The Routing Protocol for Low Power and Lossy Networks (RPL) uses objective functions to construct routes that optimize or constrain the routes it selects and uses. =A0This specification describes the Minimum Rank Objective Function with Hysteresis (MRHOF), an objective function that selects routes that minimize a metric, while using hysteresis to reduce churn in response to small metric changes. MRHOF works with metrics that are additive along a route, and the metric it uses is determined by the metrics RPL Destination Information Object (DIO) messages advertise. The IETF Secretariat. From gnawali@cs.stanford.edu Wed Apr 27 15:39:11 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B24AE078D for ; Wed, 27 Apr 2011 15:39:11 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3cimLfL0ZEi for ; Wed, 27 Apr 2011 15:39:11 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id F2C7EE0787 for ; Wed, 27 Apr 2011 15:39:10 -0700 (PDT) Received: from mail-pz0-f44.google.com ([209.85.210.44]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1QFDO2-0005DC-KU for roll@ietf.org; Wed, 27 Apr 2011 15:39:10 -0700 Received: by pzk5 with SMTP id 5so1595033pzk.31 for ; Wed, 27 Apr 2011 15:39:10 -0700 (PDT) Received: by 10.68.58.233 with SMTP id u9mr2649704pbq.426.1303943950106; Wed, 27 Apr 2011 15:39:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.68.51.167 with HTTP; Wed, 27 Apr 2011 15:38:50 -0700 (PDT) From: Omprakash Gnawali Date: Wed, 27 Apr 2011 15:38:50 -0700 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 078eb853d78558c6c655f7b6c94b391a Subject: [Roll] mrhof last call comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2011 22:39:11 -0000 Here is how I addressed these comments that were provided during the last call. 1. The draft seems specific to link metrics, does not talk about node metrics. => The draft now mentions node metrics in the right places and describes how to use it to compute the path cost. 2. Why constrain MRHOF to metric minimization? With minimal change, it can be used to find paths with metric maximization. => There is a new subsection that describes how MRHOF can also be used with metric maximization. But it notes that MRHOF is not required to support this feature. 3. MinHopRankIncrease should be set to 1. => There is a new subsection that mentions this explicitly. 4. Single parent or a set of parents? => MRHOF now supports a set of parents. The draft describes how one selects this set. 5. How to compute rank when there are multiple parents? => Compute rank corresponding to the worst parent in the parent set. 6. What metric is required for MRHOF? => ETX 7. How to handle no metric container case? => Requires ETX metric. Advertise ETX path cost as Rank. Interpret Rank as ETX path cost. - om_p From joakime@sics.se Thu Apr 28 00:31:43 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34473E06C0 for ; Thu, 28 Apr 2011 00:31:43 -0700 (PDT) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CQr4DHDiftiu for ; Thu, 28 Apr 2011 00:31:42 -0700 (PDT) Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2F483E06A6 for ; Thu, 28 Apr 2011 00:31:42 -0700 (PDT) Received: from [193.10.67.77] (harr.sics.se [193.10.67.77]) by letter.sics.se (Postfix) with ESMTPS id 9559940075; Thu, 28 Apr 2011 09:31:40 +0200 (CEST) Message-ID: <4DB917D9.5060704@sics.se> Date: Thu, 28 Apr 2011 09:31:37 +0200 From: Joakim Eriksson User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; sv-SE; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 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] mrhof last call comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 07:31:43 -0000 Hello Om, I think that the MinHopRankIncrease should not be forced to 1 to avoid the DAG_RANK() in RPL. This feels like a "workaround" that might not be needed. From my perspective DAG_RANK() is only used within the RPL protocol to filter out neigbors that should not be considered parent (to avoid potential loops, etc). Then when the OF does it's comparison between parents there is not need to use the DAG_RANK function to truncate to the integer part of the rank. Thus forcing it to 1 will remove some of the features that has been designed into RPL and limit how MRHOF can be implemented. We have been running MRHOF without metric container on ETX and have used 256 as MinHipRankIncreas to have a good resolution on the fixpoint value of ETX and I have not seen any specific problems related to this. So I vote on removing the constraint on MinHopRankIncrease. Best regards, -- Joakim Eriksson, SICS Omprakash Gnawali skrev 2011-04-28 00:38: > Here is how I addressed these comments that were provided during the last call. > > 1. The draft seems specific to link metrics, does not talk about node metrics. > > => The draft now mentions node metrics in the right places and > describes how to use it to compute the path cost. > > 2. Why constrain MRHOF to metric minimization? With minimal change, it > can be used to find paths with metric maximization. > > => There is a new subsection that describes how MRHOF can also be used > with metric maximization. But it notes that MRHOF is not required to > support this feature. > > 3. MinHopRankIncrease should be set to 1. > > => There is a new subsection that mentions this explicitly. > > 4. Single parent or a set of parents? > > => MRHOF now supports a set of parents. The draft describes how one > selects this set. > > 5. How to compute rank when there are multiple parents? > > => Compute rank corresponding to the worst parent in the parent set. > > 6. What metric is required for MRHOF? > > => ETX > > 7. How to handle no metric container case? > > => Requires ETX metric. Advertise ETX path cost as Rank. Interpret > Rank as ETX path cost. > > > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From matteo.paris@ember.com Thu Apr 28 06:57:15 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E054E0708 for ; Thu, 28 Apr 2011 06:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvhxuANzCBTh for ; Thu, 28 Apr 2011 06:57:14 -0700 (PDT) Received: from p01c12o141.mxlogic.net (p01c12o141.mxlogic.net [208.65.145.64]) by ietfa.amsl.com (Postfix) with ESMTP id 2E7C9E0669 for ; Thu, 28 Apr 2011 06:57:14 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO EMPIRE.hq.ember.com) by p01c12o141.mxlogic.net(mxl_mta-6.9.0-2) with ESMTP id 93279bd4.0.1838.00-387.4446.p01c12o141.mxlogic.net (envelope-from ); Thu, 28 Apr 2011 07:57:14 -0600 (MDT) X-MXL-Hash: 4db9723a47559a3e-9fef8cc3aec28e2588d2853d1e45c51068fbaa5b Received: from [192.168.100.118] ([192.168.81.82]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 28 Apr 2011 09:56:02 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <4DB917D9.5060704@sics.se> References: <4DB917D9.5060704@sics.se> Date: Thu, 28 Apr 2011 09:56:01 -0400 To: Joakim Eriksson , roll@ietf.org From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 28 Apr 2011 13:56:02.0587 (UTC) FILETIME=[02C4D6B0:01CC05AC] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=1.0 c=1 a=gjzT480QRjsA:10 a=saA6nF2ZJaAA:10 a=BLceEmwcHo] X-AnalysisOut: [wA:10 a=kj9zAlcOel0A:10 a=MYqPJgym4Kx47q1P90kooQ==:17 a=48] X-AnalysisOut: [vgC7mUAAAA:8 a=5yLeli91kWSM71e2socA:9 a=nSbaVQOljyoajGpHoq] X-AnalysisOut: [MA:7 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10] Subject: Re: [Roll] mrhof last call comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 13:57:15 -0000 I second Joakim's email. We are also using 256 for MinHopRankIncrease for good ETX granularity. Do you intend MRHOF to use only integral ETX values? Matteo At 9:31 AM +0200 4/28/11, Joakim Eriksson wrote: >Hello Om, > >I think that the MinHopRankIncrease should not be forced to 1 to avoid >the DAG_RANK() in RPL. This feels like a "workaround" that might not be >needed. > >From my perspective DAG_RANK() is only used within the RPL protocol to >filter out neigbors that should not be considered parent (to avoid >potential loops, etc). Then when the OF does it's comparison between >parents there is not need to use the DAG_RANK function to truncate >to the integer part of the rank. Thus forcing it to 1 will remove some >of the features that has been designed into RPL and limit how MRHOF >can be implemented. > >We have been running MRHOF without metric container on ETX and have >used 256 as MinHipRankIncreas to have a good resolution on the fixpoint >value of ETX and I have not seen any specific problems related to >this. So I vote on removing the constraint on MinHopRankIncrease. > > >Best regards, >-- Joakim Eriksson, SICS > > > >Omprakash Gnawali skrev 2011-04-28 00:38: >>Here is how I addressed these comments that were provided during >>the last call. >> >>1. The draft seems specific to link metrics, does not talk about >>node metrics. >> >>=> The draft now mentions node metrics in the right places and >>describes how to use it to compute the path cost. >> >>2. Why constrain MRHOF to metric minimization? With minimal change, it >>can be used to find paths with metric maximization. >> >>=> There is a new subsection that describes how MRHOF can also be used >>with metric maximization. But it notes that MRHOF is not required to >>support this feature. >> >>3. MinHopRankIncrease should be set to 1. >> >>=> There is a new subsection that mentions this explicitly. > > >>4. Single parent or a set of parents? >> >>=> MRHOF now supports a set of parents. The draft describes how one >>selects this set. >> >>5. How to compute rank when there are multiple parents? >> >>=> Compute rank corresponding to the worst parent in the parent set. >> >>6. What metric is required for MRHOF? >> >>=> ETX >> >>7. How to handle no metric container case? >> >>=> Requires ETX metric. Advertise ETX path cost as Rank. Interpret >>Rank as ETX path cost. >> >> >>- om_p >>_______________________________________________ >>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 pal@cs.stanford.edu Thu Apr 28 07:42:01 2011 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06BBE06BA for ; Thu, 28 Apr 2011 07:42:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GCg7XBzofmpw for ; Thu, 28 Apr 2011 07:42:01 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 313E9E0669 for ; Thu, 28 Apr 2011 07:42:01 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.104]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1QFSPo-0001SQ-FG; Thu, 28 Apr 2011 07:42:00 -0700 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Thu, 28 Apr 2011 07:42:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4DB917D9.5060704@sics.se> To: Matteo Paris X-Mailer: Apple Mail (2.1084) X-Scan-Signature: 5fb79390a4aad79c01ba7e4883e5f1df Cc: roll@ietf.org Subject: Re: [Roll] mrhof last call comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Apr 2011 14:42:01 -0000 On Apr 28, 2011, at 6:56 AM, Matteo Paris wrote: >=20 > I second Joakim's email. We are also using 256 for MinHopRankIncrease = for good ETX granularity. Do you intend MRHOF to use only integral ETX = values? Good catch -- MRHOF should support fractional ETX values. Phil