From rdroms.ietf@gmail.com Fri Jun 1 12:19:33 2012 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 23ED111E8116 for ; Fri, 1 Jun 2012 12:19:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d4F+z5LE8cla for ; Fri, 1 Jun 2012 12:19:32 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8BC0611E8117 for ; Fri, 1 Jun 2012 12:19:32 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1673014vbb.31 for ; Fri, 01 Jun 2012 12:19:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=sstJrnXLOvXy4UKrTL+u921mCYH3HTzSCkDgMhZ3q5Q=; b=f5TKMkpottb/sd+Z0mUjRPmOjCOZwrx5dXsMbO2f0EW1sTVp+wmmG3cQmDYf1Iv6RW Naf24aMtHy2Por2Dtd4TI44O4JnN7adJw7ILa2uZbhBnvOuB0ASKCSdTvU3u0nwPjxsf zdIweZAgOHxcXn9wLPSOjpjCJotDj8PIDfBMMmP/ZYgKC+51mucNFwignMQA9NSVpm/G JPfuog1r5tywBflUvamunoaVjcokz3vyc6DYE6dEb1Lq5wW0oclvvsAVnr15JskcoT2/ f2B4u3gA0mluIHP9viCiCPAtd9nSNhyjQxpcZxCGqyJ+DCQ6qKCPXkJ9cs001he7NHRm thBQ== Received: by 10.52.100.67 with SMTP id ew3mr3605302vdb.36.1338578371872; Fri, 01 Jun 2012 12:19:31 -0700 (PDT) Received: from che-vpn-cluster-1-318.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPS id d20sm4389487vde.20.2012.06.01.12.19.29 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jun 2012 12:19:29 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <17114.1337959052@marajade.sandelman.ca> Date: Fri, 1 Jun 2012 15:19:27 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5A571424-7E15-40D3-B6BD-A25E42DD13B5@gmail.com> References: <25665.1337180676@marajade.sandelman.ca> <4FB3C7CB.70709@innovationslab.net> <4FBA58CC.9040109@innovationslab.net> <19650.1337713406@marajade.sandelman.ca> <593C2D52-E780-4D75-B535-7F2B147642A0@gmail.com> <23542.1337782756@marajade.sandelman.ca> <32356.1337806435@marajade.sandelman.ca> <4FBE8CCB.2050504@innovationslab.net> <17114.1337959052@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1278) Cc: roll@ietf.org Subject: Re: [Roll] Brian Haberman Discuss on on draft-ietf-roll-minrank-hysteresis-of-10 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, 01 Jun 2012 19:19:33 -0000 On May 25, 2012, at 11:17 AM 5/25/12, Michael Richardson wrote: >=20 >>>>>> "Ralph" =3D=3D Ralph Droms writes: > Ralph> OK, do I understand the fundamental issue correctly: the > Ralph> assumption that there must be some form of installation > Ralph> process to adapt the device to the specific deployment? >=20 > WG: please disagree with this assumption of mine: >=20 >>>> Yes, that's my understanding of what current >>>> manufacturers/system integrators expect. Remember: there is >>>> layer-2 security stuff that also would need to be initialized >>>> before the smart object could even get on=20 >>>> the network to see any kind of announcement. The ZigBee IP spec expects that any ZIP node will be = configured/provisioned at manufacturing time and there will be no = installation process when a node is deployed. The spec mandates the use = of MRHOF with ETX as the selected metric with a specific set of = operational parameters. - Ralph > --=20 > Michael Richardson , Sandelman Software Works=20= > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From rdroms.ietf@gmail.com Fri Jun 1 12:28:37 2012 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 7AE8021F86B7 for ; Fri, 1 Jun 2012 12:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.359 X-Spam-Level: X-Spam-Status: No, score=-103.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jqs9dWPH240e for ; Fri, 1 Jun 2012 12:28:37 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DB19221F86B5 for ; Fri, 1 Jun 2012 12:28:36 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1678559vbb.31 for ; Fri, 01 Jun 2012 12:28:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=uCWT+6C/68eDK+Bg35RAAxYN984eXAaueRt3wArWE3E=; b=DQjFpCp/rAmeIgTI9v8h5ejNthufacEUxOay7n5zPDEpaCIdUM3Q6aRr2DTtikQUrA 789VLKTsFUqPx6gl2fwf62+mkeK5oFGSbdzLh3GneNHV53BeJcFMWVELbPSSb9lpm+P+ Gd4KKxS/YbshmKvKWQKga8dv7UcrcJ51K2DUKbrMsVMi/BqAfRDursIKWxC2W6bIfyhy UvfuJDCk5/MKGDfEPxboDsSWVGGXvS9VY9SMr7FEHaGW2ukMTdkHScOTc+IERaz+zMzS HkSPk97kKzSDvmhrfAazi/6YbCsQGFU3Tj24kN2Qv28UNyo6Xbb/y22uRtjS+G8N7Bjc pkfQ== Received: by 10.52.67.226 with SMTP id q2mr3595720vdt.53.1338578916313; Fri, 01 Jun 2012 12:28:36 -0700 (PDT) Received: from che-vpn-cluster-1-318.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPS id i19sm4426822vdt.18.2012.06.01.12.28.33 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jun 2012 12:28:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <19632.1337959850@marajade.sandelman.ca> Date: Fri, 1 Jun 2012 15:28:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <058.aaa3fc2efaae8e26a2ada588bce49a89@trac.tools.ietf.org> <19632.1337959850@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1278) Cc: roll@ietf.org, draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org Subject: Re: [Roll] [roll] #99: clarify for readers how/where provisioning of devices occurs 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, 01 Jun 2012 19:28:37 -0000 On May 25, 2012, at 11:30 AM 5/25/12, Michael Richardson wrote: >=20 >>>>>> "Omprakash" =3D=3D Omprakash Gnawali writes: > Omprakash> I was wondering if the first paragraph of 6.1 is enough = for things > Omprakash> that need to be configured/provisioned for MRHOF. >=20 > I think that it works for *MRHOF*, but I think that we have a bigger > picture problem here. Given that the ZigBee IP spec prescribes the details of how to use = MRHOF, a node that implements ZigBee IP and will not be used in any = other deployment scenario can be configured at manufacturing time and = there is no need for the node to "allow the [...] parameters to be = configured at installation time". However, I think = draft-ietf-roll-minrank-hysteresis-of would be improved by expanding the = sense of the text to something like: An implementation needs specific values for the following paramters: [...] These parameters may be set at device manufacturing time or configured at installation time. RPL/MRHOF do not provide a way for the appropriate values for these parameters to be discovered through the network.=20 - Ralph > --=20 > Michael Richardson , Sandelman Software Works=20= > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From rdroms.ietf@gmail.com Fri Jun 1 12:47:23 2012 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 E833111E80A0 for ; Fri, 1 Jun 2012 12:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.399 X-Spam-Level: X-Spam-Status: No, score=-103.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CV0tAcIzwfBz for ; Fri, 1 Jun 2012 12:47:22 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A60C011E809B for ; Fri, 1 Jun 2012 12:47:22 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1690081vbb.31 for ; Fri, 01 Jun 2012 12:47:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=y62dQS8QQR8ALX55VLiIN6VSGcY6m+VsTqc8OHdExLU=; b=PbT8RuCaEdjJ0phZbYoyyBV0cJry3U9uWPFTB/RkH0CJZil9PJyKDq7ziHCDVVqeAL xh67qN6f/kFkJ30KFpHNHMTXlJdOzFR3lMmG3ONzgGc9EjF+3RKQsrwrO/XDx+vaRwHa jM4NRKx+RMY+QDif5LsrX+OwFgePr61LfGwlbN8KR0OqK4gkQ1UqkdUPIOQhMCqpMDEy Dvkfpuo0pb/9P1dlCLhSr9g8GKQf5jqyeCuLgZzabjJilHZ09Iod9F+RM5wWCBC0pApM mtoGeQoetbc4VJOn7WDzwn+GXpi32qcvH8PzEQEpDyyNDkC7uBTfowY3nEptY+yHSKEh VswQ== Received: by 10.220.151.71 with SMTP id b7mr3813177vcw.62.1338580041223; Fri, 01 Jun 2012 12:47:21 -0700 (PDT) Received: from che-vpn-cluster-1-318.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPS id l12sm2606404vdh.8.2012.06.01.12.47.18 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jun 2012 12:47:19 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Fri, 1 Jun 2012 15:47:16 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5E46BEEE-3B9B-4E94-B54F-FE95CB8FE642@gmail.com> References: <12418.1337957631@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1278) Cc: roll@ietf.org, "Pascal Thubert \(pthubert\)" Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions 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, 01 Jun 2012 19:47:24 -0000 On May 25, 2012, at 12:31 PM 5/25/12, Pascal Thubert (pthubert) wrote: > Hi Michael: >=20 > I think RPL does not want to take party there. The OF is a piece of = logic to tie metrics and policies together.=20 > As such, there could be multiple metrics as long as there is good = logic to tie them in. for instance one would look at optimizing metric A = within contraints as expressed by metric B and the OF model will allow = that. >=20 > OTOH, it a flows requires a certain optimization (say per one metric) = and another requires something different, then certainly you want two = instances. >=20 > So ... it depends! >=20 > Pascal >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Michael Richardson > Sent: vendredi 25 mai 2012 16:54 > To: roll@ietf.org > Subject: [Roll] knowing which multiple metrics matter: MRHOF related = questions >=20 >=20 > Ralph asked some questions a few days ago. > His originally DISCUSS is at: > = http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of/ball= ot/ >=20 > This was my reply. I am particularly interested in replies from > Pascal, Anders and Mukul about my assertion about how we would never = pick RPL instances by metrics; that they would in fact be seperate RPL = Instance numbers and DODAG values, and that these things would = provisioned by the network installer. >=20 > =3D=3D=3D=3D >=20 > I'm going to reply to your comments in a different order than you = asked them, because I think question #3 is most important, and the rest = fall out of it. >=20 >>>>>> "Ralph" =3D=3D Ralph Droms writes: > Ralph> 3. Based on (1) and (2), would configuration and selection > Ralph> issues be ameliorated if the five candidate selected metrics > Ralph> were each asssigned a separate objective function? Use of a > Ralph> separate OF code point for each of the five possible = selected > Ralph> metrics would allow multiple RPL instances. >=20 > I think that it's important to understand that ROLL has a whole = palette of things that need to be provisioned by the "network operator". >=20 > In contrast to the situation of ISPs and customers, where the ISP is = the network operator, ROLL networks are more like highly orchestrated > Enterprises: "all your host belong to us" >=20 > so, when we write something like: > "The metric chosen by the network operator to use for path > selection." > in section 2, we really mean: > "The metric chosen by the network operator and provisioned into > the node when the firmware was flashed to use for path selection." OK, so I get that the model is that MRHOF is a toolbox, where the = specific tools are chosen when the device is flashed. In that case, I = think some additional review might be needed to ensure that the MRHOF = spec is internally consistent with that point of view. As one example, I think the "selected metric" should be called out = explicitly somewhere in section 5 and included in the list of configured = parameters in section 6.1. As another example, I read this text from section 3: Rank is undefined for these node/link metrics: node state and attributes, throughput, and link color. If the rank is undefined, the node must join one of the neighbors as a RPL Leaf node according to [RFC6550]. to mean that if the selected metric is one of the metrics for which rank = is undefined, the node joins as a lead node. But, how can that happen = if the selected metric is chosen by the network operator? > Ralph> 1. Why is one objective function defined for several potential=20= > Ralph> metrics? The details of MRHOF seem to preclude the = establishment=20 > Ralph> of several RPL instances in an LLN, each of which uses MRHOF = with=20 > Ralph> a different selected metric. >=20 > If one had many different RPL Instances, then we would have different > RPL Instance numbers in the RPL header. There can be many different > DODAG ("destinations") created within that instance. The instances = share a common set of (provisioned) parameters. How does a node know which RPL Instance number maps to which selected = metric? One way would be to specify that a node advertise ONLY the selected = metric for the RPL Instance in a DIO. > (To put it into DHCP terms: if we have multiple DHCP servers on a = link, then one would expect them to all offer IP addresses in the same = subnet. > If one wanted to have addresses in different subnets, and let the host = pick between them, then, one would need different layer-2s: different = VLANs or ESSIDs, or... ) >=20 > If you feel that RPL is rather schizo about provisioning vs = configuration, then I agree. It's not always clear to me why some = things are advertised while others are provisioned. >=20 > In BGPv4, we calculate metrics by adding AS entries in the path. > (It's always additive), and we add at least one AS entry to the path. > One can AS-stuff and add more, but proper operation of BGP does not = depend upon the exact algorithm used. >=20 > Finally, my impression is that how the various metrics are used = (singly, or in some combination) to calculate Rank Increase is a = question of further research, experimentation, and trade secret. Well, OK, but for the purposes of the MRHOF spec, it seems pretty clear = to me there is one selected metric that is used across all nodes as a = strictly additive path cost computation. > So long as the Rank increases, and a node does not flap between = parents, the exact details do not matter. Each node can do it's parent = selection based upon the available metrics on it's own. It advertises = the metrics it has. >=20 > I hope the authors will correct me if I'm completely off here. I read the spec to require a single selected metric across the entire = RPL Instance. - Ralph >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From rdroms.ietf@gmail.com Fri Jun 1 12:53:18 2012 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 C62FC21F87AB for ; Fri, 1 Jun 2012 12:53:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.428 X-Spam-Level: X-Spam-Status: No, score=-103.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hL8kSd9-AF2B for ; Fri, 1 Jun 2012 12:53:18 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1D82821F87A8 for ; Fri, 1 Jun 2012 12:53:18 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1693731vbb.31 for ; Fri, 01 Jun 2012 12:53:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=4qIjhY6y0PhEukQfijRr3nQwEn0vQXgB+siFHOmamT8=; b=NGS8ldljfgW7Ew0FpEe9xkndvZ3fbcYs8j3N4Z1sXyFC2Tzx+esshK57GqlP6ckN8J LX9s6B+837xYiDPqaPRiELLtP8VUy1HemRfAiSiVhrK8llQj47gyfmwEauUbE/R+1+zb VgYHemtoYegSYADce0+6K3I6GitEFKuzkA93cDaTC7puIdZXZOlxtlHCdMgOWc7spGwS B1YsOsi5b5B9A8CzIEbh27Yz19FGeKWaE9FwD1Zd2jvFoUTTU6cP1tvoMRt9TrCL8XtC cW9Ac/445k28i7uzuLB7RCNLvPN/sM2aGOMKE0ZB03DVuI8M2qHRxf3jiHq1pajOEJBg OaiA== Received: by 10.220.215.136 with SMTP id he8mr3880699vcb.13.1338580397618; Fri, 01 Jun 2012 12:53:17 -0700 (PDT) Received: from che-vpn-cluster-1-318.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPS id n2sm4544715vdj.3.2012.06.01.12.53.16 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jun 2012 12:53:16 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jun 2012 15:53:14 -0400 Message-Id: <943C0516-F78E-43FD-AECD-F66A8B930F21@gmail.com> To: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: roll@ietf.org Subject: [Roll] "Node energy" as a metric for MRHOF 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, 01 Jun 2012 19:53:19 -0000 I came across a new puzzle while re-reading = draft-ietf-roll-minrank-hysteresis-of. "Node energy" doesn't appear to be listed as an additive metric in RFC = 6551. Reading the description of the node energy metric, which carries = remaining battery capacity as a percentage of initial capacity, I have = no clue how a node using MRHOF would compute a path cost based on node = energy. Does node energy really fit as one of the metrics that MRHOF = can use? - Ralph From rdroms.ietf@gmail.com Fri Jun 1 13:15:26 2012 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 6603E11E80B4 for ; Fri, 1 Jun 2012 13:15:26 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huYl-Fu4w9re for ; Fri, 1 Jun 2012 13:15:26 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 129F411E8074 for ; Fri, 1 Jun 2012 13:15:25 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1710888vcq.31 for ; Fri, 01 Jun 2012 13:15:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=1WvyFMX8MSRHMHkk65VllDaJ8Nn5ZuzaCCiHRxXjm/g=; b=tLSXygqS338KUHUrSzW24jKyLZXf33zoFTwHubNdNfv4lGwMRO+EV3xlgiNasbT1cG V8QVL9URRzdObR3XcxWEWk3LRImCRFjMKh7q7LOnTwFNMYuouUryif9ewKDbN8jYXdAx s20ymGRiPyojhZAMvccF0jmv/4fMgR2gIH6KdDIjr297pKps0Ja5kLIs8nidT+pKYPTY Q2x3qsRzX4+WioBOn/dVCAUY8g31OIKd5tccdiEttwX/UV01wyTKOXTT7iHknyzkeDha QaRnEmA7htknEhBGmbhoz3AqH8zB1da6/uzWCJsM7fgU8Dw9uRGnoi0XVNH9Mj9jd22h CxLQ== Received: by 10.52.69.200 with SMTP id g8mr3553016vdu.113.1338581725518; Fri, 01 Jun 2012 13:15:25 -0700 (PDT) Received: from che-vpn-cluster-1-318.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPS id c17sm4618374vdj.11.2012.06.01.13.15.24 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 01 Jun 2012 13:15:24 -0700 (PDT) From: Ralph Droms Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Jun 2012 16:15:22 -0400 Message-Id: To: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) Cc: roll@ietf.org Subject: [Roll] "Link quality" as a metric for MRHIF 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, 01 Jun 2012 20:15:26 -0000 How is the "link quality" metric used as a selected metric in MRHOF? As = I read RFC 6551, the link quality container carries a list of individual = link qualities. To use the link quality metric in MRHOF, does the = computing node add up all the link qualities from the container option = to compute the parent path cost? What about link quality sub-objects = with link quality value "0"? - Ralph From dat@exegin.com Fri Jun 1 19:21:31 2012 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 147BD11E80BB for ; Fri, 1 Jun 2012 19:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JQDTdXXd6iK for ; Fri, 1 Jun 2012 19:21:27 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 95F8F11E808C for ; Fri, 1 Jun 2012 19:21:27 -0700 (PDT) Received: by dacx6 with SMTP id x6so3484742dac.31 for ; Fri, 01 Jun 2012 19:21:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=voeHVM6sbcUvNIFZY8WKhYVjxdzlA2JHHkih/tLCLtU=; b=omCPqQKEYY9lMmIuzeO8Y3KqvcfhAyY04Fp6GJBv/70I1hgNOBEJhrBF5VD47cs3hk QZsqpDkhIPg2WVPAA+CHByqwNq1zrh8UOoejQTSywPVMS41HZwVQlgRyx+Mc3GRMs9pt K7nTPUmhOQV0rTGZfBic4YCjLo5YaR3+NWJ5e/gFbyQqa3fp5gmeqw++/gdDeZV5Z/To I1Hmzk8W13TBfAG2Dq8RlsIUJW4XxPrUGMVyOg7WcIpjfZ4C3cpKHntEaF7sPOHMMemn OXy7CY/4lO8+ZUXkEZtb+L6yiq1GzTpF5X1qstYMQg73H1IhSiqYYhnANKSsTV/7dvC4 PQnQ== Received: by 10.68.233.102 with SMTP id tv6mr15595151pbc.153.1338603687158; Fri, 01 Jun 2012 19:21:27 -0700 (PDT) Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id mt9sm4681593pbb.14.2012.06.01.19.21.25 (version=SSLv3 cipher=OTHER); Fri, 01 Jun 2012 19:21:26 -0700 (PDT) Message-ID: <4FC978A2.30202@exegin.com> Date: Fri, 01 Jun 2012 19:21:22 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: Tecuceanu Andreea-Dana-B10623 References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------010903090100090201060201" X-Gm-Message-State: ALoCoQlc6eQmB9fQCMKg2nEmO+loYjLJaYLB/qZxlw/hNWoaqJOwquHz6rJa6Q7C7chT1dMQL4n6 Cc: "roll@ietf.org" Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554 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, 02 Jun 2012 02:21:31 -0000 This is a multi-part message in MIME format. --------------010903090100090201060201 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Yes, I noticed this as well. It is unfortunate because as you say, there is now no way to identify which instance a Error in SRH is for, and subsequently the root node can't just remove that routing entry in a specific instance. Instead it must either remove that entry from all instances or do nothing and wait for the next DAO to update the entry. Dario On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote: > > Hello, > > I have observed that the RPLInstanceID field from Source Routing > header (present in draft-ietf-6man-rpl-routing-header-07) was removed > in RFC6554. > > Are there particular reasons for this? This field is necessary at the > DODAG Root when it receives a Destination Unreachable with code "Error > in Source Routing Header" to identify the instance with the problem > (only if there are two instances with the same prefix and if the node > is Root in both of them). > > *Andreea Tecuceanu* > (Freescale Semiconductor) > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------010903090100090201060201 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yes, I noticed this as well. It is unfortunate because as you say, there is now no way to identify which instance a Error in SRH is for, and subsequently the root node can't just remove that routing entry in a specific instance. Instead it must either remove that entry from all instances or do nothing and wait for the next DAO to update the entry.

Dario

On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote:

Hello,

 

I have observed that the RPLInstanceID field from Source Routing header (present in  draft-ietf-6man-rpl-routing-header-07) was removed in RFC6554.

Are there particular reasons for this? This field is necessary at the DODAG Root when it receives a  Destination Unreachable with code "Error in Source Routing Header" to identify the instance with the problem (only if there are two instances with the same prefix and if the node is Root in both of them).

 

 

Andreea Tecuceanu
(Freescale Semiconductor)



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

--------------010903090100090201060201-- From jonhui@cisco.com Fri Jun 1 19:47:02 2012 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 2BDF111E80B8 for ; Fri, 1 Jun 2012 19:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OU4O3MSFH+Z5 for ; Fri, 1 Jun 2012 19:47:01 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 4973E11E808C for ; Fri, 1 Jun 2012 19:47:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=7226; q=dns/txt; s=iport; t=1338605221; x=1339814821; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=/njZWDO434dm6vhM8I8+Y5c8HyCCPhTIhKprXz3BDto=; b=mYF5O2R20NsBBsoC5L04K3Eo7WihNCvxKDZ4P6O6zzwcw/nX+6pL8d4C EWLbO49saZ9UUFOZ2ehFdyDqprlURxClhM/YQCfhjP5syLG5IfA8rSiGr mhO//FUaZtYuMEgChHMriCE2540T/kF+YRHiMswMSIeizmxqsFbtis2uk w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAAZ+yU+rRDoJ/2dsb2JhbAA7CoJFsX+BB4IYAQEBAwEBAQEPARpBCwULCw4KLicwBhMih2QEDJgZn1IEiw8QhSBgA4hAjFmOD4FmgwA X-IronPort-AV: E=Sophos;i="4.75,700,1330905600"; d="scan'208,217";a="47275455" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 02 Jun 2012 02:47:00 +0000 Received: from sjc-vpn6-1990.cisco.com (sjc-vpn6-1990.cisco.com [10.21.127.198]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q522kxZR023936; Sat, 2 Jun 2012 02:46:59 GMT Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: multipart/alternative; boundary=Apple-Mail-1--479232985 From: Jonathan Hui In-Reply-To: <4FC978A2.30202@exegin.com> Date: Fri, 1 Jun 2012 19:46:59 -0700 Message-Id: <07C8A712-9390-4704-8823-5E38C9635DBC@cisco.com> References: <4FC978A2.30202@exegin.com> To: Dario Tedeschi X-Mailer: Apple Mail (2.1084) Cc: "roll@ietf.org" Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554 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, 02 Jun 2012 02:47:02 -0000 --Apple-Mail-1--479232985 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I don't understand the need for knowing the RPLInstanceID when handling = an ICMP Destination Unreachable error. The SRH does not follow any RPL = Instance, just the IPv6 addresses listed in the SRH. Receiving an ICMP = Destination Unreachable error from a node S simply means that S could = not forward to the next IPv6 address in the SRH. The inability of S to = forward to the specified next hop would be true regardless of what RPL = Instance the SRH was constructed from. -- Jonathan Hui On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote: > Yes, I noticed this as well. It is unfortunate because as you say, = there is now no way to identify which instance a Error in SRH is for, = and subsequently the root node can't just remove that routing entry in a = specific instance. Instead it must either remove that entry from all = instances or do nothing and wait for the next DAO to update the entry. >=20 > Dario >=20 > On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote: >>=20 >> Hello, >> =20 >> I have observed that the RPLInstanceID field from Source Routing = header (present in draft-ietf-6man-rpl-routing-header-07) was removed = in RFC6554. >> Are there particular reasons for this? This field is necessary at the = DODAG Root when it receives a Destination Unreachable with code "Error = in Source Routing Header" to identify the instance with the problem = (only if there are two instances with the same prefix and if the node is = Root in both of them). >> =20 >> =20 >> Andreea Tecuceanu >> (Freescale Semiconductor) >>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-1--479232985 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

I don't understand the need for knowing the RPLInstanceID when handling an ICMP Destination Unreachable error.  The SRH does not follow any RPL Instance, just the IPv6 addresses listed in the SRH.  Receiving an ICMP Destination Unreachable error from a node S simply means that S could not forward to the next IPv6 address in the SRH.  The inability of S to forward to the specified next hop would be true regardless of what RPL Instance the SRH was constructed from.

--
Jonathan Hui

On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote:

Yes, I noticed this as well. It is unfortunate because as you say, there is now no way to identify which instance a Error in SRH is for, and subsequently the root node can't just remove that routing entry in a specific instance. Instead it must either remove that entry from all instances or do nothing and wait for the next DAO to update the entry.

Dario

On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote:

Hello,

 

I have observed that the RPLInstanceID field from Source Routing header (present in  draft-ietf-6man-rpl-routing-header-07) was removed in RFC6554.

Are there particular reasons for this? This field is necessary at the DODAG Root when it receives a  Destination Unreachable with code "Error in Source Routing Header" to identify the instance with the problem (only if there are two instances with the same prefix and if the node is Root in both of them).

 

 

Andreea Tecuceanu
(Freescale Semiconductor)



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

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

--Apple-Mail-1--479232985-- From gnawali@cs.uh.edu Sat Jun 2 01:45:35 2012 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 4522D21F8A69 for ; Sat, 2 Jun 2012 01:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.37 X-Spam-Level: X-Spam-Status: No, score=-5.37 tagged_above=-999 required=5 tests=[AWL=0.607, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkkxHVKrEUux for ; Sat, 2 Jun 2012 01:45:34 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5F66321F8A68 for ; Sat, 2 Jun 2012 01:45:34 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 6046B23CA88 for ; Sat, 2 Jun 2012 03:45:32 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFHVsBmcPpY8 for ; Sat, 2 Jun 2012 03:45:32 -0500 (CDT) Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id A0FD123CA8F for ; Sat, 2 Jun 2012 03:45:29 -0500 (CDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by it.cs.uh.edu (Postfix) with ESMTP id 9DD392A280C0 for ; Sat, 2 Jun 2012 03:42:36 -0500 (CDT) Received: by yenq13 with SMTP id q13so2566115yen.31 for ; Sat, 02 Jun 2012 01:45:30 -0700 (PDT) Received: by 10.236.155.6 with SMTP id i6mr913362yhk.11.1338626730480; Sat, 02 Jun 2012 01:45:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.165.20 with HTTP; Sat, 2 Jun 2012 01:45:10 -0700 (PDT) In-Reply-To: <5E46BEEE-3B9B-4E94-B54F-FE95CB8FE642@gmail.com> References: <12418.1337957631@marajade.sandelman.ca> <5E46BEEE-3B9B-4E94-B54F-FE95CB8FE642@gmail.com> From: Omprakash Gnawali Date: Sat, 2 Jun 2012 03:45:10 -0500 Message-ID: To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org, "Pascal Thubert \(pthubert\)" Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions 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, 02 Jun 2012 08:45:35 -0000 My understanding is the metric to be used by MRHOF is to be carried in the DAG metric container in DIOs. If an instance is using a given metric, that metric will be in the metric container. - om_p On Fri, Jun 1, 2012 at 2:47 PM, Ralph Droms wrote: > > On May 25, 2012, at 12:31 PM 5/25/12, Pascal Thubert (pthubert) wrote: > >> Hi Michael: >> >> I think RPL does not want to take party there. The OF is a piece of logi= c to tie metrics and policies together. >> As such, there could be multiple metrics as long as there is good logic = to tie them in. for instance one would look at optimizing metric A within c= ontraints as expressed by metric B and the OF model will allow that. >> >> OTOH, it a flows requires a certain optimization (say per one metric) an= d another requires something different, then certainly you want two instanc= es. >> >> So ... it depends! >> >> Pascal >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Michael Richardson >> Sent: vendredi 25 mai 2012 16:54 >> To: roll@ietf.org >> Subject: [Roll] knowing which multiple metrics matter: MRHOF related que= stions >> >> >> Ralph asked some questions a few days ago. >> His originally DISCUSS is at: >> =A0 =A0http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresi= s-of/ballot/ >> >> This was my reply. =A0 =A0I am particularly interested in replies from >> Pascal, Anders and Mukul about my assertion about how we would never pic= k RPL instances by metrics; that they would in fact be seperate RPL Instanc= e numbers and DODAG values, and that these things would provisioned by the = network installer. >> >> =3D=3D=3D=3D >> >> I'm going to reply to your comments in a different order than you asked = them, because I think question #3 is most important, and the rest fall out = of it. >> >>>>>>> "Ralph" =3D=3D Ralph Droms writes: >> =A0 =A0Ralph> 3. Based on (1) and (2), would configuration and selection >> =A0 =A0Ralph> issues be ameliorated if the five candidate selected metri= cs >> =A0 =A0Ralph> were each asssigned a separate objective function? =A0Use = of a >> =A0 =A0Ralph> separate OF code point for each of the five possible selec= ted >> =A0 =A0Ralph> metrics would allow multiple RPL instances. >> >> I think that it's important to understand that ROLL has a whole palette = of things that need to be provisioned by the "network operator". >> >> In contrast to the situation of ISPs and customers, where the ISP is the= network operator, ROLL networks are more like highly orchestrated >> Enterprises: "all your host belong to us" >> >> so, when we write something like: >> =A0 =A0"The metric chosen by the network operator to use for path >> =A0 =A0selection." >> in section 2, we really mean: >> =A0 =A0"The metric chosen by the network operator and provisioned into >> =A0 =A0the node when the firmware was flashed to use for path selection.= " > > OK, so I get that the model is that MRHOF is a toolbox, where the specifi= c tools are chosen when the device is flashed. =A0In that case, I think som= e additional review might be needed to ensure that the MRHOF spec is intern= ally consistent with that point of view. > > As one example, I think the "selected metric" should be called out explic= itly somewhere in section 5 and included in the list of configured paramete= rs in section 6.1. > > As another example, I read this text from section 3: > > =A0 Rank is undefined for these node/link metrics: node state and > =A0 attributes, throughput, and link color. =A0If the rank is undefined, > =A0 the node must join one of the neighbors as a RPL Leaf node according > =A0 to [RFC6550]. > > to mean that if the selected metric is one of the metrics for which rank = is undefined, the node joins as a lead node. =A0But, how can that happen if= the selected metric is chosen by the network operator? > >> Ralph> 1. =A0Why is one objective function defined for several potential >> Ralph> metrics? =A0The details of MRHOF seem to preclude the establishme= nt >> Ralph> of several RPL instances in an LLN, each of which uses MRHOF with >> Ralph> a different selected metric. >> >> If one had many different RPL Instances, then we would have different >> RPL Instance numbers in the RPL header. =A0 There can be many different >> DODAG ("destinations") created within that instance. =A0The instances sh= are a common set of (provisioned) parameters. > > How does a node know which RPL Instance number maps to which selected met= ric? > > One way would be to specify that a node advertise ONLY the selected metri= c for the RPL Instance in a DIO. > >> (To put it into DHCP terms: if we have multiple DHCP servers on a link, = =A0then one would expect them to all offer IP addresses in the same subnet. >> If one wanted to have addresses in different subnets, and let the host = =A0pick between them, then, one would need different layer-2s: different = =A0VLANs or ESSIDs, or... ) >> >> If you feel that RPL is rather schizo about provisioning vs configuratio= n, then I agree. =A0It's not always clear to me why some things are adverti= sed while others are provisioned. >> >> In BGPv4, we calculate metrics by adding AS entries in the path. >> (It's always additive), and we add at least one AS entry to the path. >> One can AS-stuff and add more, but proper operation of BGP does not depe= nd upon the exact algorithm used. >> >> Finally, my impression is that how the various metrics are used (singly,= or in some combination) to calculate Rank Increase is a question of furthe= r research, experimentation, and trade secret. > > Well, OK, but for the purposes of the MRHOF spec, it seems pretty clear t= o me there is one selected metric that is used across all nodes as a strict= ly additive path cost computation. > >> So long as the Rank increases, and a node does not flap between parents,= the exact details do not matter. =A0Each node can do it's parent selection= based upon the available metrics on it's own. =A0It advertises the metrics= it has. >> >> I hope the authors will correct me if I'm completely off here. > > I read the spec to require a single selected metric across the entire RPL= Instance. > > - Ralph > >> >> >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From gnawali@cs.uh.edu Sat Jun 2 01:52:11 2012 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 ED3B321F8A6F for ; Sat, 2 Jun 2012 01:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.522 X-Spam-Level: X-Spam-Status: No, score=-5.522 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3oHDhVed6VEs for ; Sat, 2 Jun 2012 01:52:11 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5D021F8A6E for ; Sat, 2 Jun 2012 01:52:11 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 9025F23CA86 for ; Sat, 2 Jun 2012 03:52:09 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HRF07Pi42Ymu for ; Sat, 2 Jun 2012 03:52:09 -0500 (CDT) Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 0D43723CA8B for ; Sat, 2 Jun 2012 03:52:07 -0500 (CDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by it.cs.uh.edu (Postfix) with ESMTP id 0CF562A280CE for ; Sat, 2 Jun 2012 03:49:13 -0500 (CDT) Received: by ghbg16 with SMTP id g16so2925799ghb.31 for ; Sat, 02 Jun 2012 01:52:08 -0700 (PDT) Received: by 10.100.86.1 with SMTP id j1mr1661746anb.50.1338627127970; Sat, 02 Jun 2012 01:52:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.165.20 with HTTP; Sat, 2 Jun 2012 01:51:47 -0700 (PDT) In-Reply-To: <535F88D6-7E39-417A-BEB7-CC67B1FFE788@cisco.com> References: <535F88D6-7E39-417A-BEB7-CC67B1FFE788@cisco.com> From: Omprakash Gnawali Date: Sat, 2 Jun 2012 03:51:47 -0500 Message-ID: To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, roll@ietf.org Subject: Re: [Roll] "Link quality" as a metric for MRHIF 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, 02 Jun 2012 08:52:12 -0000 On Fri, Jun 1, 2012 at 3:14 PM, Ralph Droms wrote: > How is the "link quality" metric used as a selected metric in MRHOF? =A0A= s I read RFC 6551, the link quality container carries a list of individual = link qualities. =A0To use the link quality metric in MRHOF, does the comput= ing node add up all the link qualities from the container option to compute= the parent path cost? =A0What about link quality sub-objects with link qua= lity value "0"? Yes, adding up all the link quality level to compute the path cost. Adding up all the link quality level, including a 0, will result in some value which is converted to rank but it is not clear if MRHOF would be the best objective function to use if you want to use link quality level metric. - om_p From gnawali@cs.uh.edu Sat Jun 2 02:06:46 2012 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 6017521F8A43 for ; Sat, 2 Jun 2012 02:06:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.613 X-Spam-Level: X-Spam-Status: No, score=-5.613 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fYKGLiqOswCP for ; Sat, 2 Jun 2012 02:06:45 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8A99021F8A51 for ; Sat, 2 Jun 2012 02:06:43 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 706D923CA8F for ; Sat, 2 Jun 2012 04:06:38 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dENTpmOA1G8B for ; Sat, 2 Jun 2012 04:06:35 -0500 (CDT) Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id F233023CA88 for ; Sat, 2 Jun 2012 04:06:34 -0500 (CDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by it.cs.uh.edu (Postfix) with ESMTP id 0AF8E2A280C1 for ; Sat, 2 Jun 2012 04:03:41 -0500 (CDT) Received: by ggnc4 with SMTP id c4so2571352ggn.31 for ; Sat, 02 Jun 2012 02:06:35 -0700 (PDT) Received: by 10.236.193.67 with SMTP id j43mr955744yhn.17.1338627995970; Sat, 02 Jun 2012 02:06:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.165.20 with HTTP; Sat, 2 Jun 2012 02:06:15 -0700 (PDT) In-Reply-To: References: <058.aaa3fc2efaae8e26a2ada588bce49a89@trac.tools.ietf.org> <19632.1337959850@marajade.sandelman.ca> From: Omprakash Gnawali Date: Sat, 2 Jun 2012 04:06:15 -0500 Message-ID: To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org, draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org Subject: Re: [Roll] [roll] #99: clarify for readers how/where provisioning of devices occurs 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, 02 Jun 2012 09:06:46 -0000 On Fri, Jun 1, 2012 at 2:28 PM, Ralph Droms wrote: > > On May 25, 2012, at 11:30 AM 5/25/12, Michael Richardson wrote: > >> >>>>>>> "Omprakash" =3D=3D Omprakash Gnawali writes: >> =A0 =A0Omprakash> I was wondering if the first paragraph of 6.1 is enoug= h for things >> =A0 =A0Omprakash> that need to be configured/provisioned for MRHOF. >> >> I think that it works for *MRHOF*, but I think that we have a bigger >> picture problem here. > > Given that the ZigBee IP spec prescribes the details of how to use MRHOF,= a node that implements ZigBee IP and will not be used in any other deploym= ent scenario can be configured at manufacturing time and there is no need f= or the node to "allow the [...] parameters to be configured at installation= time". =A0However, I think draft-ietf-roll-minrank-hysteresis-of would be = improved by expanding the sense of the text to something like: > > =A0 An implementation needs specific values for the following > =A0 paramters: [...] =A0These parameters may be set at device > =A0 manufacturing time or configured at installation time. =A0RPL/MRHOF > =A0 do not provide a way for the appropriate values for these > =A0 parameters to be discovered through the network. This is a good feedback based on what is happening in practice. Happy to incorporate this by changing the existing text from: An implementation SHOULD allow the following parameters to be configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST, PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT. An implementation MAY allow these parameters to be configured dynamically at run time once a network has been deployed. to: An implementation needs specific values for the following parameters: MAX_LINK_METRIC, MAX_PATH_COST, PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT. These parameters may be set at device manufacturing time, configured at installation time, or configured at run time once a network has been deployed. MRHOF does not directly help determine the values for these parameters. - om_p From gnawali@cs.uh.edu Sat Jun 2 02:13:29 2012 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 64A7F21F8A09 for ; Sat, 2 Jun 2012 02:13:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.673 X-Spam-Level: X-Spam-Status: No, score=-5.673 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSXc-6SiEGAh for ; Sat, 2 Jun 2012 02:13:29 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id D711F21F8A04 for ; Sat, 2 Jun 2012 02:13:28 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 0EF9523CA8F for ; Sat, 2 Jun 2012 04:13:27 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qJJihmpTgfW for ; Sat, 2 Jun 2012 04:13:24 -0500 (CDT) Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 3B90C23CA86 for ; Sat, 2 Jun 2012 04:13:24 -0500 (CDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by it.cs.uh.edu (Postfix) with ESMTP id DCCF82A280C1 for ; Sat, 2 Jun 2012 04:10:30 -0500 (CDT) Received: by ghbg16 with SMTP id g16so2929073ghb.31 for ; Sat, 02 Jun 2012 02:13:22 -0700 (PDT) Received: by 10.236.173.232 with SMTP id v68mr878465yhl.97.1338628402452; Sat, 02 Jun 2012 02:13:22 -0700 (PDT) MIME-Version: 1.0 Received: by 10.146.165.20 with HTTP; Sat, 2 Jun 2012 02:13:02 -0700 (PDT) In-Reply-To: <943C0516-F78E-43FD-AECD-F66A8B930F21@gmail.com> References: <943C0516-F78E-43FD-AECD-F66A8B930F21@gmail.com> From: Omprakash Gnawali Date: Sat, 2 Jun 2012 04:13:02 -0500 Message-ID: To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, roll@ietf.org Subject: Re: [Roll] "Node energy" as a metric for MRHOF 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, 02 Jun 2012 09:13:29 -0000 On Fri, Jun 1, 2012 at 2:53 PM, Ralph Droms wrote: > I came across a new puzzle while re-reading draft-ietf-roll-minrank-hyste= resis-of. > > "Node energy" doesn't appear to be listed as an additive metric in RFC 65= 51. =A0Reading the description of the node energy metric, which carries rem= aining battery capacity as a percentage of initial capacity, I have no clue= how a node using MRHOF would compute a path cost based on node energy. =A0= Does node energy really fit as one of the metrics that MRHOF can use? One could certainly add up the node energy for all the links, however, it is probably better to use the path that maximized the minimum energy along the path as suggested in RFC 6551. If so, MRHOF would not be the best OF to use when one uses node energy as the metric. - om_p From jpv@cisco.com Sat Jun 2 07:25:29 2012 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 C4A5821F8535 for ; Sat, 2 Jun 2012 07:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSOzZyju-sor for ; Sat, 2 Jun 2012 07:25:29 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 2C51021F8534 for ; Sat, 2 Jun 2012 07:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=2229; q=dns/txt; s=iport; t=1338647129; x=1339856729; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=2Bs5ZVSnU4r5JSbZwWNAcUK+ztK0KSf/mzZ2+CdIzKE=; b=kGoNL7FdPSuDZ9jY23XsimmDVcfvRRydCMlEM9f81OV6dJmm9toPI/qr uVaDZb1eA+c6E6dRSfdg9niH1o+yv0wt5a5FfKwozKYZGjQ1gzmdkfowD Ne0u4t0cCH1QluO/MvAo2PsI4fNWSj5bR/YF85OgTSNqAd4HOoLGA/eCa M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAKwhyk+rRDoH/2dsb2JhbABFtB2BB4IYAQEBAwEBAQEPASc0CwULC0YnMAYBEiKHZAQBC5dSnxmLEYUwYAOVG4EPhEGIQIFmgmI X-IronPort-AV: E=Sophos;i="4.75,701,1330905600"; d="scan'208";a="44823203" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 02 Jun 2012 14:25:28 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q52EPSjr003609; Sat, 2 Jun 2012 14:25:28 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Jun 2012 07:25:28 -0700 Received: from [10.60.114.229] ([10.60.114.229]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Jun 2012 07:25:28 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: Date: Sat, 2 Jun 2012 14:35:24 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <71D540B5-B2E9-4B5C-AE11-ECAA6E18655C@cisco.com> References: <12418.1337957631@marajade.sandelman.ca> <31164.1337974189@marajade.sandelman.ca> To: "Pascal Thubert (pthubert)" , "roll@ietf.org WG" X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 02 Jun 2012 14:25:29.0167 (UTC) FILETIME=[8F614DF0:01CD40CB] Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions 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, 02 Jun 2012 14:25:29 -0000 Agree with Pascal - for information there was a discussion about 2 years = on the subject matter and there was a consensus not to try to either mix metrics/constraints (which IMO is the right = thing to do even if it leads to sub-optimality or disconnected areas) or try to make use of default metrics. On May 28, 2012, at 12:04 PM, Pascal Thubert (pthubert) wrote: > Hello Micheal >=20 >>>>>> "Pascal" =3D=3D Pascal Thubert <(pthubert)" > = writes: > Pascal> I think RPL does not want to take party there. The OF is a > Pascal> piece of logic to tie metrics and policies together. =20 >=20 > My question is: >=20 > - do the nodes of a DODAG have to use the same metrics to pick a = parent, > (and if so, how do they agree) > I think that they do not, so long as they use an algorithm (such as > MRHOF) which has certain properties. >=20 > [Pascal] The current spec requires that all players of an instance = play by the same rule, that is same OF, in order to guarantee the = expected result.=20 > The goal there was deeper than the OF, like same OF with same = parameterization. MRHOF is generic and allows various incarnations, = depending in the metrics; all those incarnations are to be seen as = different OFs WRT to RPL 's uniqueness rule. >=20 > Note that this rule is not for looplessness, the Rank would assure = that anyway. >=20 >=20 > - if we had multiple RPL instances in an LLN, using different metrics, > then we would have multiple RPL Instances and DODAGs. The different > set of metrics would not co-exist in the same RPL Instance. >=20 > [Pascal] I think we agree. An instance can use multiple metrics bound = by some logic. But those metrics and that logic must be identical = throughout the instance.=20 > A different (set of) metric means a different OF even if MRHOF is = behind both. >=20 > Cheers, >=20 > Pascal >=20 > --=20 > Michael Richardson , Sandelman Software Works=20= > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Sat Jun 2 07:25:37 2012 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 C163221F853C for ; Sat, 2 Jun 2012 07:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pP9YBSlO-1wa for ; Sat, 2 Jun 2012 07:25:37 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 57F0821F853B for ; Sat, 2 Jun 2012 07:25:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=1031; q=dns/txt; s=iport; t=1338647137; x=1339856737; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=5xKbEQi+NNDFtsfn3cf1bwxZZatXbsiXJSZx5d7JEXE=; b=QbTKLaBek6cHTLvBnaXw/QuubC47ISzpt+3XHczKYJafgkSZXmJIZGbH ksQ19DFa0LKCOpKpXcAZCliq43864qM6SAmhnSzi0F65Fr0V5/rSZEuub NjDQZwsdDej0qwBK35pKmZZ2A3aj/P1L+tNMPQqQFWWq3dDtiI3SyWJ+I 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAOkgyk+rRDoH/2dsb2JhbABFtB2BB4IYAQEBAwEBAQEPAVQHCwULCw44JzAGEyKHZAQBC5dSnxUEixEFhStgA5UbhVCIQIFmgmI X-IronPort-AV: E=Sophos;i="4.75,701,1330905600"; d="scan'208";a="47398304" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 02 Jun 2012 14:25:37 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q52EPbkP003670; Sat, 2 Jun 2012 14:25:37 GMT Received: from xfe-sjc-232.amer.cisco.com ([128.107.191.79]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 2 Jun 2012 07:25:36 -0700 Received: from [10.60.114.229] ([10.60.114.229]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 2 Jun 2012 07:25:37 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: JP Vasseur In-Reply-To: <943C0516-F78E-43FD-AECD-F66A8B930F21@gmail.com> Date: Sat, 2 Jun 2012 16:22:00 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <67497215-FAB5-4AC1-B5D0-7FB9963AF3B9@cisco.com> References: <943C0516-F78E-43FD-AECD-F66A8B930F21@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 02 Jun 2012 14:25:37.0323 (UTC) FILETIME=[943DCFB0:01CD40CB] Cc: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, roll@ietf.org Subject: Re: [Roll] "Node energy" as a metric for MRHOF 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, 02 Jun 2012 14:25:37 -0000 Thanks Ralph. When you say "path cost based on node energy", you refer = to using a cumulative metric where node metric are inversely=20 proportional to the remaining energy ? I am asking since there are = several approaches to compute the metric, it could be coupled with=20 the remaining energy used as a constraint, =85 Thanks. JP. On Jun 1, 2012, at 9:53 PM, Ralph Droms wrote: > I came across a new puzzle while re-reading = draft-ietf-roll-minrank-hysteresis-of. >=20 > "Node energy" doesn't appear to be listed as an additive metric in RFC = 6551. Reading the description of the node energy metric, which carries = remaining battery capacity as a percentage of initial capacity, I have = no clue how a node using MRHOF would compute a path cost based on node = energy. Does node energy really fit as one of the metrics that MRHOF = can use? >=20 > - Ralph >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abdussalambaryun@gmail.com Sun Jun 3 01:37:15 2012 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 64A0221F8613 for ; Sun, 3 Jun 2012 01:37:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.442 X-Spam-Level: X-Spam-Status: No, score=-3.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wxZAFwlfF6Hc for ; Sun, 3 Jun 2012 01:37:14 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id AE5DB21F8611 for ; Sun, 3 Jun 2012 01:37:14 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2248555vcq.31 for ; Sun, 03 Jun 2012 01:37:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=XeoQwO7YZf6zRnRSdzL6A1H8LI+7bgHjfhmhulDzrjM=; b=g0MClwUQKtKbZq1RJE5OMRGYV38KjAy9nyHzdKDpNcsXGM0sBMqLYBoujMTqQtQoGg cd56QK6KoMlhC8iY65dq8EWMFTRrO21TIDza37FytV9OCeYN1JHDGc2a0mNe14m+LzEA qkwvnC1Sn8bwxjCJ1v43RPz62GRHumUHvlzNmRC78AR8LaOTBhyyKk0xC9BBp6OrORsy VF8DLVvFLUA6F0hwKE91Ejq78841Wzh8MYpbI1n+ux5txigWaG4Q5+qQSR4620qym/uC wLSVlxJw3yRDnaqoEemNyWxOPIE49LsTFNaPKtmtIQKs4tj5mjmM5Xm1u72Q/Jp+DzLI l0+w== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr7377107vds.117.1338712633939; Sun, 03 Jun 2012 01:37:13 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Sun, 3 Jun 2012 01:37:13 -0700 (PDT) In-Reply-To: References: Date: Sun, 3 Jun 2012 10:37:13 +0200 Message-ID: From: Abdussalam Baryun To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] Node Ability to Participate (NAP) 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, 03 Jun 2012 08:37:15 -0000 ================Possible Duplication=================== Hi All, I want to discuss is there a need to consider the node ability to participate (NAP) in LLN functions? I think that the node ability (considering; energy consumption issue, routing issue, and environment-event issue), it is good for some node-originators to know neighbor nodes/sinks ability ( NAP to-route, or NAP continue-to-route, or NAP to-survive, NAP to-store, NAP to-manage, or other abilities), but not sure if it is available in some of the ROLL or 6lowpan protocols, nor sure if it can make side effects to LLN performance. The node-ability can be useful if we have different devices capabilities and conditions. This knowledge-factor can be useful and may be included in some technique, or forwarding table in the protocol specification. I want to know your advises and opinion, thanking you, Best regards Abdussalam Baryun, University of Glamorgan, UK. ======================================================= ( One may be wrong, or may be right, but it does not matter if we work together as a group to discuss and resolve all issues. WGs are always right ) **************************************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. The contents are comply to the IETF regulations, and WG procedures. You should not copy the email nor use it for any other purpose, nor disclose, nor distribute its contents to any other person. ***************************************************************************************** From abdussalambaryun@gmail.com Sun Jun 3 02:51:05 2012 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 0F1B921F8611 for ; Sun, 3 Jun 2012 02:51:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.463 X-Spam-Level: X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6vnl7TWTNRd for ; Sun, 3 Jun 2012 02:51:04 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 70A2621F860F for ; Sun, 3 Jun 2012 02:51:04 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2259075vbb.31 for ; Sun, 03 Jun 2012 02:50:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=D/+TD228pH/URILi7kRG17EjgfZfOppZRk+kRA3b+4k=; b=J7ybIDq0w23jexZ+rrBHn5QKKf1RHSlpyYbVRj6Po7JievonnmPUJH0D4zYo1AdXgA Gcwoixck7hxrhf4kmq/vr+YkxwIYCum1P5qN1aRieX2dnzaWsCVfrVbWUEApZMUfnZfu oTMFMaYgQhhJSCzJ5hwPMYBYea9uZxwZNF3o1xIb1Ym0pJdJ5pHjUWTI8z4VTq1uiagg tsuwI+sZbCwQ9m0C1k4EcAMp9XQApZWspqim70+G9BX3yJih6uZeUeEo2lopPiB84Udw yOC1m7I91lypaSMzmCvLi6NL5K2ip6LFAC9Y/YM2lxwcOi/yEXnMAvzdPtktqkrDx/9n 9dXw== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr7472078vds.117.1338717058602; Sun, 03 Jun 2012 02:50:58 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Sun, 3 Jun 2012 02:50:58 -0700 (PDT) Date: Sun, 3 Jun 2012 11:50:58 +0200 Message-ID: From: Abdussalam Baryun To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: [Roll] draft-ietf-roll-terminology-06.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: Sun, 03 Jun 2012 09:51:05 -0000 Hi Vasseur, I want to ask about the draft of ROLL terminology, when will it be re-activated? because expired, and if it is completed should we make it go forward, or is it better to wait for other drafts to come in, not sure, please advise, thanking you, Abdussalam Baryun, University of Glamorgan, UK From rdroms.ietf@gmail.com Sun Jun 3 04:59:28 2012 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 45C1921F867F for ; Sun, 3 Jun 2012 04:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.002 X-Spam-Level: X-Spam-Status: No, score=-102.002 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jpp9UZcOmsUF for ; Sun, 3 Jun 2012 04:59:26 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8ABF021F867D for ; Sun, 3 Jun 2012 04:59:26 -0700 (PDT) Received: by yhq56 with SMTP id 56so2708416yhq.31 for ; Sun, 03 Jun 2012 04:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; bh=QLT6QpUA7JIWZSJCaHzacv+rOBg+7GQnnL7KgpTlEvc=; b=zz/mHOKoHlYhLYor82tFX9bqdH+Eoesuho9hgNRD/cZvetlad2j7KgkE0IxpNvX215 jApRK6kmBTLV8B77Pxnou5E23mYEdBeKN8ef/2mC52vYv0a1xrOJcI4H0Xwqgpj+DK01 jsd+lZvntsGCTCx1+q1Uvr0xQWgYgclh/NvkBzZZclxwheszm6bz+P13Zb6cWnq2nCOK Zj2haTmTAzzOrkJXiDgw/6vTO1FZ7QzRznbitgvGBJq/9w18Omkz8gKUJ0tkZ2dGv/7j SXYVnh8k/FbIhduNLM79qZX0X+OYUFGx5AJ6qUPoA/rIi89AgH9Ty4ybTUTcAWK2iDUy q5lA== Received: by 10.236.187.2 with SMTP id x2mr3822833yhm.42.1338724766115; Sun, 03 Jun 2012 04:59:26 -0700 (PDT) Received: from [172.28.172.207] (h114.178.216.66.static.ip.windstream.net. [66.216.178.114]) by mx.google.com with ESMTPS id v16sm10556687anh.22.2012.06.03.04.59.22 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 03 Jun 2012 04:59:24 -0700 (PDT) References: <535F88D6-7E39-417A-BEB7-CC67B1FFE788@cisco.com> In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <037178D2-ED90-4204-ACAA-982472DA767B@gmail.com> X-Mailer: iPad Mail (9B206) From: Ralph Droms Date: Sun, 3 Jun 2012 07:59:28 -0400 To: Omprakash Gnawali Cc: "draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org" , "roll@ietf.org" , Ralph Droms Subject: Re: [Roll] "Link quality" as a metric for MRHIF 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, 03 Jun 2012 11:59:28 -0000 On Jun 2, 2012, at 4:51 AM, Omprakash Gnawali wrote: > On Fri, Jun 1, 2012 at 3:14 PM, Ralph Droms wrote: >> How is the "link quality" metric used as a selected metric in MRHOF? As I= read RFC 6551, the link quality container carries a list of individual link= qualities. To use the link quality metric in MRHOF, does the computing nod= e add up all the link qualities from the container option to compute the par= ent path cost? What about link quality sub-objects with link quality value "= 0"? >=20 > Yes, adding up all the link quality level to compute the path cost. > Adding up all the link quality level, including a 0, will result in > some value which is converted to rank but it is not clear if MRHOF > would be the best objective function to use if you want to use link > quality level metric. Ok, then the MRHOF spec should be revised to drop link quality level as one o= f the candidate selected metrics or to specify in detail how to use link qua= lity level as the selected metric. - Ralph >=20 > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From ietf@thomasclausen.org Sun Jun 3 16:25:26 2012 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 DEF8021F8745 for ; Sun, 3 Jun 2012 16:25:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWQwY23u4Dld for ; Sun, 3 Jun 2012 16:25:26 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 3518221F8739 for ; Sun, 3 Jun 2012 16:25:26 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id EEE9A557F88 for ; Sun, 3 Jun 2012 16:25:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 62C1B1C01B91; Sun, 3 Jun 2012 16:25:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.1.113] (Cs-136-215.CS.UCLA.EDU [131.179.136.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 2E1671C01B90; Sun, 3 Jun 2012 16:25:25 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Thomas Heide Clausen In-Reply-To: Date: Sun, 3 Jun 2012 16:25:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu> <2AF45E51-6C3B-48D9-908F-117ECF0CABAA@imag.fr> To: JP Vasseur X-Mailer: Apple Mail (2.1257) Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences 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, 03 Jun 2012 23:25:27 -0000 Dear JP, Opaque LSAs are an interesting, although entirely irrelevant, example - = an apples-to-oranges comparison.=20 Opaque LSAs are simply "containers for application specific data, for = distribution through an OSPF domain (link, area, AS wide)". As such, = it's - of course - difficult to specify a transmission frequency; I am = sure that we agree that this naturally is an application dependent = issue. DAOs are much more akin to OSPF HELLO or LSA packets, in that they = pertain to distributing topology proper for the routing protocol = operation - specifically, DAOs are not the slightest like opaque LSAs. = OSPF does quite specify expectations for when, for example, a HELLO = packet should have been received (RouterDeadInterval / InactivityTimer) = or LSAs re-flooded (LSRefreshTime). In other words, for opaque LSAs, the content of the LSA is opaque to the = routing protocol (could be anything), whereas the dissemination process = is well defined. Contrast with DAO, where the content is known (and very = much important to the routing protocol), alas, the processing and = dissemination is opaque and so you need an external mechanism for DAO to = work properly. I also note a different point, which is that the environment wherein an = OSPF router generally operates (accessible, network engineer access = during operation) is very different from the environment wherein an RPL = router is expected to operate. Finally, there are protocols, typically those designed for non-managed = deployments. which permit routers with different parameter = configurations to interoperate, and then again others where lack of = needed information can simply trigger a request for it to be generated. Concluding: thus comparing with an information type for a different = purpose, extracted from a protocol for a different deployment with = constraints of a different nature doesn't really help. Best, Thomas On May 19, 2012, at 12:39 , JP Vasseur wrote: > Hi Martin, >=20 > co-chair hat off =85 >=20 > How often do you think that ISIS LSA should be refreshed ? > Or OSPF opaque LSA for TE extensions be flooded ? > Or BFD packets ?=20 > Or PCEP Keepalive when turned on ? >=20 > Very seriously =85 these questions apply to all protocols =85 and you = cannot expect the specifications to give you > hard coded values (but default whenever possible); these are topology = and application specific, don't you think ? >=20 > Thanks. >=20 > Cheers. >=20 > JP. >=20 > On May 18, 2012, at 10:46 PM, Martin Heusse wrote: >=20 >> Phil,=20 >> what you are writing bellow may be true (although...) but it does not = address comment 12, that we have no idea when DAOs should be sent and = how DAOs should be handled (how long should the route be kept?).=20 >>=20 >> Along those lines, 2 comments: >> 1) I notice that draft-ietf-roll-applicability-ami, for instance, = ignores DAOs except for specifying that DAOs SHOULD be sent -- so they = might not be sent--, even though "Two-way communication is a = requirement"(?). At the same time, this draft goes as far as suggesting = what parameters to use for trickle (big deal) or for MaxRankIncrease = (big deal: will things break if someone uses 512 instead of 1024?).=20 >> (same comment applies to draft-gnawali-roll-rpl-recommendations-03.) >> 2) What is the point of making DAOs compact in storing mode = (learning the route recursively) while the packets that actually contain = data have to carry the whole path anyway? =20 >>=20 >> Best regards, >> Martin >>=20 >>=20 >> Philip Levis wrote: >>=20 >>> For 12, "implementations may exhibit a bad performance if not = carefully implemented." I think it is safe to say this is true for = almost ANY protocol. A specification is not intended to be a complete = statement of efficient implementation, otherwise you give little = latitude to future improvements and good engineering. >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From IETF@ThomasClausen.org Sun Jun 3 17:27:36 2012 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 3355621F87B4 for ; Sun, 3 Jun 2012 17:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.188 X-Spam-Level: X-Spam-Status: No, score=-1.188 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2TfkqLt77mAI for ; Sun, 3 Jun 2012 17:27:35 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 50DEF21F87B2 for ; Sun, 3 Jun 2012 17:27:35 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 30696557F16 for ; Sun, 3 Jun 2012 17:27:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id EE83A1C01E0A; Sun, 3 Jun 2012 17:27:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.1.113] (Cs-136-215.CS.UCLA.EDU [131.179.136.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id B19521C01E09; Sun, 3 Jun 2012 17:27:34 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Thomas Heide Clausen In-Reply-To: <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu> Date: Sun, 3 Jun 2012 17:27:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <59F4B025-990D-4738-8424-D8078EF9FB7C@ThomasClausen.org> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu> To: Philip Levis X-Mailer: Apple Mail (2.1257) Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 00:27:36 -0000 Dear Phil, Thank you for your review. Comments below (with apologies for the = incurred delay). On May 16, 2012, at 22:02 , Philip Levis wrote: >=20 > On May 16, 2012, at 10:11 AM, Thomas Heide Clausen wrote: >=20 >>=20 >>=20 >> For example:=20 >>=20 >> o the state required for storing/non-storing mode does = *not* depend on a=20 >> specific implementation and deployment, but is an = artifact from the RPL design. >>=20 >> o the message-size of RPL is not dependent on a specific = implementation and deployment, >> but is an artifact from the RPL design. >>=20 >> o the use of links "upwards" based on receipt of traffic = "downwards" (i.e. the unidirectional >> link issue) is not dependent on a specific = implementation and deployment, >> but is an artifact from the RPL design. >>=20 >> o the unknown-by-source MTU issues for data-traffic when = using non-storing mode=20 >> is not dependent on a specific implementation and = deployment, >> but is an artifact from the RPL design. >>=20 >> I could go on, but then it'd be easier to just paste the whole I-D = into this email. >=20 >=20 > Thomas, >=20 > I agree that some points in the ID are valid statements about the = protocol itself, such as message sizes and the issues caused by floating = DODAGs. Those, to me, seem like reasonable points to make. Thank you, we appreciate this. >=20 > However, some of the points are hypotheses about performance (14), a = bit naive about how wireless networks behave (13) or somewhat snippy = gripes (11, 12). In my opinion, a document which focused on factual = statements of the protocol design not really open to interpretation and = cut hypothetical or subjective statements might be ready for the working = group to consider. >=20 > As just a start, I object to 10, 11, 12, 13, and 14 being considered = inherent to the protocol. >=20 Very good, this gives us precise points to discuss technically, and we = want to thank you for having been so precise and constructive in your = email on this subject. > 10 assumes that a node only uses DIO reception to allow a parent; the = specification is pretty clear that you should check the parent is usable = (section 1.1). You're taking a bad implementation decision and assuming = there isn't another way to do things.=20 >=20 That is definitely a fair point to bring up. We agree that various external mechanisms can contribute to make a = smart, or even very smart, parent selection - but, as section 1.1 points = out, as bi-directional links are a minimum requirement, the fact that = RPL doesn't specify a minimum, basic mechanism for ensuring that is = highly problematic. NUD is the only mechanism explicitly called out in = RPL (section 8.2, 9.8, for example), which is why the observations in = section 10 concern RPL when using NUD (and not some other "good (but = unspecified) design decision"). We do, however, understand (but correct us if we are wrong) that you = agree that the mechanisms for this problem, as specified in the RPL RFC, = are insufficient for building and operating networks. That is exactly = the point that we are trying to make also. Where we may differ in opinion (do we?) is, that we think that the IETF = should specify such mechanisms: in order to make interoperable = implementations, some sort of agreement on what a "good implementation = decision" is required, in particular if such requires messages being = exchanged. =20 > For 11, there are implementations of RPL smaller than 50kB; they do = not implement every feature, but that was kind of the point of the = protocol, that it could be implemented on a sliding scale of = implementation complexity. The TinyOS implementation, for example, is, I = believe, ~20kB, less than half the size. You don't report what = architecture the 50kB is for, clearly it would be more for a 32-bit than = a 16-bit architecture.=20 Phil, would you clarify this for us?=20 As the specification reads, there is only the MOP flag that can specify = that which the DODAG root expects from the routers in the network; if a = router receives a MOP flag that it doesn't support, it won't be able to = join as anything as a leaf. There are no negotiations, or discovery of capabilities, we think, nor = is it clear what exactly the "sliding scale" you refer to is. (sure, we = can see the MOP-scale: DIO only, DAO-nonstoring, DAO-storing - but = beyond that, what do we miss?) Short of heavy-handed administrative configuration, the only realistic = way of ensuring interoperability of devices from different vendors is to = support the full spec. But, don't just take our words for complexity issues: http://comments.gmane.org/gmane.os.contiki.devel/12102 The implementation that we cite (URL is in the draft) is the ContikiRPL = implementation, which only supports storing mode, and which consumes = these ~50 KB (in the above link, they talk about 44KB being their code = size). This on a 16bit MSP 430 tmote sky. > For 12, "implementations may exhibit a bad performance if not = carefully implemented." I think it is safe to say this is true for = almost ANY protocol. We think we get your point, and this phrase is indeed a little like "You = can write Fortran77 in any language" ;) > A specification is not intended to be a complete statement of = efficient implementation, otherwise you give little latitude to future = improvements and good engineering. This is very true, and we agree that a specification should = (necessarily) be indicating the most efficient way of doing something.=20= Alas, for example, for DAO messages, as the diffusion mechanism is not = well specified, this may lead to not just inefficiency, but actual = traffic loss by way of connectivity not being accurately reflected in = the information sets on RPL, in very mechanical way.=20 It would, of course, be perfectly fine to specify an inefficient - but = working - method, and allow future improvements and good engineering to = better that. Unfortunately, in this case, no working diffusion method is = given (i.e., it may lead to the above issues). In addition, it is not just about efficient implementation from one = vendor that could mitigate these problems, but rather about allowing for = interoperable implementations in the same routing domain. > For 13, this assumes that a wireless network has a stable topology = which the protocol can converge to. Wireless networks are often NOT = stable: one cannot expect a protocol to converge on a dynamic graph. That it absolutely correct. This observation absolutely applies to the = testbed, in which these trickle experiments were conducted. The point we want to make here is, that contrary to what we observe in = simulations and modeling, when deploying trickle in wireless networks, = one should expect more control traffic than seen in theory and = simulations. We may be able to do an editorial pass to make this section = clearer -- especially as it seems that we do agree on the fundamental = property that's being discussed? > 14 is similarly confused about what a wireless network looks like. How = can the state of a distributed system based on a dynamic topology be = "consistent?" I think this is a fundamental misunderstanding of how the = network works. We are a little unclear on what you mean here, or what you suggest that = we disagree on. Is it the use of "inconsistent" in the penultimate = paragraph of page 24?=20 The purpose is to indicate some of the situations where loops can occur = in RPL, and what the consequences hereof, and of the proposed detection = mechanisms, are - especially the requirement for IPv6-in-IPv6 tunneling = at each hop (which, btw., is independent of if wireless or not). Thank you again, and we hope that you can clarify the issues that we = indicated above. Best, Thomas, Ulrich, Jiazi, Axel > That being said, I think point 6 is well taken and should be = considered, maybe others. Maybe the constructive way to take this = document, if you don't want to take the step of specifying solutions, is = at least casting it as a roadmap for ways in which you think the WG = should improve RPL? >=20 > Phil >=20 From ulrich@herberg.name Sun Jun 3 19:24:24 2012 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 B04BF21F8811 for ; Sun, 3 Jun 2012 19:24:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[AWL=0.357, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHiZRCpHLmYD for ; Sun, 3 Jun 2012 19:24:22 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id A36C221F8808 for ; Sun, 3 Jun 2012 19:24:22 -0700 (PDT) Received: by ggnc4 with SMTP id c4so2992195ggn.31 for ; Sun, 03 Jun 2012 19:24:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=0dMD/MbXG/5oekc4heZfvYVfRhlAu+qvP/Mtk3wpuRQ=; b=yJh7/pY1I4QG4oqhJIQvXX7kbjYbdXakJzrEKFLXuMi3V3osgqKV3RlP1Vdd9qnrMr uvmo6iJYounj6MNXB07p31qZ/jMP0WdSqc4tOn39AFdiQ1JN7GHdEFflUeAmMYegA/xf cLVYEA3GNXzzHSz5Ow5NR8NM35IvmKMa9uypg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=0dMD/MbXG/5oekc4heZfvYVfRhlAu+qvP/Mtk3wpuRQ=; b=Bx+lxbCTmj3gQBtPZn5cYok2+TgTbSFYBz3n+DghqtaEdZnS/KCvJ6puiJr8SzMzJI JZCpJ7vhTqmUD57tbT95TC9QzwddIMN+ongA4PRJ8dTcnYAW4NZkloBBxXZZCzj85enQ c+46gbNAdFwXA8a+RMn7OT2COLDQpqOrP+vr/iOw3Dqymn9WKkJTJemMvl+3lvLQc9Jf nDF1OpOrJDoWbv2dZuLVg16NBfZmXOMM3jVYKPu/Qr/2Xsjj1ATU+FaQiCjdPd69WDob OFJry5ZhrZHD3j8VxT+43hX3XlO70W8icZb1ddtnsf0Rq1vs7sew5lvYmqByqP9RrUG+ 81+Q== MIME-Version: 1.0 Received: by 10.236.191.2 with SMTP id f2mr5376479yhn.120.1338776659086; Sun, 03 Jun 2012 19:24:19 -0700 (PDT) Received: by 10.146.248.21 with HTTP; Sun, 3 Jun 2012 19:24:18 -0700 (PDT) In-Reply-To: <2071633195.463484.1337615149395.JavaMail.root@mail17.pantherlink.uwm.edu> References: <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu> <2071633195.463484.1337615149395.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Sun, 3 Jun 2012 19:24:18 -0700 Message-ID: From: Ulrich Herberg To: Mukul Goyal Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmU7ZjdWhSPp3ADAFnQZqpyJNYHtb5p5Jzxsyjg+KqjP0oiarGKXg8LB5V65HBLy6RRQ2PO Cc: roll WG , Jiazi Yi , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 02:24:24 -0000 Dear Mukul, thank you for your review. Please find my comments below: On Mon, May 21, 2012 at 8:45 AM, Mukul Goyal wrote: > Here is my review for first 9 sections of draft-clausen-lln-rpl-experienc= es-03. For later sections, I have nothing substaintial to add to what Phili= p has already said in the message below. > > One answer to many questions raised in draft-clausen is: use P2P-RPL. In previous email exchanges, it has been argued why we believe this is insufficient (P2P-RPL not officially "updating" or "obsoleting" RPL, and not being Std. Track etc). (see here: http://www.ietf.org/mail-archive/web/roll/current/msg07005.html) > It is not the case that P2P-RPL must always be used simply because the pr= oblems it solves are not significant in all scenarios or application domain= s. But, where it makes sense, P2P-RPL can certainly be used. P2P-RPL is cur= rently aiming for Experimental status. As more experience is gained with it= s operation, it will go for Standards Track status. Again, such a Std. Track document may be published in several years, but until then, commercial deployments of RPL routers will be based on current specifications. > > Thanks > Mukul > > Section 4: Requirement Of DODAG Root > -------------------------------------- > > "RPL Routers provisioned with resources to act as DODAG Roots, and > =A0 administratively configured to act as such, represent a single point > =A0 of failure in the network. =A0As the memory requirements for the DODA= G > =A0 Root and for other RPL Routers are substantially different, unless > =A0 all RPL Routers are provisioned with resources (memory, energy, ...) > =A0 to act as DODAG Roots, effectively if the designated DODAG Root > =A0 fails, the network fails and RPL is unable to operate. =A0Even if > =A0 electing another RPL Router as temporary DODAG root (e.g., for > =A0 forming a "Floating" DODAG) for providing internal connectivity > =A0 between RPL Routers, this router may not have the necessary resources > =A0 to satisfy this role as (temporary) DODAG Root. > " > > If a deployment uses "RPL + P2P-RPL", the criticism listed above is not v= alid. There is no single point of failure. If the global DAG(s) cannot work= because of the root's failure, the nodes can still discover routes to each= other using P2P-RPL. Nodes do not need extra memory/CPU to run P2P-RPL. See our arguments from previous emails about P2P-RPL (http://www.ietf.org/mail-archive/web/roll/current/msg07005.html). > "Another possible LLN scenario is that only internal point-to-point > =A0 connectivity is sought, and no RPL Router has a more "central" role > =A0 than any other - a self-organizing LLN. =A0Requiring special > =A0 provisioning of a specific "super-node" as DODAG Root is both > =A0 unnecessary and undesirable." > > Such an LLN can just use P2P-RPL. No need for special provisioning for an= y node. See our arguments from previous emails about P2P-RPL (http://www.ietf.org/mail-archive/web/roll/current/msg07005.html). > Section 5: =A0RPL Data Traffic Flows > -------------------------------------- > > " RPL makes a-priori assumptions of data traffic types, and explicitly > =A0 defines three such [I-D.ietf-roll-terminology] traffic types: sensor- > =A0 to-root data traffic (multipoint-to-point) is predominant, root-to- > =A0 sensor data traffic (point-to-multipoint) is rare and sensor-to- > =A0 sensor (point-to-point) data traffic is extremely rare. =A0While not > =A0 specifically called out thus in [RFC6550], the resulting protocol > =A0 design, however, reflects these assumptions in that the mechanism > =A0 constructing multipoint-to-point routes is efficient in terms of > =A0 control traffic generated and state required, point-to-multipoint > =A0 route construction much less so - and point-to-point routes subject > =A0 to potentially significant route stretch (routes going through the > =A0 DODAG Root in non-storing mode) and over-the-wire overhead from using > =A0 source routing (from the DODAG Root to the destination) (see > =A0 Section 7) - or, in case of storing mode, considerable memory > =A0 requirements in all LLN routers inside the network (see Section 7). > " > > P2P-RPL resolves any route stretch issues. See our arguments from previous emails about P2P-RPL (http://www.ietf.org/mail-archive/web/roll/current/msg07005.html). > Note that if the source and destination are far apart, the route stretch = with core RPL is not much (i.e. the along-DAG routes wont be much worse tha= n direct routes) although the constraint to traverse through the root may s= till cause congestion near the root. If source and destination are nearby, = the route stretch with "along global DAG" route could be significant and th= at is where using P2P-RPL makes most sense. > > Also, P2P-RPL supports discovery of both hop-by-hop routes and source rou= tes. A source could choose which one to use for a particular destination. > > "The data traffic characteristics, assumed by RPL, do not represent a > =A0 universal distribution of traffic types in LLNs: > > =A0 o =A0There are scenarios where sensor-to-sensor traffic is a more > =A0 =A0 =A0common occurrence, documented, e.g., in [RFC5867] ("Building > =A0 =A0 =A0Automation Routing Requirements in Low Power and Lossy Network= s"). > > " > > And in such cases, it makes sense to use P2P-RPL with or without core RPL= . > > "For the former, all sensor-to-sensor routes include the DODAG Root, > =A0 possibly causing congestions on the communication medium near the > =A0 DODAG Root, and draining energy from the intermediate RPL Routers on > =A0 an unnecessarily long route. =A0If sensor-to-sensor traffic is common= , > =A0 RPL Routers near the DODAG Root will be particularly solicited as > =A0 relays, especially in non-storing mode. > " > > Use P2P-RPL. See our arguments from previous emails about P2P-RPL (http://www.ietf.org/mail-archive/web/roll/current/msg07005.html). > Section 6: =A0Fragmentation Of RPL Control Messages And Data Packet > ---------------------------------------------------------------- > " While 79 octets > =A0 may seem to be sufficient to carry RPL control messages, consider the > =A0 following: RPL control messages are carried in ICMPv6, and the > =A0 mandatory ICMPv6 header consumes 4 octets. =A0The DIO base another 24 > =A0 octets. =A0If link metrics are used, that consumes at least another 8 > =A0 octets - and this is using a hop count metric; other metrics may > =A0 require more. =A0The DODAG Configuration Object consumes up to a > =A0 further 16 octets, for a total of 52 octets. =A0Adding a Prefix > =A0 Information Object for address configuration consumes another 32 > =A0 octets, for a total of 84 octets - thus exceeding the 79 octets > =A0 available for L3 data payload and causing link-layer fragmentation of > =A0 such a DIO. " > > It is certainly possible for a DIO to exceed 79 bytes. But, it is not the= case that a DIO would always fragment. Likely not, but several of these options need to be frequently included (such as link metric options, and DODAG Configuration options + Prefix Information options for use in dynamic topologies where new routers may join the RPL instance). More importantly, fragmentation on the data layer is the bigger issue, since that is out of control of the routing protocol, and may lead to loss of data packets. > DODAG Configuration Option is an "option" and so is the Prefix Informatio= n Option. Every DIO need not carry these options (or others defined in Sect= ion 6.7 of RPL RFC). > > That being said, possible fragmentation of DIOs is a real issue. When des= igning a packet format, one always has to struggle to achieve a balance bet= ween the need to save space and the need to be modular - two conflicting go= als. Pascal called the P2P Route Discovery Option (P2P-RDO, defined in P2P-= RPL) a "garbage can option" because it includes all the information P2P-RPL= route discovery needs (besides what is carried in the configuration option= , the metric containers and the DIO base object). We designed P2P-RDO think= ing that the need to save space is more critical. Various options defined i= n RPL RFC were designed giving more importance to the need for modularity. = I dont think this is necessarily a bad thing as draft-clausen alleges. We did not allege that this "is a bad thing", we simply made an observation that control and data packets may be fragmented when using RPL. > While many RPL deployments will use IEEE 802.15.4 as the link layer in ne= ar future, this may not always be the case. The correct solution to the pro= blem of fragmentation in 802.15.4 LLNs is to devise a compression mechanism= at 6lowpan level. Some > =A0thing similar to draft-bormann-6lowpan-ghc-04 or the RPL-specific comp= ression scheme we proposed (draft-goyal-roll-rpl-compression but now workin= g at 6lowpan layer). We don't know how 6lowpan compression could alleviate the fragmentation issues we observe in draft-clausen-lln-rpl-experiences. We already consider compressed addresses in our draft. As discussed at the IETF when draft-goyal-roll-rpl-compression was presented, it was noted that such a mechanism would lead to non-interoperable implementations of RPL. Since there are already commercial RPL routers out in the market, we believe that is not a good proposal. > > "As a point of reference, the ContikiRPL [rpl-contiki] > =A0 implementation includes both the DODAG Configuration option and the > =A0 Prefix Information option in all DIO messages. =A0Any other options, > =A0 e.g., Route Information options indicating prefixes reachable through > =A0 the DODAG Root, increase the overhead and thus the probability of > =A0 fragmentation. > " > > OK, so a particular implementation always includes config and PI options = in all DIOs. That sounds like a problem this particular implementation has = created for itself. True, but there are no clear guidelines in the RPL specification how to do better (see also section 12 of our draft). Considering that ContikiRPL is one of the most wide-spread open-source implementations of RPL, it may be an indication that implementers may do bad choices based on reading the specification. > > "Given the minimal packet size of LLNs, the routing protocol must > =A0 impose low (or no) overhead on data packets, hopefully independently > =A0 of the number of hops [RFC4919]. =A0However, source-routing not only > =A0 causes increased overhead in the IP header, but also leads to a > =A0 variable available payload for data (depending on how long the source > =A0 route is)." > > Again, this is not a simple one-sided issue. Yes, source routes eat preci= ous bytes in the data packets. But, in many constrained environments (e.g. = in some home automation deployments), only source routing is possible becau= se devices are hard pressed for memory and cannot maintain any routing stat= e. But still, the problems we describe for source routes may occur. > "In point-to-point communication and when non-storing mode > =A0 is used for downward traffic, the source of a data packet will be > =A0 unaware of how many octets will be available for payload (without > =A0 incurring L2.5 fragmentation) when the DODAG Root relays the data > =A0 packet and add the source routing header. =A0Thus, the source may > =A0 choose an inefficient size for the data payload: if the data payload > =A0 is large, it may exceed the link-layer MTU at the DODAG Root after > =A0 adding the source-routing header; on the other hand, if the data > =A0 payload is low, the network resources are not used efficiently, which > =A0 introduces more overhead and more frame transmissions. > > " > > This is a good point to make. Note that this problem is not present when = the source (rather than the DAG root) itself includes the source route in t= he packet. So, this problem goes away when using P2P-RPL. See our arguments from previous emails about P2P-RPL (http://www.ietf.org/mail-archive/web/roll/current/msg07005.html). > > Section 7: The DAO Mechanism: Downward and Point-to-Point Routes > --------------------------------------------------------------- > > "RPL specifies two distinct and incompatible "modes of operation" for > =A0 downward traffic: storing mode, where each RPL Router is assumed to > =A0 maintain routes to all destinations in its sub-DODAG, i.e., RPL > =A0 Routers that are "deeper down" in the DODAG, and non-storing mode, > =A0 where only the DODAG Root stores routes to destinations inside the > =A0 LLN, and where the DODAG Root employs strict source routing in order > =A0 to route data traffic to the destination RPL Router. > " > > The above description of storing mode is incorrect. It is not the case th= at, in storing mode, each RPL Router maintains routes to all destinations i= n its sub-DODAG. The child decides which of its parents would receive a DAO= . Further, for each advertized destination, the origin (of the advertisemen= t) decides (via path control bits) how many separate routes could exist for= this destination. Yes, but still each child has to be advertised by at least one DAO parent (and therefore all children and grandchildren etc. are stored on DAO parents). The Path Control bits may be used to select more than one parallel path to a target, which would even increase the state requirements. > > Section 7.1: > > "In case a destination is > =A0 unreachable, all the DODAG Root may do is require all destinations to > =A0 re-issue their DAOs, by way of issuing a DIO with an increased DODAG > =A0 version number, possibly provoking a broadcast-storm-like situation. > " > > This problem is easily fixable by a simple DAO solicitation mechanism: ro= ot includes a solicitation in its DIO, routers in the DAG propagate the sol= icitation further in their DIOs and when the desired destination receives t= he solicitation, it sends the DAO to the root. Pascal has often talked abou= t writing up this fix. Something like this may be an option, but it is not part of the RPL specification, which is exactly what our draft observes. > > "A final point on the DAO mechanism: RPL supports point-to-point > =A0 traffic only by way of relaying through the DODAG. =A0In networks whe= re > =A0 point-to-point traffic is no rare occurrence, this causes unduly long > =A0 routes (with possibly increased energy consumption, increased > =A0 probability of packet losses) as well as possibly congestion around > =A0 the DODAG Root. > " > > Use P2P-RPL in such scenarios. See our arguments from previous emails about P2P-RPL (http://www.ietf.org/mail-archive/web/roll/current/msg07005.html). > > Section 8: Address aggregation and summarization > ------------------------------------------------------ > I dont agree with the assertion that address aggregation will break down = completely if a node's DAO parent is not same as the one whose advertized p= refix was used by the node to configure its address. I think DAO parent sel= ection at lower levels wont have too much impact on address aggregation at = nodes at upper level. Sure address aggregation may not be possible at the n= ode's parent or grandparent. But, nodes still higher up will be less and le= ss affected. Yes, if you use a hierarchical aggregation, then this may be true. But, as we observe in our draft, there is no such mechanism specified which guarantees correct topological aggregation in dynamic networks. Moreover, in networks where 6lowpan compressed addresses are used, aggregation may not be possible. > > Also, there might be factual inaccuracy in the text below. > > " Any aggregated routes require the use of a prefix shorter than /64, > =A0 and subsequent hierarchical assignment of prefixes down to a /64 (as > =A0 any RPL Router itself provides a /64 subnet to any hosts connected to > =A0 the router). > > =A0 Moreover, if the 6lowpan adaption layer [RFC4944] is used in the LLN, > =A0 route aggregation is not possible since the same /64 is applied > =A0 across the entire network." > > I dont think an RPL router has to always advertize a 64 bit prefix to its= hosts. RFC4291 states: "For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format." > Further, with RFC 6282, I am not sure if only /64 prefix could be used fo= r autoconfiguration of 802.15.4 interfaces. Can you precise how autoconfiguration could use other prefix lengths when using RFC6282? Either hosts may be attached to RPL routers, in which case each RPL router needs to be assigned a 64 bit prefix, or 6lowpan compressed addresses are used, in which case I don't know how address aggregation could be done in the network (since all routers use the same prefix in the lowpan). > So, the assertion "Any aggregated routes require the use of a prefix shor= ter than /64" may not be true. > > Section 9: Link assumed bidirectional > ------------------------------------------------- > > "Unidirectional links are no rare occurrence, such as is known from > =A0 wireless multi-hop networks. =A0Preliminary results from a test-bed o= f > =A0 AMI (Automated Metering Infrastructure) devices using 950MHz radio > =A0 interfaces, and with a total of 22 links, show that 36% of these > =A0 links are unidirectional." > > Could the authors provide reference to published literature showing that = a significant fraction of links are unidirectional? The reference to an unp= ublished/unavailable study is not OK. Also, it seems that "950MHz" is a typ= o. Experience from many years in MANETs have told us that links tend to be highly asymmetric to the point of being unidirectional. Do you have a different experience? Why is 950MHz a typo? Best regards Ulrich and Jiazi > > ----- Original Message ----- > From: "Philip Levis" > To: "Thomas Heide Clausen" > Cc: "roll WG" , "Michael Richardson" > Sent: Thursday, May 17, 2012 12:02:32 AM > Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences > > > On May 16, 2012, at 10:11 AM, Thomas Heide Clausen wrote: > >> >> >> For example: >> >> =A0 =A0 =A0 o =A0 =A0 =A0 the state required for storing/non-storing mod= e does *not* depend on a >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 specific implementation and deployment, but = is an artifact from the RPL design. >> >> =A0 =A0 =A0 o =A0 =A0 =A0 the message-size of RPL is not dependent on a = specific implementation and deployment, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 but is an artifact from the RPL design. >> >> =A0 =A0 =A0 o =A0 =A0 =A0 the use of links "upwards" based on receipt of= traffic "downwards" (i.e. the unidirectional >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 link issue) is not dependent on a specific i= mplementation and deployment, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 but is an artifact from the RPL design. >> >> =A0 =A0 =A0 o =A0 =A0 =A0 the unknown-by-source MTU issues for data-traf= fic when using non-storing mode >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 is not dependent on a specific implementatio= n and deployment, >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 but is an artifact from the RPL design. >> >> I could go on, but then it'd be easier to just paste the whole I-D into = this email. > > > Thomas, > > I agree that some points in the ID are valid statements about the protoco= l itself, such as message sizes and the issues caused by floating DODAGs. T= hose, to me, seem like reasonable points to make. > > However, some of the points are hypotheses about performance (14), a bit = naive about how wireless networks behave (13) or somewhat snippy gripes (11= , 12). In my opinion, a document which focused on factual statements of the= protocol design not really open to interpretation and cut hypothetical or = subjective statements might be ready for the working group to consider. > > As just a start, I object to 10, 11, 12, 13, and 14 being considered inhe= rent to the protocol. > > 10 assumes that a node only uses DIO reception to allow a parent; the spe= cification is pretty clear that you should check the parent is usable (sect= ion 1.1). You're taking a bad implementation decision and assuming there is= n't another way to do things. > > For 11, there are implementations of RPL smaller than 50kB; they do not i= mplement every feature, but that was kind of the point of the protocol, tha= t it could be implemented on a sliding scale of implementation complexity. = The TinyOS implementation, for example, is, I believe, ~20kB, less than hal= f the size. You don't report what architecture the 50kB is for, clearly it = would be more for a 32-bit than a 16-bit architecture. > > For 12, "implementations may exhibit a bad performance if not carefully i= mplemented." =A0I think it is safe to say this is true for almost ANY proto= col. A specification is not intended to be a complete statement of efficien= t implementation, otherwise you give little latitude to future improvements= and good engineering. > > For 13, this assumes that a wireless network has a stable topology which = the protocol can converge to. Wireless networks are often NOT stable: one c= annot expect a protocol to converge on a dynamic graph. > > 14 is similarly confused about what a wireless network looks like. How ca= n the state of a distributed system based on a dynamic topology be "consist= ent?" I think this is a fundamental misunderstanding of how the network wor= ks. > > That being said, I think point 6 is well taken and should be considered, = maybe others. Maybe the constructive way to take this document, if you don'= t want to take the step of specifying solutions, is at least casting it as = a roadmap for ways in which you think the WG should improve RPL? > > 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 jreddy@ti.com Sun Jun 3 21:29:54 2012 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 CC14B21F87A1 for ; Sun, 3 Jun 2012 21:29:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0shwP05EGaqJ for ; Sun, 3 Jun 2012 21:29:54 -0700 (PDT) Received: from arroyo.ext.ti.com (arroyo.ext.ti.com [192.94.94.40]) by ietfa.amsl.com (Postfix) with ESMTP id EF19021F879C for ; Sun, 3 Jun 2012 21:29:53 -0700 (PDT) Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by arroyo.ext.ti.com (8.13.7/8.13.7) with ESMTP id q544Tqlg007661; Sun, 3 Jun 2012 23:29:52 -0500 Received: from DFLE70.ent.ti.com (dfle70.ent.ti.com [128.247.5.40]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id q544Tql7020304; Sun, 3 Jun 2012 23:29:52 -0500 Received: from DLEE10.ent.ti.com ([fe80::843:a4aa:bf01:3f68]) by DFLE70.ent.ti.com ([fe80::db3:609a:aa62:e1ec%22]) with mapi id 14.01.0323.003; Sun, 3 Jun 2012 23:29:53 -0500 From: "Reddy, Joseph" To: Mukul Goyal , "roll@ietf.org" , "Jakob Buron (Jakob_Buron@sigmadesigns.com)" Thread-Topic: P2P-RPL: Data-Option in P2P-DIO Thread-Index: AQHNQTf+HlDbzHR71UaFCzCJbquvvpbpkbLA Date: Mon, 4 Jun 2012 04:29:51 +0000 Message-ID: <2AA5AC69E924D149A8D63EB676AF87DB2CA3BB37@DLEE10.ent.ti.com> References: <6CD8B4189A89EB4FB816FA9827F6F65F0ABCD132@cph-ex1> <1105562878.579687.1338693679499.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <1105562878.579687.1338693679499.JavaMail.root@mail17.pantherlink.uwm.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.170.170.90] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [Roll] P2P-RPL: Data-Option in P2P-DIO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 04:29:55 -0000 DQpIaSBKYWtvYiwNCg0KSWYgd2UgYWdyZWUgdG8gIHJlbW92ZSB0aGUgc2VxdWVuY2UgbnVtYmVy cyBmcm9tIHRoZSBkYXRhIG9wdGlvbiAoIGFuZCwgY29uc2VxdWVudGx5LCByZXF1aXJlIHRoYXQg dGhlIE9yaWdpbiBtdXN0IG5vdCBtb2RpZnkgdGhlIGRhdGEtb3B0aW9uIGR1cmluZyBhIHRyYW5z bWlzc2lvbiApLCB0aGF0IHdvdWxkIGJlIGFjY2VwdGFibGUgdG8gbWUuDQoNCi1SZWdhcmRzLCBK b3NlcGgNCg0KDQotLS0tLSBGb3J3YXJkZWQgTWVzc2FnZSAtLS0tLQ0KRnJvbTogIkpha29iIEJ1 cm9uIiA8SmFrb2JfQnVyb25Ac2lnbWFkZXNpZ25zLmNvbT4NClRvOiAiSm9zZXBoJyAnUmVkZHki IDxqcmVkZHlAdGkuY29tPiwgIk11a3VsIEdveWFsIiA8bXVrdWxAdXdtLmVkdT4NCkNjOiByb2xs QGlldGYub3JnDQpTZW50OiBUdWVzZGF5LCBNYXkgMjksIDIwMTIgODoyNDowMyBBTQ0KU3ViamVj dDogUkU6IFAyUC1SUEw6IERhdGEtT3B0aW9uIGluIFAyUC1ESU8NCg0KSGksIHBsZWFzZSBzZWUg bXkgY29tbWVudHMgaW5saW5lLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZ10g T24gQmVoYWxmIA0KPiBPZiBSZWRkeSwgSm9zZXBoDQo+IFNlbnQ6IEZyaWRheSwgTWF5IDI1LCAy MDEyIDExOjA4IFBNDQo+IFRvOiBNdWt1bCBHb3lhbA0KPiBDYzogcm9sbEBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW1JvbGxdIFAyUC1SUEw6IERhdGEtT3B0aW9uIGluIFAyUC1ESU8NCj4gDQo+ IEhpIE11a3VsLA0KPiANCj4gU2VlIHJlc3BvbnNlIGJlbG93Li4uDQo+IA0KPiAtUmVnYXJkcywg Sm9zZXBoDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiANCj4gW0pvc2VwaF0N Cj4gU2VjdGlvbiA5LjQNCj4gQnVsbGV0IDE6DQo+IFVuZGVyIHdoYXQgY29uZGl0aW9ucyB3b3Vs ZCBhIHJvdXRlciByZWNlaXZlIHRoZSBzYW1lIERJTyBhbmQgYSBEYXRhLSANCj4gT3B0aW9uIHdp dGggaGlnaGVyIHNlcXVlbmNlIG51bWJlcj8gSSBhc3N1bWUgdGhhdCBvbmx5IHRoZSBPcmlnaW5h dG9yIA0KPiBjYW4gaW5jbHVkZSBhIERhdGEtT3B0aW9uID8gU2FtZSBxdWVzdGlvbiBhbHNvIGFy aXNlcyBmb3Igc2VjdGlvbiA5LjUgDQo+ICggcGFyYQ0KPiAxICkNCj4gDQo+IFtNdWt1bF0NCj4g WWVzLCBvbmx5IHRoZSBvcmlnaW4gY2FuIGluY2x1ZGUgYSBkYXRhIG9wdGlvbiBmb3IgZGVsaXZl cnkgdG8gdGhlIA0KPiB0YXJnZXQocykuIEluIHRoZW9yeSwgdGhlIG9yaWdpbiBtaWdodCBoYXZl IG5ld2VyIGRhdGEgdG8gY29udmV5IHRvIA0KPiB0aGUNCj4gdGFyZ2V0KHMpIHdoaWxlIHRoZSBy b3V0ZSBkaXNjb3ZlcnkgaXMgc3RpbGwgZ29pbmcgb24uIFNlcXVlbmNlIA0KPiBudW1iZXJzIGFj Y291bnRzIGZvciB0aGF0IHBvc3NpYmlsaXR5LiBOb3RlIHRoYXQgRGF0YSBvcHRpb24gZGlkIG5v dCANCj4gaGF2ZSBhIHNlcXVlbmNlIG51bWJlciBlYXJsaWVyIChiZWZvcmUgdGhlIGZpcnN0IExD KS4gVGhlbiwgUGFzY2FsIA0KPiByYWlzZWQgdGhlIHBvc3NpYmlsaXR5IHdoYXQgaWYgb3JpZ2lu IGNoYW5nZXMgdGhlIGRhdGEgb3B0aW9uLiBIb3cgDQo+IHdvdWxkIGludGVybWVkaWF0ZSByb3V0 ZXJzIGFuZCB0YXJnZXQga25vdyB0aGF0IHRoaXMgaXMgdGhlIG5ld2VyIA0KPiBkYXRhPyBIZW5j ZSwgd2UgaW50cm9kdWNlZCB0aGUgc2VxdWVuY2UgbnVtYmVyLg0KPiANCj4gW0pvc2VwaF0NCj4g SSBkb27igJl0IHRoaW5rIHRoZSBPcmlnaW4gc2hvdWxkIGFibGUgdG8gdGhpcy4gSW4gZmFjdCwg dGhlIE9yaWdpbiBtdXN0IA0KPiBub3QgbWFrZSBhbnkgY2hhbmdlcyB0byB0aGUgY29udGVudHMg b2YgdGhlIERJTyBhbmQgcmV0cmFuc21pdCBpdCANCj4gd2l0aG91dCB1cGRhdGluZyB0aGUgdmVy c2lvbiBudW1iZXIuIElmIHRoZSBPcmlnaW4gd2FudHMgdG8gc2VuZCBkYXRhLCANCj4gaXQgc2hv dWxkIHNpbXBseSB3YWl0IHVudGlsIHRoZSBwMnAgcm91dGUgaXMgc2V0dXAgYW5kIHRoZW4gdXNl IGl0Lg0KPiANCj4gVGhlIHdob2xlIGlkZWEgb2Ygc2VuZGluZyBVRFAgRGF0YSBtZXNzYWdlcyBp biB0aGUgSUNNUCBtZXNzYWdlIA0KPiBwYXlsb2FkIGl0c2VsZiBkb2VzbuKAmXQgc2VlbSBxdWl0 ZSByaWdodC4gSXQgaXMgYWxzbyBub3Qgc2ltcGxlIGZyb20gYW4gDQo+IGltcGxlbWVudGF0aW9u IHBlcnNwZWN0aXZlIHRvIG1ha2UgdGhpcyBraW5kIG9mIGNyb3NzIGxheWVyIGludGVyYWN0aW9u cy4NCj4gDQpbSmFrb2JdDQpJIHVuZGVyc3RhbmQgdGhlIGNvbmNlcm4gYWJvdXQgdGhlIERhdGEg T3B0aW9uIGFuZCBjcm9zcy1sYXllciBpbnRlcmFjdGlvbnMuIEkgYWxzbyBiZWxpZXZlIHRoYXQg aXQgaXMgYSBzZW5zaWJsZSBhbmQgbmVjZXNzYXJ5IGRlc2lnbiBjaG9pY2UgZm9yIGhvbWUgYXV0 b21hdGlvbiBuZXR3b3Jrcy4gSG9tZSBhdXRvbWF0aW9uIGZyZXF1ZW50bHkgcmVxdWlyZXMgbG93 LWxhdGVuY3kgbWVzc2FnZXMgdG8gYmUgZGVsaXZlcmVkIHRvIHRhcmdldHMgZm9yIHdoaWNoIHRo ZSBvcmlnaW5hdG9yIGhhcyBubyByb3V0ZS4gQW4gZXhhbXBsZSBpcyBhIHJlbW90ZSBsaWdodCBz d2l0Y2ggdGhhdCBuZWVkcyB0byBjb250cm9sIGEgcmVsb2NhdGVkIGxhbXAuIFRoZSBmYXN0ZXN0 IHdheSB0byBkbyB0aGF0IGluIGEgcmVhY3RpdmUgcm91dGluZyBzY2hlbWUgaXMgdG8gcGlnZ3li YWNrIHRoZSBkYXRhIG9uIHRoZSByb3V0aW5nIHBhY2tldHMuIFRoZSBvdGhlciBvcHRpb24gd291 bGQgYmUgdG8gdXNlIHNpbXBsZSBmbG9vZGluZywgd2l0aCBubyB0cmlja2xlIGNvbnRyb2wsIHdo aWNoIHdvdWxkIGludm9sdmUgZ2VuZXJhdGluZyBhIGh1Z2UgbnVtYmVyIG9mIHBhY2tldHMuIFBp Z2d5YmFja2luZyBkYXRhIG9uIHJvdXRpbmcgcGFja2V0cyBoZWxwcyBhdm9pZCBnZW5lcmF0aW5n IGV4dHJhIHBhY2tldHMuDQoNCkhvbWUgYXV0b21hdGlvbiBuZXR3b3JrcyBkbyBub3QgbmVlZCB0 byB1cGRhdGUgdGhlIERhdGEgT3B0aW9uIHdoaWxlIGEgZGlzY292ZXJ5IGlzIGluIHByb2dyZXNz LiBJIGFtIG9rYXkgd2l0aCByZW1vdmluZyB0aGUgc2VxdWVuY2UgbnVtYmVycyBpZiB0aGV5IGFk ZCB0b28gbXVjaCBjb21wbGV4aXR5Lg0KDQpCZXN0IHJlZ2FyZHMsDQpKYWtvYg0KPiANCj4gDQo+ IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4gUm9sbEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== From jreddy@ti.com Sun Jun 3 21:50:29 2012 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 032B321F888B for ; Sun, 3 Jun 2012 21:50:27 -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=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 787o2WttaHSW for ; Sun, 3 Jun 2012 21:50:25 -0700 (PDT) Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by ietfa.amsl.com (Postfix) with ESMTP id AB52721F887E for ; Sun, 3 Jun 2012 21:50:24 -0700 (PDT) Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id q544oNeW008398; Sun, 3 Jun 2012 23:50:23 -0500 Received: from DFLE71.ent.ti.com (dfle71.ent.ti.com [128.247.5.62]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id q544oNF1002280; Sun, 3 Jun 2012 23:50:23 -0500 Received: from DLEE10.ent.ti.com ([fe80::843:a4aa:bf01:3f68]) by DFLE71.ent.ti.com ([fe80::29f6:72ad:a62e:2025%21]) with mapi id 14.01.0323.003; Sun, 3 Jun 2012 23:50:23 -0500 From: "Reddy, Joseph" To: Mukul Goyal Thread-Topic: [Roll] P2P-RPL: RIO/PIO in P2P-DIO Thread-Index: Ac06uOwwX3Y4CbuVTFqlKGFRgCOm/gAL/lAAAZ4ItYAAKq1a8A== Date: Mon, 4 Jun 2012 04:50:22 +0000 Message-ID: <2AA5AC69E924D149A8D63EB676AF87DB2CA3BB8C@DLEE10.ent.ti.com> References: <1339758364.520004.1337982022814.JavaMail.root@mail17.pantherlink.uwm.edu> <1462746375.579679.1338693327373.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <1462746375.579679.1338693327373.JavaMail.root@mail17.pantherlink.uwm.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.170.170.90] Content-Type: multipart/alternative; boundary="_000_2AA5AC69E924D149A8D63EB676AF87DB2CA3BB8CDLEE10entticom_" MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] P2P-RPL: RIO/PIO in P2P-DIO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 04:50:29 -0000 --_000_2AA5AC69E924D149A8D63EB676AF87DB2CA3BB8CDLEE10entticom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQoNCkhpIE11a3VsLA0KDQpUaGFua3MgZm9yIHRoZSBjbGFyaWZpY2F0aW9uLiBGb3IgdGhlIFBJ TyBmbGFncywgSSB0aGluayB0aGUgc2V0dGluZ3MgbXVzdCBub3QgY29udHJhZGljdCB0aGUgUlBM IHNwZWMuIFNvICBJIHdvdWxkIGFkZCB0aGUgc2FtZSByZXN0cmljdGlvbnMgaGVyZSAoIGkuZS4g TCBiaXQgbXVzdCBub3QgYmUgc2V0ICkuDQoNCi1SZWdhcmRzLCBKb3NlcGgNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCg0KRnJvbTogIk11a3VsIEdveWFsIiA8bXVrdWxAdXdt LmVkdTxtYWlsdG86bXVrdWxAdXdtLmVkdT4+DQpUbzogIkpvc2VwaCBSZWRkeSIgPGpyZWRkeUB0 aS5jb208bWFpbHRvOmpyZWRkeUB0aS5jb20+Pg0KQ2M6IHJvbGxAaWV0Zi5vcmc8bWFpbHRvOnJv bGxAaWV0Zi5vcmc+DQpTZW50OiBGcmlkYXksIE1heSAyNSwgMjAxMiA0OjQwOjIyIFBNDQpTdWJq ZWN0OiBSZTogW1JvbGxdIFAyUC1SUEw6IFJJTy9QSU8gaW4gUDJQLURJTw0KDQpIaSBKb3NlcGgN Cg0KUGxlYXNlIHNlZSBpbmxpbmUuDQoNClRoYW5rcw0KTXVrdWwNCg0KW0pvc2VwaDFdDQpTZWN0 aW9uIDYuMToNCiIuLi5BIFAyUC1ESU8gTUFZIGNhcnJ5IG9uZSBvciBtb3JlIFJJTyBhbmQgUElP IG9wdGlvbnMuLi4iDQpJIGFtIG5vdCBzdXJlIGhvdyB0aGVzZSBvcHRpb25zIHNob3VsZCBiZSB1 c2VkIGJ5IHRoZSBEQUcgbWVtYmVycy4gTGF0ZXIgb24sIGluIDkuMSwgaXQgc2F5cyB0aGF0ICIu LnRoZSB0ZW1wb3JhcnkgREFHIG11c3Qgbm90IGJlIHVzZWQgdG8gcm91dGUgcGFja2V0cy4uLi4i LiBTbyB3aGF0IGlzIHRoZSBwdXJwb3NlIG9mIFJJTyBhbmQgYWxzbyBQSU8gPw0KDQpbTXVrdWwx XQ0KVGhlIFJJTyB3b3VsZCBhZHZlcnRpemUgdG8gdGhlIHRhcmdldChzKSB0aGUgb3JpZ2luJ3Mg Y29ubmVjdGl2aXR5IHRvIHRoZSBzcGVjaWZpZWQgcHJlZml4LiBSZWdhcmRpbmcgUElPLCBJIHdv dWxkIHZlcnkgbXVjaCBsaWtlIHRvIGFsbG93IFAyUCBtb2RlIERJT3MgdG8gY2FycnkgUElPcyB0 byBwcm9wYWdhdGUgcHJlZml4ZXMgZm9yIGFkZHJlc3Mgc2VsZmNvbmZpZ3VyYXRpb24gKGkuZS4g aGF2ZSBBIGZsYWcgc2V0KS4gSSB0aGluayB3ZSBjb3VsZCBmb3JiaWQgc2V0dGluZyB0aGUgUiBm bGFnIHRvIG9uZSBpbiBhIFBJTyBjYXJyaWVkIGluIGEgUDJQIG1vZGUgRElPcy4gUmVnYXJkaW5n IHRoZSBMIGZsYWcsIEkgdGhpbmsgd2UgY291bGQgYWxsb3cgYSBQMlAgbW9kZSBESU8gdG8gY2Fy cnkgYSBQSU8gd2l0aCBMIGZsYWcgc2V0IHN1YmplY3QgdG8gdGhlIGZvbGxvd2luZyBydWxlcyBp biBSRkMgNjU1MDoNCjwuLi4+DQoNCltKb3NlcGgyXQ0KVGhlIFJJTy9QSU8gaW5mb3JtYXRpb24g aXMgc2VudCBieSB0aGUgT3JpZ2luIHRvIHByb3BhZ2F0ZSBpdHMgY29ubmVjdGl2aXR5IGFuZCBw cmVmaXggaW5mb3JtYXRpb24uIEhvd2V2ZXIsIHRoZSByb3V0ZSBpcyBlc3RhYmxpc2hlZCB0b3dh cmRzIHRoZSBUYXJnZXQuIFNvIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSB0aGUgT3JpZ2luIGlu Zm9ybWF0aW9uIGlzIHJlbGV2YW50IC4uDQoNCltNdWt1bDJdDQoNCkhlcmUgaXMgc29tZSByZWxl dmFudCB0ZXh0IGZyb20gU2VjdGlvbiA5LjM6DQoNCiJBIHJvdXRlciBTSE9VTEQgZGlzY2FyZCBh IHJlY2VpdmVkIFAyUCBtb2RlIERJTyB3aXRoIG5vIGZ1cnRoZXINCiAgIHByb2Nlc3NpbmcgaWYg aXQgZG9lcyBub3QgaGF2ZSBiaWRpcmVjdGlvbmFsIHJlYWNoYWJpbGl0eSB3aXRoIHRoZQ0KICAg bmVpZ2hib3IgdGhhdCBnZW5lcmF0ZWQgdGhlIHJlY2VpdmVkIERJTy4gIE5vdGUgdGhhdCBiaWRp cmVjdGlvbmFsDQogICByZWFjaGFiaWxpdHkgZG9lcyBub3QgbWVhbiB0aGF0IHRoZSBsaW5rIG11 c3QgaGF2ZSB0aGUgc2FtZSB2YWx1ZXMNCiAgIGZvciBhIHJvdXRpbmcgbWV0cmljIGluIGJvdGgg ZGlyZWN0aW9ucy4gIEEgcm91dGVyIFNIT1VMRCBjYWxjdWxhdGUNCiAgIHRoZSB2YWx1ZXMgb2Yg dGhlIGxpbmstbGV2ZWwgcm91dGluZyBtZXRyaWNzIGluY2x1ZGVkIGluIHRoZSByZWNlaXZlZA0K ICAgRElPIHRha2luZyBpbiBhY2NvdW50IHRoZSBtZXRyaWMncyB2YWx1ZSBpbiBib3RoIGZvcndh cmQgYW5kIEJhY2t3YXJkDQogICBkaXJlY3Rpb25zLiAgQmlkaXJlY3Rpb25hbCByZWFjaGFiaWxp dHkgYWxvbmcgYSBkaXNjb3ZlcmVkIHJvdXRlDQogICBhbGxvd3MgdGhlIFRhcmdldCB0byB1c2Ug dGhpcyByb3V0ZSB0byByZWFjaCB0aGUgT3JpZ2luLiAgSW4NCiAgIHBhcnRpY3VsYXIsIHRoZSBE Uk8gbWVzc2FnZXMgdHJhdmVsIGZyb20gdGhlIFRhcmdldCB0byB0aGUgT3JpZ2luDQogICBhbG9u ZyBhIGRpc2NvdmVyZWQgcm91dGUuDQoiDQoNClNvLCB0aGUgdGFyZ2V0IGNhbiBjZXJ0YWlubHkg dXNlIGEgZGlzY292ZXJlZCByb3V0ZSBhcyBhIHNvdXJjZSByb3V0ZSB0byByZWFjaCB0aGUgb3Jp Z2luLiBUaGUgYmFja3dhcmQgZGlyZWN0aW9uIHJvdXRlIG1heSBub3QgbWVldCBkZXNpcmVkIHJv dXRpbmcgY29uc3RyYWludHMgYnV0IGRvZXMgcHJvdmlkZSBhIHdheSB0byByZWFjaCB0aGUgb3Jp Z2luLiBTbywgaXQgbWF5IGJlIHVzZWZ1bCBmb3IgdGhlIHRhcmdldCB0byBrbm93IHdoYXQgZGVz dGluYXRpb24gcHJlZml4ZXMgY2FuIGJlIHJlYWNoZWQgdmlhIHRoZSBvcmlnaW4uIEluIGZhY3Qs IGl0IG1ha2VzIHNlbnNlIHRvIGFsbG93IHRoZSB0YXJnZXQgdG8gaW5jbHVkZSBvbmUgb3IgbW9y ZSAgUklPcyBpbiBpdHMgRFJPIHRvIGxldCBvcmlnaW4ga25vdyB3aGF0IGRlc3RpbmF0aW9uIHBy ZWZpeGVzIGNvdWxkIGJlIHJlYWNoZWQgdmlhIHRoZSB0YXJnZXQuDQoNClJlZ2FyZGluZyB0aGUg UElPLCBJIHRoaW5rIHRoZSBtb3N0IGNyaXRpY2FsIG5lZWQgaXMgdG8gYWxsb3cgdGhlIHByb3Bh Z2F0aW9uIG9mIGFkZHJlc3Mgc2VsZi1jb25maWd1cmF0aW9uIHByZWZpeGVzIHZpYSBQMlAgbW9k ZSBESU9zLiBUaGVzZSBwcmVmaXhlcyBjYW4gYmUgdXNlZCBub3Qgb25seSBieSB0aGUgdGFyZ2V0 IGJ1dCBhbHNvIHRoZSBvdGhlciBub2RlcyB0aGF0IGpvaW4gdGhlIHRlbXBvcmFyeSBEQUcuIEkg YW0gbm90IHRvbyBzdXJlIGFib3V0IGFsbG93aW5nIFBJT3Mgd2l0aCBMIGZsYWcgc2V0IGluc2lk ZSB0aGUgUDJQIG1vZGUgRElPcy4gV291bGQgY2VydGFpbmx5IGxpa2UgdG8gaGVhciB5b3VyIHZp ZXdzIG9uIHRoaXMuDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmc8bWFpbHRvOlJvbGxA aWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== --_000_2AA5AC69E924D149A8D63EB676AF87DB2CA3BB8CDLEE10entticom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6 ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGkgTXVrdWwsPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhhbmtzIGZvciB0aGUgY2xhcmlm aWNhdGlvbi4gRm9yIHRoZSBQSU8gZmxhZ3MsIEkgdGhpbmsgdGhlIHNldHRpbmdzIG11c3Qgbm90 IGNvbnRyYWRpY3QgdGhlIFJQTCBzcGVjLiBTbyAmbmJzcDtJIHdvdWxkIGFkZCB0aGUgc2FtZSBy ZXN0cmljdGlvbnMgaGVyZQ0KICggaS5lLiBMIGJpdCBtdXN0IG5vdCBiZSBzZXQgKS48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4tUmVnYXJkcywgSm9zZXBoPG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdiBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0iY2VudGVyIiBz dHlsZT0idGV4dC1hbGlnbjpjZW50ZXIiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+DQo8aHIg c2l6ZT0iMiIgd2lkdGg9IjEwMCUiIGFsaWduPSJjZW50ZXIiIGlkPSJ6d2NociI+DQo8L3NwYW4+ PC9kaXY+DQo8cD48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4NCkZyb206ICZxdW90O011 a3VsIEdveWFsJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bXVrdWxAdXdtLmVkdSI+bXVrdWxA dXdtLmVkdTwvYT4mZ3Q7PGJyPg0KVG86ICZxdW90O0pvc2VwaCBSZWRkeSZxdW90OyAmbHQ7PGEg aHJlZj0ibWFpbHRvOmpyZWRkeUB0aS5jb20iPmpyZWRkeUB0aS5jb208L2E+Jmd0Ozxicj4NCkNj OiA8YSBocmVmPSJtYWlsdG86cm9sbEBpZXRmLm9yZyI+cm9sbEBpZXRmLm9yZzwvYT48YnI+DQpT ZW50OiBGcmlkYXksIE1heSAyNSwgMjAxMiA0OjQwOjIyIFBNPGJyPg0KU3ViamVjdDogUmU6IFtS b2xsXSBQMlAtUlBMOiBSSU8vUElPIGluIFAyUC1ESU88YnI+DQo8YnI+DQpIaSBKb3NlcGg8YnI+ DQo8YnI+DQpQbGVhc2Ugc2VlIGlubGluZS48YnI+DQo8YnI+DQpUaGFua3M8YnI+DQpNdWt1bDxi cj4NCjxicj4NCltKb3NlcGgxXTxicj4NClNlY3Rpb24gNi4xOjxicj4NCiZxdW90Oy4uLkEgUDJQ LURJTyBNQVkgY2Fycnkgb25lIG9yIG1vcmUgUklPIGFuZCBQSU8gb3B0aW9ucy4uLiZxdW90Ozxi cj4NCkkgYW0gbm90IHN1cmUgaG93IHRoZXNlIG9wdGlvbnMgc2hvdWxkIGJlIHVzZWQgYnkgdGhl IERBRyBtZW1iZXJzLiBMYXRlciBvbiwgaW4gOS4xLCBpdCBzYXlzIHRoYXQgJnF1b3Q7Li50aGUg dGVtcG9yYXJ5IERBRyBtdXN0IG5vdCBiZSB1c2VkIHRvIHJvdXRlIHBhY2tldHMuLi4uJnF1b3Q7 LiBTbyB3aGF0IGlzIHRoZSBwdXJwb3NlIG9mIFJJTyBhbmQgYWxzbyBQSU8gPzxicj4NCjxicj4N CltNdWt1bDFdPGJyPg0KVGhlIFJJTyB3b3VsZCBhZHZlcnRpemUgdG8gdGhlIHRhcmdldChzKSB0 aGUgb3JpZ2luJ3MgY29ubmVjdGl2aXR5IHRvIHRoZSBzcGVjaWZpZWQgcHJlZml4LiBSZWdhcmRp bmcgUElPLCBJIHdvdWxkIHZlcnkgbXVjaCBsaWtlIHRvIGFsbG93IFAyUCBtb2RlIERJT3MgdG8g Y2FycnkgUElPcyB0byBwcm9wYWdhdGUgcHJlZml4ZXMgZm9yIGFkZHJlc3Mgc2VsZmNvbmZpZ3Vy YXRpb24gKGkuZS4gaGF2ZSBBIGZsYWcgc2V0KS4gSSB0aGluayB3ZSBjb3VsZA0KIGZvcmJpZCBz ZXR0aW5nIHRoZSBSIGZsYWcgdG8gb25lIGluIGEgUElPIGNhcnJpZWQgaW4gYSBQMlAgbW9kZSBE SU9zLiBSZWdhcmRpbmcgdGhlIEwgZmxhZywgSSB0aGluayB3ZSBjb3VsZCBhbGxvdyBhIFAyUCBt b2RlIERJTyB0byBjYXJyeSBhIFBJTyB3aXRoIEwgZmxhZyBzZXQgc3ViamVjdCB0byB0aGUgZm9s bG93aW5nIHJ1bGVzIGluIFJGQyA2NTUwOjxicj4NCiZsdDsuLi4mZ3Q7PGJyPg0KPGJyPg0KW0pv c2VwaDJdPGJyPg0KVGhlIFJJTy9QSU8gaW5mb3JtYXRpb24gaXMgc2VudCBieSB0aGUgT3JpZ2lu IHRvIHByb3BhZ2F0ZSBpdHMgY29ubmVjdGl2aXR5IGFuZCBwcmVmaXggaW5mb3JtYXRpb24uIEhv d2V2ZXIsIHRoZSByb3V0ZSBpcyBlc3RhYmxpc2hlZCB0b3dhcmRzIHRoZSBUYXJnZXQuIFNvIEkg ZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSB0aGUgT3JpZ2luIGluZm9ybWF0aW9uIGlzIHJlbGV2YW50 IC4uPGJyPg0KPGJyPg0KW011a3VsMl08YnI+DQo8YnI+DQpIZXJlIGlzIHNvbWUgcmVsZXZhbnQg dGV4dCBmcm9tIFNlY3Rpb24gOS4zOjxicj4NCjxicj4NCiZxdW90O0Egcm91dGVyIFNIT1VMRCBk aXNjYXJkIGEgcmVjZWl2ZWQgUDJQIG1vZGUgRElPIHdpdGggbm8gZnVydGhlcjxicj4NCiZuYnNw OyZuYnNwOyBwcm9jZXNzaW5nIGlmIGl0IGRvZXMgbm90IGhhdmUgYmlkaXJlY3Rpb25hbCByZWFj aGFiaWxpdHkgd2l0aCB0aGU8YnI+DQombmJzcDsmbmJzcDsgbmVpZ2hib3IgdGhhdCBnZW5lcmF0 ZWQgdGhlIHJlY2VpdmVkIERJTy4gJm5ic3A7Tm90ZSB0aGF0IGJpZGlyZWN0aW9uYWw8YnI+DQom bmJzcDsmbmJzcDsgcmVhY2hhYmlsaXR5IGRvZXMgbm90IG1lYW4gdGhhdCB0aGUgbGluayBtdXN0 IGhhdmUgdGhlIHNhbWUgdmFsdWVzPGJyPg0KJm5ic3A7Jm5ic3A7IGZvciBhIHJvdXRpbmcgbWV0 cmljIGluIGJvdGggZGlyZWN0aW9ucy4gJm5ic3A7QSByb3V0ZXIgU0hPVUxEIGNhbGN1bGF0ZTxi cj4NCiZuYnNwOyZuYnNwOyB0aGUgdmFsdWVzIG9mIHRoZSBsaW5rLWxldmVsIHJvdXRpbmcgbWV0 cmljcyBpbmNsdWRlZCBpbiB0aGUgcmVjZWl2ZWQ8YnI+DQombmJzcDsmbmJzcDsgRElPIHRha2lu ZyBpbiBhY2NvdW50IHRoZSBtZXRyaWMncyB2YWx1ZSBpbiBib3RoIGZvcndhcmQgYW5kIEJhY2t3 YXJkPGJyPg0KJm5ic3A7Jm5ic3A7IGRpcmVjdGlvbnMuICZuYnNwO0JpZGlyZWN0aW9uYWwgcmVh Y2hhYmlsaXR5IGFsb25nIGEgZGlzY292ZXJlZCByb3V0ZTxicj4NCiZuYnNwOyZuYnNwOyBhbGxv d3MgdGhlIFRhcmdldCB0byB1c2UgdGhpcyByb3V0ZSB0byByZWFjaCB0aGUgT3JpZ2luLiAmbmJz cDtJbjxicj4NCiZuYnNwOyZuYnNwOyBwYXJ0aWN1bGFyLCB0aGUgRFJPIG1lc3NhZ2VzIHRyYXZl bCBmcm9tIHRoZSBUYXJnZXQgdG8gdGhlIE9yaWdpbjxicj4NCiZuYnNwOyZuYnNwOyBhbG9uZyBh IGRpc2NvdmVyZWQgcm91dGUuPGJyPg0KJnF1b3Q7PGJyPg0KPGJyPg0KU28sIHRoZSB0YXJnZXQg Y2FuIGNlcnRhaW5seSB1c2UgYSBkaXNjb3ZlcmVkIHJvdXRlIGFzIGEgc291cmNlIHJvdXRlIHRv IHJlYWNoIHRoZSBvcmlnaW4uIFRoZSBiYWNrd2FyZCBkaXJlY3Rpb24gcm91dGUgbWF5IG5vdCBt ZWV0IGRlc2lyZWQgcm91dGluZyBjb25zdHJhaW50cyBidXQgZG9lcyBwcm92aWRlIGEgd2F5IHRv IHJlYWNoIHRoZSBvcmlnaW4uIFNvLCBpdCBtYXkgYmUgdXNlZnVsIGZvciB0aGUgdGFyZ2V0IHRv IGtub3cgd2hhdCBkZXN0aW5hdGlvbg0KIHByZWZpeGVzIGNhbiBiZSByZWFjaGVkIHZpYSB0aGUg b3JpZ2luLiBJbiBmYWN0LCBpdCBtYWtlcyBzZW5zZSB0byBhbGxvdyB0aGUgdGFyZ2V0IHRvIGlu Y2x1ZGUgb25lIG9yIG1vcmUgJm5ic3A7UklPcyBpbiBpdHMgRFJPIHRvIGxldCBvcmlnaW4ga25v dyB3aGF0IGRlc3RpbmF0aW9uIHByZWZpeGVzIGNvdWxkIGJlIHJlYWNoZWQgdmlhIHRoZSB0YXJn ZXQuPGJyPg0KPGJyPg0KUmVnYXJkaW5nIHRoZSBQSU8sIEkgdGhpbmsgdGhlIG1vc3QgY3JpdGlj YWwgbmVlZCBpcyB0byBhbGxvdyB0aGUgcHJvcGFnYXRpb24gb2YgYWRkcmVzcyBzZWxmLWNvbmZp Z3VyYXRpb24gcHJlZml4ZXMgdmlhIFAyUCBtb2RlIERJT3MuIFRoZXNlIHByZWZpeGVzIGNhbiBi ZSB1c2VkIG5vdCBvbmx5IGJ5IHRoZSB0YXJnZXQgYnV0IGFsc28gdGhlIG90aGVyIG5vZGVzIHRo YXQgam9pbiB0aGUgdGVtcG9yYXJ5IERBRy4gSSBhbSBub3QgdG9vIHN1cmUNCiBhYm91dCBhbGxv d2luZyBQSU9zIHdpdGggTCBmbGFnIHNldCBpbnNpZGUgdGhlIFAyUCBtb2RlIERJT3MuIFdvdWxk IGNlcnRhaW5seSBsaWtlIHRvIGhlYXIgeW91ciB2aWV3cyBvbiB0aGlzLjxicj4NCjxicj4NCjxi cj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KUm9sbCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Um9sbEBpZXRmLm9y ZyI+Um9sbEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3JvbGwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcm9sbDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_2AA5AC69E924D149A8D63EB676AF87DB2CA3BB8CDLEE10entticom_-- From jreddy@ti.com Sun Jun 3 21:51:06 2012 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 067D121F8890 for ; Sun, 3 Jun 2012 21:51:06 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BrQYWkFyUfaj for ; Sun, 3 Jun 2012 21:50:58 -0700 (PDT) Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by ietfa.amsl.com (Postfix) with ESMTP id 6DF5B21F887E for ; Sun, 3 Jun 2012 21:50:54 -0700 (PDT) Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id q544osn4008426; Sun, 3 Jun 2012 23:50:54 -0500 Received: from DFLE71.ent.ti.com (dfle71.ent.ti.com [128.247.5.62]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id q544osOX002679; Sun, 3 Jun 2012 23:50:54 -0500 Received: from DLEE10.ent.ti.com ([fe80::843:a4aa:bf01:3f68]) by DFLE71.ent.ti.com ([fe80::29f6:72ad:a62e:2025%21]) with mapi id 14.01.0323.003; Sun, 3 Jun 2012 23:50:54 -0500 From: "Reddy, Joseph" To: "'Mukul Goyal'" Thread-Topic: Use P2P-RPL to repair DAO routes Thread-Index: AQHNQTeLad/wP4Slmk+rhqippmOu2pbpkwbggAAFsLA= Date: Mon, 4 Jun 2012 04:50:53 +0000 Message-ID: <2AA5AC69E924D149A8D63EB676AF87DB2CA3BB99@DLEE10.ent.ti.com> References: <992131173.513367.1337956316701.JavaMail.root@mail17.pantherlink.uwm.edu> <1851893033.579685.1338693497231.JavaMail.root@mail17.pantherlink.uwm.edu> <2AA5AC69E924D149A8D63EB676AF87DB2CA3BB6A@DLEE10.ent.ti.com> In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CA3BB6A@DLEE10.ent.ti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.170.170.90] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] Use P2P-RPL to repair DAO routes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 04:51:06 -0000 DQpIaSBNdWt1bCwNCg0KVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbi4gSSBhZ3JlZSB3aXRo IHlvdXIgc3VnZ2VzdGlvbiB0byBjb25zaWRlciB0aGlzIGFzIHN1YmplY3QgZm9yIGEgc2VwYXJh dGUgZG9jdW1lbnQuDQoNCi1SZWdhcmRzLCBKb3NlcGgNCg0KDQotLS0tLSBGb3J3YXJkZWQgTWVz c2FnZSAtLS0tLQ0KW0pvc2VwaF0gICANClNlY3Rpb24gMTI6DQouLkluIGdlbmVyYWwsIFAyUC1S UEwgb3BlcmF0aW9uIGRvZXMgbm90IGFmZmVjdCBjb3JlIFJQTCBvcGVyYXRpb24uLiINCkkgdGhp bmsgdGhpcyBpcyB1bmZvcnR1bmF0ZSBhcyBQMlAgY2FuIGJlIHVzZWQgdG8gZml4IGlzc3VlcyB3 aXRoIGNvcmUgcnBsLiBGb3IgZXhhbXBsZSwgaW4gY29yZSBSUEwsIHRoZXJlIGlzIG5vIHdheSB0 byByZXBhaXIgYSBkb3dud2FyZCByb3V0ZSB1bnRpbCB0aGUgYWN0dWFsIFRhcmdldCBzZW5kcyBh bm90aGVyIERBTywgd2hpY2ggY2FuIHRha2UgYSBsb25nIHRpbWUuIEl0IHdvdWxkIGJlIHZlcnkg bmljZSBpZiB0aGUgRG9EYWcgcm9vdCBjYW4gdXNlIFAyUC1SUEwgdG8gZGlzY292ZXIgYSByb3V0 ZSB0byBhIFRhcmdldCBub2RlIHRoYXQgaXMgdW5yZWFjaGFibGUgYW5kIHRoZW4gdXNlIHRoZSBy ZXN1bHRpbmcgc291cmNlIHJvdXRlIGFzIHRoZSBkb3dud2FyZCByb3V0ZS4gIA0KDQpbTXVrdWxd DQpXaGF0IHRoZSB0ZXh0IHlvdSBxdW90ZWQgbWVhbnMgaXMgdGhhdCBpdCBkb2VzIG5vdCBicmVh ayBjb3JlIFJQTCBvcGVyYXRpb24uIFAyUC1SUEwgY2FuIGNlcnRhaW5seSBiZSB1c2VkIGluIHRo ZSBtYW5uZXIgeW91IHNwZWNpZmllZC4gVGhlIHJvb3Qgb2YgYSBnbG9iYWwgRE9EQUcgY2FuIGNl cnRhaW5seSB1c2UgUDJQLVJQTCB0byBkaXNjb3ZlciBhIHNvdXJjZSByb3V0ZSB0byBhbnkgdGFy Z2V0LiBKdXN0IHRoYXQgaXQgd2lsbCBpbnZvbHZlIGNyZWF0aW9uIG9mIGEgc2VwYXJhdGUgdGVt cG9yYXJ5IERBRy4gSWYgeW91IHdhbnQgdG8gZG8gdGhpcyByb3V0ZSBkaXNjb3Zlcnkgd2l0aGlu IHRoZSBzY29wZSBvZiB0aGUgZXhpc3RpbmcgZ2xvYmFsIHBlcm1hbmVudCBEQUcsIGl0IGNhbiBi ZSBkb25lIGJ1dCBuZWVkcyB0byBiZSB3cml0dGVuIHVwIGluIGEgc2VwYXJhdGUgZG9jdW1lbnQu IEkgZG9udCB0aGluayB0aGlzIHByb3Zpc2lvbiBzaG91bGQgYmUgaW5zaWRlIFAyUC1SUEwgZG9j dW1lbnQuIFRoaXMgaXMgYmVjYXVzZSwgZm9yIFJQTCBkZXBsb3ltZW50cyB0aGF0IHdvdWxkIG5v dCBvdGhlcndpc2Ugc3VwcG9ydCBQMlAtUlBMLCBpdCBtYXkgYmUgbW9yZSBlZmZpY2llbnQgdG8g c2ltcGx5IHVzZSBhbiBSUEwgVGFyZ2V0IE9wdGlvbiBpbnNpZGUgYSBESU8gdG8gdHJpZ2dlciBE QU9zIHRoYXQgd291bGQgYWxsb3cgZGVzaXJlZCByb3V0ZSB0byBiZSBkaXNjb3ZlcmVkLiBPZmNv dXJzZSwgdGhpcyBuZWVkcyB0byBiZSB3cml0dGVuIHVwIHRvIChzaW5jZSBjdXJyZW50bHkgVGFy Z2V0IE9wdGlvbiBjYW5ub3Qgc2l0IGluc2lkZSBhIG5vbi1QMlAgbW9kZSBESU8pLg0KDQo= From jpv@cisco.com Sun Jun 3 22:48:19 2012 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 A53C521F8846 for ; Sun, 3 Jun 2012 22:48:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.522 X-Spam-Level: X-Spam-Status: No, score=-109.522 tagged_above=-999 required=5 tests=[AWL=-1.077, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEZ9og7Yv7kR for ; Sun, 3 Jun 2012 22:48:18 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id B424821F883E for ; Sun, 3 Jun 2012 22:48:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4912; q=dns/txt; s=iport; t=1338788898; x=1339998498; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=0voHILJaDPbhkwBWaNthJ35WW3or+GatXQnW2N8j9ps=; b=QWT/VZG2xblgIOmjlnbBc9XM9FakV+yTTbBt3SaEUNL+WNvWZf7lU1zK 3HP9LvpKHefsw9+Wr6+K59QeMaPWehvwpRUwh3ZHfPJZe2WYsfIdtEgbt B/0flPSfUG0CHS5Bu5KX1dDEr3WG19XbFaQMG/2lPYxer/jT/X/ZKDujc s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtEFAA9LzE+rRDoJ/2dsb2JhbABFgx2xCYEHghgBAQEDAQEBAQ8BWgELBQsLGC4nMAYTIodkBAELlxSeagSLEYUwYAOVG4VQiECBZoJi X-IronPort-AV: E=Sophos;i="4.75,711,1330905600"; d="scan'208";a="47535438" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-2.cisco.com with ESMTP; 04 Jun 2012 05:48:18 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q545mIck030424; Mon, 4 Jun 2012 05:48:18 GMT Received: from xfe-sjc-221.amer.cisco.com ([128.107.191.32]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Jun 2012 22:48:17 -0700 Received: from [10.60.114.229] ([10.60.114.229]) by xfe-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 3 Jun 2012 22:48:17 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: JP Vasseur In-Reply-To: Date: Mon, 4 Jun 2012 07:48:15 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <44D4BD29-E77B-446E-90AF-A278FEF31D9A@cisco.com> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu> <2AF45E51-6C3B-48D9-908F-117ECF0CABAA@imag.fr> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 04 Jun 2012 05:48:17.0320 (UTC) FILETIME=[A3C8BA80:01CD4215] Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 05:48:19 -0000 Hi Thomas, See below- On Jun 4, 2012, at 1:25 AM, Thomas Heide Clausen wrote: > Dear JP, >=20 > Opaque LSAs are an interesting, although entirely irrelevant, example = - an apples-to-oranges comparison.=20 >=20 > Opaque LSAs are simply "containers for application specific data, for = distribution through an OSPF domain (link, area, AS wide)". As such, = it's - of course - difficult to specify a transmission frequency; I am = sure that we agree that this naturally is an application dependent = issue. >=20 > DAOs are much more akin to OSPF HELLO or LSA packets, JP> I gave several examples =85 such as BFD packets, PCEP Keepalive; the = point that I was making is that any protocol, you cannot=20 expect to provide hard coded value for the timers in the specifications, = it depends of what you are trying to achieve. Thanks. JP. > in that they pertain to distributing topology proper for the routing = protocol operation - specifically, DAOs are not the slightest like = opaque LSAs. OSPF does quite specify expectations for when, for example, = a HELLO packet should have been received (RouterDeadInterval / = InactivityTimer) or LSAs re-flooded (LSRefreshTime). >=20 > In other words, for opaque LSAs, the content of the LSA is opaque to = the routing protocol (could be anything), whereas the dissemination = process is well defined. Contrast with DAO, where the content is known = (and very much important to the routing protocol), alas, the processing = and dissemination is opaque and so you need an external mechanism for = DAO to work properly. >=20 > I also note a different point, which is that the environment wherein = an OSPF router generally operates (accessible, network engineer access = during operation) is very different from the environment wherein an RPL = router is expected to operate. >=20 > Finally, there are protocols, typically those designed for non-managed = deployments. which permit routers with different parameter = configurations to interoperate, and then again others where lack of = needed information can simply trigger a request for it to be generated. >=20 > Concluding: thus comparing with an information type for a different = purpose, extracted from a protocol for a different deployment with = constraints of a different nature doesn't really help. >=20 > Best, >=20 > Thomas >=20 > On May 19, 2012, at 12:39 , JP Vasseur wrote: >=20 >> Hi Martin, >>=20 >> co-chair hat off =85 >>=20 >> How often do you think that ISIS LSA should be refreshed ? >> Or OSPF opaque LSA for TE extensions be flooded ? >> Or BFD packets ?=20 >> Or PCEP Keepalive when turned on ? >>=20 >> Very seriously =85 these questions apply to all protocols =85 and you = cannot expect the specifications to give you >> hard coded values (but default whenever possible); these are topology = and application specific, don't you think ? >>=20 >> Thanks. >>=20 >> Cheers. >>=20 >> JP. >>=20 >> On May 18, 2012, at 10:46 PM, Martin Heusse wrote: >>=20 >>> Phil,=20 >>> what you are writing bellow may be true (although...) but it does = not address comment 12, that we have no idea when DAOs should be sent = and how DAOs should be handled (how long should the route be kept?).=20 >>>=20 >>> Along those lines, 2 comments: >>> 1) I notice that draft-ietf-roll-applicability-ami, for instance, = ignores DAOs except for specifying that DAOs SHOULD be sent -- so they = might not be sent--, even though "Two-way communication is a = requirement"(?). At the same time, this draft goes as far as suggesting = what parameters to use for trickle (big deal) or for MaxRankIncrease = (big deal: will things break if someone uses 512 instead of 1024?).=20 >>> (same comment applies to draft-gnawali-roll-rpl-recommendations-03.) >>> 2) What is the point of making DAOs compact in storing = mode (learning the route recursively) while the packets that actually = contain data have to carry the whole path anyway? =20 >>>=20 >>> Best regards, >>> Martin >>>=20 >>>=20 >>> Philip Levis wrote: >>>=20 >>>> For 12, "implementations may exhibit a bad performance if not = carefully implemented." I think it is safe to say this is true for = almost ANY protocol. A specification is not intended to be a complete = statement of efficient implementation, otherwise you give little = latitude to future improvements and good engineering. >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abdussalambaryun@gmail.com Sun Jun 3 23:06:37 2012 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 BE88021F87D2 for ; Sun, 3 Jun 2012 23:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.469 X-Spam-Level: X-Spam-Status: No, score=-3.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyrVoVO6-61o for ; Sun, 3 Jun 2012 23:06:37 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 282AA21F87D0 for ; Sun, 3 Jun 2012 23:06:37 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2562781vbb.31 for ; Sun, 03 Jun 2012 23:06:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=TLo0QPPpZkzi8HnZy/VofnO5TzfcvSO9NcAfBlV7bNw=; b=w8cYfF6Us4ZaX1nPv48beoIX+TT9X4hDHOBTpOazMZo0FZ0dmrTwRJcIq/xdhpK+5z VDdNcpmZTSTLud992pJHPj1SCvhZZ+YtVj/al6J5OqLfNt9wVQ5d6lMEbjRf0bYONn07 hmtRvmh/4XvCWI1w/bNIXFXqS48J2gp2VkqTJSCVGyXWqhHk97M2sOK8d4oR06v2GCls W9q+S2SNnCA7V8gp7EwDWW0u1aVHl7uqq+/0LCYLjrGfsFmVx9ShPj9/foQnNjk6gWBY cLA3NM9eG4VJA8/e6dFCwcE79qnwqP9rNLn6TN7nIev+Evh/anvfdyLoJex/BmHzh2dp WNEA== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr9533809vds.117.1338789995930; Sun, 03 Jun 2012 23:06:35 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Sun, 3 Jun 2012 23:06:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 4 Jun 2012 08:06:35 +0200 Message-ID: From: Abdussalam Baryun To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] Node Ability to Participate (NAP) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 06:06:37 -0000 =============== Possible Duplication ==================== Hi All, I want to discuss is there a need to consider the node ability to participate (NAP) in LLN functions? I think that the node ability (considering; energy consumption issue, routing issue, and environment-event issue), it is good for some node-originators to know neighbor nodes/sinks ability ( NAP to-route, or NAP continue-to-route, or NAP to-survive, NAP to-store, NAP to-manage, or other abilities), but not sure if it is available in some of the ROLL or 6lowpan protocols, nor sure if it can make side effects to LLN performance. The node-ability can be useful if we have different devices capabilities and conditions. This knowledge-factor can be useful and may be included in some technique, or forwarding table in the protocol specification. I want to know your advises and opinion, thanking you, Best regards Abdussalam Baryun, University of Glamorgan, UK. ======================================================= ( One may be wrong, or may be right, but it does not matter if we work together as a group to discuss and resolve all issues. WGs are always right ) **************************************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. The contents are comply to the IETF regulations, and WG procedures. You should not copy the email nor use it for any other purpose, nor disclose, nor distribute its contents to any other person. ***************************************************************************************** From abdussalambaryun@gmail.com Sun Jun 3 23:09:55 2012 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 451BB21F87F5 for ; Sun, 3 Jun 2012 23:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.475 X-Spam-Level: X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CPFKqc6Rlo9H for ; Sun, 3 Jun 2012 23:09:54 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 651D021F87E3 for ; Sun, 3 Jun 2012 23:09:54 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2568628vcq.31 for ; Sun, 03 Jun 2012 23:09:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=5ATxOjAtCenIlZ5esZbpmSq2dNr9K+LOqghn0WvlCeo=; b=TdiQTiOe1aANhe3q5BblwBg9lJ4mOIuNuO9XuWVtu5JJYvfGSSS7VzJLo1pVuA/R9E 85FALOcxBb6rRDzvQ6zml0ti3iZdRMUpd84BgFZpGqT50DqIrCSv0Yq8HkU0Zj+ScU9T nzU1JixKhE3I5V5DhfUBIQogS/htpF1xYbIB/pV8trwn9NvXcaGSM2znvZijHUvg/4OS kgUOqownDcDtW40wbLoyGrRXH88+S7vJnMYWEsAIrovA3qf9euamN3eF3nCOxoknAFXN UQ18yaDKWzee7SUZUsRAMOSjS4qhNtoMUjF/QjGH/hPE2SuUtYq213GC20AVDASSkcO+ NJZA== MIME-Version: 1.0 Received: by 10.52.36.116 with SMTP id p20mr9582763vdj.129.1338790193777; Sun, 03 Jun 2012 23:09:53 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Sun, 3 Jun 2012 23:09:53 -0700 (PDT) In-Reply-To: References: <1FFD6787-3529-462B-B59A-115ADC99B842@cisco.com> Date: Mon, 4 Jun 2012 08:09:53 +0200 Message-ID: From: Abdussalam Baryun To: JP Vasseur , roll Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] Node Ability to Participate (NAP) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 06:09:55 -0000 ================== Possible Duplication =================== Hi All, I want to discuss is there a need to consider the node ability to participate (NAP) in LLN functions? I think that the node ability (considering; energy consumption issue, routing issue, and environment-event issue), it is good for some node-originators to know neighbor nodes/sinks ability ( NAP to-route, or NAP continue-to-route, or NAP to-survive, NAP to-store, NAP to-manage, or other abilities), but not sure if it is available in some of the ROLL or 6lowpan protocols, nor sure if it can make side effects to LLN performance. The node-ability can be useful if we have different devices capabilities and conditions. This knowledge-factor can be useful and may be included in some technique, or forwarding table in the protocol specification. I want to know your advises and opinion, thanking you, Best regards Abdussalam Baryun, University of Glamorgan, UK. ======================================================= ( One may be wrong, or may be right, but it does not matter if we work together as a group to discuss and resolve all issues. WGs are always right ) **************************************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. The contents are comply to the IETF regulations, and WG procedures. You should not copy the email nor use it for any other purpose, nor disclose, nor distribute its contents to any other person. ***************************************************************************************** From prvs=49575ab5a=mukul@uwm.edu Sun Jun 3 23:27:40 2012 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 2955021F8802 for ; Sun, 3 Jun 2012 23:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.398 X-Spam-Level: X-Spam-Status: No, score=-6.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dqKNwnPOnkNi for ; Sun, 3 Jun 2012 23:27:39 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 402C421F87CC for ; Sun, 3 Jun 2012 23:27:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAGRUzE9/AAAB/2dsb2JhbABFhU6xdgEBAQQBAQEgSwsMDw4DBAEBAwINFgMCKR8JCAYTiAsLpDGIWokABIEjiW6EfoESA4hAjFuPdoJ+ Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 4184D1FD0C9; Mon, 4 Jun 2012 01:27:38 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qq2+tuUS3BUK; Mon, 4 Jun 2012 01:27:37 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id CEB121FD0C7; Mon, 4 Jun 2012 01:27:37 -0500 (CDT) Date: Mon, 4 Jun 2012 01:27:37 -0500 (CDT) From: Mukul Goyal To: Joseph Reddy Message-ID: <515392394.582804.1338791257726.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CA3BB37@DLEE10.ent.ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] P2P-RPL: Data-Option in P2P-DIO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 06:27:40 -0000 Hi Joseph As Jakob mentioned there is no need for the origin to modify a data option = during a route discovery. So I guess I can certainly make this change in P2= P-RPL. Sequence numbers were introduced in Data option in response to Pasca= l's question whether it was possible for the origin to modify the data opti= on during a route discovery. I should have answered no right then. :( I guess we could consider this item closed. Thanks Mukul ----- Original Message ----- From: "Joseph Reddy" To: "Mukul Goyal" , roll@ietf.org, "Jakob Buron (Jakob_Buron= @sigmadesigns.com)" Sent: Sunday, June 3, 2012 11:29:51 PM Subject: RE: P2P-RPL: Data-Option in P2P-DIO Hi Jakob, If we agree to remove the sequence numbers from the data option ( and, con= sequently, require that the Origin must not modify the data-option during a= transmission ), that would be acceptable to me. -Regards, Joseph ----- Forwarded Message ----- From: "Jakob Buron" To: "Joseph' 'Reddy" , "Mukul Goyal" Cc: roll@ietf.org Sent: Tuesday, May 29, 2012 8:24:03 AM Subject: RE: P2P-RPL: Data-Option in P2P-DIO Hi, please see my comments inline. > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > Of Reddy, Joseph > Sent: Friday, May 25, 2012 11:08 PM > To: Mukul Goyal > Cc: roll@ietf.org > Subject: Re: [Roll] P2P-RPL: Data-Option in P2P-DIO >=20 > Hi Mukul, >=20 > See response below... >=20 > -Regards, Joseph >=20 > -----Original Message----- >=20 > [Joseph] > Section 9.4 > Bullet 1: > Under what conditions would a router receive the same DIO and a Data-=20 > Option with higher sequence number? I assume that only the Originator=20 > can include a Data-Option ? Same question also arises for section 9.5=20 > ( para > 1 ) >=20 > [Mukul] > Yes, only the origin can include a data option for delivery to the=20 > target(s). In theory, the origin might have newer data to convey to=20 > the > target(s) while the route discovery is still going on. Sequence=20 > numbers accounts for that possibility. Note that Data option did not=20 > have a sequence number earlier (before the first LC). Then, Pascal=20 > raised the possibility what if origin changes the data option. How=20 > would intermediate routers and target know that this is the newer=20 > data? Hence, we introduced the sequence number. >=20 > [Joseph] > I don=E2=80=99t think the Origin should able to this. In fact, the Origin= must=20 > not make any changes to the contents of the DIO and retransmit it=20 > without updating the version number. If the Origin wants to send data,=20 > it should simply wait until the p2p route is setup and then use it. >=20 > The whole idea of sending UDP Data messages in the ICMP message=20 > payload itself doesn=E2=80=99t seem quite right. It is also not simple fr= om an=20 > implementation perspective to make this kind of cross layer interactions. >=20 [Jakob] I understand the concern about the Data Option and cross-layer interactions= . I also believe that it is a sensible and necessary design choice for home= automation networks. Home automation frequently requires low-latency messa= ges to be delivered to targets for which the originator has no route. An ex= ample is a remote light switch that needs to control a relocated lamp. The = fastest way to do that in a reactive routing scheme is to piggyback the dat= a on the routing packets. The other option would be to use simple flooding,= with no trickle control, which would involve generating a huge number of p= ackets. Piggybacking data on routing packets helps avoid generating extra p= ackets. Home automation networks do not need to update the Data Option while a disc= overy is in progress. I am okay with removing the sequence numbers if they = add too much complexity. Best regards, Jakob >=20 >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=49575ab5a=mukul@uwm.edu Sun Jun 3 23:30:15 2012 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 E99D621F86B1 for ; Sun, 3 Jun 2012 23:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id buDk2CNTX1xc for ; Sun, 3 Jun 2012 23:30:14 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id DFD7621F86AF for ; Sun, 3 Jun 2012 23:30:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAJtVzE9/AAAB/2dsb2JhbABFhU6xdgEBBSNWDA8OAwQBAQMCDRkCUQgGE4gLpECIWokEgSOJboR+gRIDiECMW492gn6BOCM Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 7042BE6A8D; Mon, 4 Jun 2012 01:30:13 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJe6EpZeteHI; Mon, 4 Jun 2012 01:30:13 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 205D2E6A72; Mon, 4 Jun 2012 01:30:13 -0500 (CDT) Date: Mon, 4 Jun 2012 01:30:13 -0500 (CDT) From: Mukul Goyal To: Joseph Reddy Message-ID: <457536501.582806.1338791413060.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CA3BB99@DLEE10.ent.ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] Use P2P-RPL to repair DAO routes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 06:30:15 -0000 Thanks Joseph. I guess this issue is closed too as far as P2P-RPL is concerned. Mukul ----- Original Message ----- From: "Joseph Reddy" To: "Mukul Goyal" Cc: roll@ietf.org Sent: Sunday, June 3, 2012 11:50:53 PM Subject: RE: Use P2P-RPL to repair DAO routes Hi Mukul, Thanks for the clarification. I agree with your suggestion to consider this as subject for a separate document. -Regards, Joseph ----- Forwarded Message ----- [Joseph] Section 12: ..In general, P2P-RPL operation does not affect core RPL operation.." I think this is unfortunate as P2P can be used to fix issues with core rpl. For example, in core RPL, there is no way to repair a downward route until the actual Target sends another DAO, which can take a long time. It would be very nice if the DoDag root can use P2P-RPL to discover a route to a Target node that is unreachable and then use the resulting source route as the downward route. [Mukul] What the text you quoted means is that it does not break core RPL operation. P2P-RPL can certainly be used in the manner you specified. The root of a global DODAG can certainly use P2P-RPL to discover a source route to any target. Just that it will involve creation of a separate temporary DAG. If you want to do this route discovery within the scope of the existing global permanent DAG, it can be done but needs to be written up in a separate document. I dont think this provision should be inside P2P-RPL document. This is because, for RPL deployments that would not otherwise support P2P-RPL, it may be more efficient to simply use an RPL Target Option inside a DIO to trigger DAOs that would allow desired route to be discovered. Ofcourse, this needs to be written up to (since currently Target Option cannot sit inside a non-P2P mode DIO). From prvs=49575ab5a=mukul@uwm.edu Sun Jun 3 23:33:41 2012 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 C6D7921F8864 for ; Sun, 3 Jun 2012 23:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.371 X-Spam-Level: X-Spam-Status: No, score=-5.371 tagged_above=-999 required=5 tests=[AWL=-0.926, BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtvIGzLlfF3E for ; Sun, 3 Jun 2012 23:33:41 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id BA52021F86AF for ; Sun, 3 Jun 2012 23:33:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EABNWzE9/AAAB/2dsb2JhbABFhU6xdgEBAQMBAQEBIEoBCwUHDxEEAQEBAgINGQIpKAgGE4gGBQukNIhaiQAEgSOJboR+gRIDiECMW492gn4 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id EAFF71FD0C9; Mon, 4 Jun 2012 01:33:39 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TPBrrR-yIpoC; Mon, 4 Jun 2012 01:33:39 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 701C51FD0CA; Mon, 4 Jun 2012 01:33:39 -0500 (CDT) Date: Mon, 4 Jun 2012 01:33:39 -0500 (CDT) From: Mukul Goyal To: JP Vasseur Message-ID: <235193708.582808.1338791619378.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <44D4BD29-E77B-446E-90AF-A278FEF31D9A@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 06:33:41 -0000 >the point that I was making is that any protocol, you cannot=20 expect to provide hard coded value for the timers in the specifications, it= depends of what you are trying to achieve. I agree with JP. Such values may differ not only across applications but al= so across various deployments within an application domain. I guess the app= licability statements might provide some guidance in this respect. Thanks Mukul =20 ----- Original Message ----- From: "JP Vasseur" To: "Thomas Heide Clausen" Cc: "roll WG" , "Michael Richardson" Sent: Monday, June 4, 2012 12:48:15 AM Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences Hi Thomas, See below- On Jun 4, 2012, at 1:25 AM, Thomas Heide Clausen wrote: > Dear JP, >=20 > Opaque LSAs are an interesting, although entirely irrelevant, example - a= n apples-to-oranges comparison.=20 >=20 > Opaque LSAs are simply "containers for application specific data, for dis= tribution through an OSPF domain (link, area, AS wide)". As such, it's - of= course - difficult to specify a transmission frequency; I am sure that we = agree that this naturally is an application dependent issue. >=20 > DAOs are much more akin to OSPF HELLO or LSA packets, JP> I gave several examples =E2=80=A6 such as BFD packets, PCEP Keepalive; = the point that I was making is that any protocol, you cannot=20 expect to provide hard coded value for the timers in the specifications, it= depends of what you are trying to achieve. Thanks. JP. > in that they pertain to distributing topology proper for the routing prot= ocol operation - specifically, DAOs are not the slightest like opaque LSAs.= OSPF does quite specify expectations for when, for example, a HELLO packet= should have been received (RouterDeadInterval / InactivityTimer) or LSAs r= e-flooded (LSRefreshTime). >=20 > In other words, for opaque LSAs, the content of the LSA is opaque to the = routing protocol (could be anything), whereas the dissemination process is = well defined. Contrast with DAO, where the content is known (and very much = important to the routing protocol), alas, the processing and dissemination = is opaque and so you need an external mechanism for DAO to work properly. >=20 > I also note a different point, which is that the environment wherein an O= SPF router generally operates (accessible, network engineer access during o= peration) is very different from the environment wherein an RPL router is e= xpected to operate. >=20 > Finally, there are protocols, typically those designed for non-managed de= ployments. which permit routers with different parameter configurations to = interoperate, and then again others where lack of needed information can si= mply trigger a request for it to be generated. >=20 > Concluding: thus comparing with an information type for a different purpo= se, extracted from a protocol for a different deployment with constraints o= f a different nature doesn't really help. >=20 > Best, >=20 > Thomas >=20 > On May 19, 2012, at 12:39 , JP Vasseur wrote: >=20 >> Hi Martin, >>=20 >> co-chair hat off =E2=80=A6 >>=20 >> How often do you think that ISIS LSA should be refreshed ? >> Or OSPF opaque LSA for TE extensions be flooded ? >> Or BFD packets ?=20 >> Or PCEP Keepalive when turned on ? >>=20 >> Very seriously =E2=80=A6 these questions apply to all protocols =E2=80= =A6 and you cannot expect the specifications to give you >> hard coded values (but default whenever possible); these are topology an= d application specific, don't you think ? >>=20 >> Thanks. >>=20 >> Cheers. >>=20 >> JP. >>=20 >> On May 18, 2012, at 10:46 PM, Martin Heusse wrote: >>=20 >>> Phil,=20 >>> what you are writing bellow may be true (although...) but it does not a= ddress comment 12, that we have no idea when DAOs should be sent and how DA= Os should be handled (how long should the route be kept?).=20 >>>=20 >>> Along those lines, 2 comments: >>> 1) I notice that draft-ietf-roll-applicability-ami, for instance, ignor= es DAOs except for specifying that DAOs SHOULD be sent -- so they might not= be sent--, even though "Two-way communication is a requirement"(?). At the= same time, this draft goes as far as suggesting what parameters to use for= trickle (big deal) or for MaxRankIncrease (big deal: will things break if = someone uses 512 instead of 1024?).=20 >>> (same comment applies to draft-gnawali-roll-rpl-recommendations-03.) >>> 2) What is the point of making DAOs compact in storing mode (= learning the route recursively) while the packets that actually contain dat= a have to carry the whole path anyway? =20 >>>=20 >>> Best regards, >>> Martin >>>=20 >>>=20 >>> Philip Levis wrote: >>>=20 >>>> For 12, "implementations may exhibit a bad performance if not carefull= y implemented." I think it is safe to say this is true for almost ANY prot= ocol. A specification is not intended to be a complete statement of efficie= nt implementation, otherwise you give little latitude to future improvement= s and good engineering. >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=49575ab5a=mukul@uwm.edu Sun Jun 3 23:38:07 2012 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 4E1D721F8758 for ; Sun, 3 Jun 2012 23:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.345 X-Spam-Level: X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNp83fNkI8y1 for ; Sun, 3 Jun 2012 23:38:06 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 6735C21F8709 for ; Sun, 3 Jun 2012 23:38:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EANFWzE9/AAAB/2dsb2JhbABFhU6xdgEBAQQBAQEgRAcLDA8OAwQBAQMCDQQVAikoCAYTiAsLpDaIXIkABIEjiW6CboIQgRIDiECMW492gn6BOCM Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id E3EE01FD0C9; Mon, 4 Jun 2012 01:38:05 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id deNpUs5KOLHg; Mon, 4 Jun 2012 01:38:05 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 6D69A1FD0C7; Mon, 4 Jun 2012 01:38:05 -0500 (CDT) Date: Mon, 4 Jun 2012 01:38:05 -0500 (CDT) From: Mukul Goyal To: Joseph Reddy Message-ID: <640777384.582825.1338791885349.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CA3BB8C@DLEE10.ent.ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] P2P-RPL: RIO/PIO in P2P-DIO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 06:38:07 -0000 So I guess I would simply refer to RFC 6550 regarding how PIOs might be use= d in P2P-RPL. I will also clarify that the RIO would advertize to the targe= t(s) the origin's connectivity to the specified prefix. Thanks Mukul ----- Original Message ----- From: "Joseph Reddy" To: "Mukul Goyal" Cc: roll@ietf.org Sent: Sunday, June 3, 2012 11:50:22 PM Subject: RE: [Roll] P2P-RPL: RIO/PIO in P2P-DIO =C2=A0=20 Hi Mukul,=20 Thanks for the clarification. For the PIO flags, I think the settings must = not contradict the RPL spec. So =C2=A0I would add the same restrictions her= e ( i.e. L bit must not be set ).=20 -Regards, Joseph=20 ----- Original Message ----- From: "Mukul Goyal" < mukul@uwm.edu >=20 To: "Joseph Reddy" < jreddy@ti.com >=20 Cc: roll@ietf.org=20 Sent: Friday, May 25, 2012 4:40:22 PM=20 Subject: Re: [Roll] P2P-RPL: RIO/PIO in P2P-DIO=20 Hi Joseph=20 Please see inline.=20 Thanks=20 Mukul=20 [Joseph1]=20 Section 6.1:=20 "...A P2P-DIO MAY carry one or more RIO and PIO options..."=20 I am not sure how these options should be used by the DAG members. Later on= , in 9.1, it says that "..the temporary DAG must not be used to route packe= ts....". So what is the purpose of RIO and also PIO ?=20 [Mukul1]=20 The RIO would advertize to the target(s) the origin's connectivity to the s= pecified prefix. Regarding PIO, I would very much like to allow P2P mode DI= Os to carry PIOs to propagate prefixes for address selfconfiguration (i.e. = have A flag set). I think we could forbid setting the R flag to one in a PI= O carried in a P2P mode DIOs. Regarding the L flag, I think we could allow = a P2P mode DIO to carry a PIO with L flag set subject to the following rule= s in RFC 6550:=20 <...>=20 [Joseph2]=20 The RIO/PIO information is sent by the Origin to propagate its connectivity= and prefix information. However, the route is established towards the Targ= et. So I don=E2=80=99t understand why the Origin information is relevant ..= =20 [Mukul2]=20 Here is some relevant text from Section 9.3:=20 "A router SHOULD discard a received P2P mode DIO with no further=20 =C2=A0=C2=A0 processing if it does not have bidirectional reachability with= the=20 =C2=A0=C2=A0 neighbor that generated the received DIO. =C2=A0Note that bidi= rectional=20 =C2=A0=C2=A0 reachability does not mean that the link must have the same va= lues=20 =C2=A0=C2=A0 for a routing metric in both directions. =C2=A0A router SHOULD= calculate=20 =C2=A0=C2=A0 the values of the link-level routing metrics included in the r= eceived=20 =C2=A0=C2=A0 DIO taking in account the metric's value in both forward and B= ackward=20 =C2=A0=C2=A0 directions. =C2=A0Bidirectional reachability along a discovere= d route=20 =C2=A0=C2=A0 allows the Target to use this route to reach the Origin. =C2= =A0In=20 =C2=A0=C2=A0 particular, the DRO messages travel from the Target to the Ori= gin=20 =C2=A0=C2=A0 along a discovered route.=20 "=20 So, the target can certainly use a discovered route as a source route to re= ach the origin. The backward direction route may not meet desired routing c= onstraints but does provide a way to reach the origin. So, it may be useful= for the target to know what destination prefixes can be reached via the or= igin. In fact, it makes sense to allow the target to include one or more = =C2=A0RIOs in its DRO to let origin know what destination prefixes could be= reached via the target.=20 Regarding the PIO, I think the most critical need is to allow the propagati= on of address self-configuration prefixes via P2P mode DIOs. These prefixes= can be used not only by the target but also the other nodes that join the = temporary DAG. I am not too sure about allowing PIOs with L flag set inside= the P2P mode DIOs. Would certainly like to hear your views on this.=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Jun 4 04:54:10 2012 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 08FCF21F8762 for ; Mon, 4 Jun 2012 04:54:10 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pIStU9WHAXKp for ; Mon, 4 Jun 2012 04:54:09 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4F7AC21F86BB for ; Mon, 4 Jun 2012 04:54:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1314; q=dns/txt; s=iport; t=1338810849; x=1340020449; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=6gy/bb4sIlW2GaBWcy6SgO2d/6aYPj4GdUFtL4VXMjA=; b=HaIeniblQvaXYzBm5bYrHTXKv0orwwJlHxUt47fVHW4QnbW32L9qUES8 vUddWt3dKiCROVmRMBGoty6bz9iF4vcn/674anlU5mGEcSDhb0jIBkSVC 50b4zQRiyfqqN6qYr90+tcRBKoI3koePE1gE9X4cjWSglhrF1aBufl8Zu o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAIChzE+tJV2d/2dsb2JhbABFhU6tPoEagQeCGAEBAQQSARARUQQCAQgRBAEBAwIGHQMCAgIwFAEGAQEFAwIEEwgah2mWeo0WkhWBI4luAoR8MmADoyuBZoJg X-IronPort-AV: E=Sophos;i="4.75,712,1330905600"; d="scan'208";a="89234813" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 04 Jun 2012 11:53:59 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id q54BrxYZ030955 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 4 Jun 2012 11:53:59 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.42]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0298.004; Mon, 4 Jun 2012 06:53:59 -0500 From: "Pascal Thubert (pthubert)" To: "roll@ietf.org" Thread-Topic: Expiration impending: Thread-Index: AQHNQkcUCaPa44JaukKsojXuJ1DPWpbqC1jA Date: Mon, 4 Jun 2012 11:53:45 +0000 Deferred-Delivery: Mon, 4 Jun 2012 11:53:00 +0000 Message-ID: References: <20120604114208.13263.77277.idtracker@ietfa.amsl.com> In-Reply-To: <20120604114208.13263.77277.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.128] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18946.006 x-tm-as-result: No--33.995700-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Roll] FW: Expiration impending: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 11:54:10 -0000 RGVhciBXRzoNCg0KVGhpcyBkcmFmdCBpcyBkZXNpZ25lZCB0byBhcHBseSBSUEwgb24gYXN5bW1l dHJpYyBsaW5rcyBhZnRlciBzZXZlcmFsIGRpc2N1c3Npb25zIG9uIHRoZSBNTC4NCiBJbiBwYXJ0 aWN1bGFyLCBpdCBhbGxvd3MgdG86DQoxKSAgYnVpbGQgYSBkaWZmZXJlbnQgdG9wb2xvZ3kgZm9y IHVwd2FyZCBhbmQgZG93bndhcmQgdHJhZmZpYw0KMikgIGZhbGxiYWNrIHRyYWZmaWMgZnJvbSBh IGJyb2tlbiB0b3BvbG9neSB0byBhIGJhY2t1cCBvbmUuDQoNCkl0IGlzIG5vdyBjbG9zZSB0byBl eHBpcnkgYnV0IHJhaXNlZCBsaXR0bGUgZGlzY3Vzc2lvbiBzaW5jZSBwdWJsaWNhdGlvbi4NCklm IHRoZXJlJ3Mgc3RpbGwgaW50ZXJlc3QgaW4gcHJvZ3Jlc3NpbmcgUlBMIG9uIGFzeW1tZXRyaWMg bGlua3MgSSBjYW4gZWFzaWx5IHJlZnJlc2ggaXQgYW5kL29yIGFkZCBzdHVmZjsNCm90aGVyd2lz ZSBJJ2xsIHByb2JhYmx5IGdpdmUgdXAgb24gdGhpcyBzdWJqZWN0Lg0KDQpXaGF0IGRvIHlvdSB0 aGluaz8NCg0KUGFzY2FsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IElF VEYgU2VjcmV0YXJpYXQgW21haWx0bzppZXRmLXNlY3JldGFyaWF0LXJlcGx5QGlldGYub3JnXSAN ClNlbnQ6IGx1bmRpIDQganVpbiAyMDEyIDEzOjQyDQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHVi ZXJ0KQ0KU3ViamVjdDogRXhwaXJhdGlvbiBpbXBlbmRpbmc6IDxkcmFmdC10aHViZXJ0LXJvbGwt YXN5bWxpbmstMDIudHh0Pg0KDQpUaGUgZm9sbG93aW5nIGRyYWZ0IHdpbGwgZXhwaXJlIHNvb246 DQoNCk5hbWU6ICAgICBkcmFmdC10aHViZXJ0LXJvbGwtYXN5bWxpbmsNClRpdGxlOiAgICBSUEwg YWRhcHRhdGlvbiBmb3IgYXN5bW1ldHJpY2FsIGxpbmtzDQpTdGF0ZTogICAgSS1EIEV4aXN0cw0K RXhwaXJlczogIDIwMTItMDYtMTEgKGluIDYgZGF5cywgMTkgaG91cnMpDQoNCg== From abdussalambaryun@gmail.com Sat Jun 2 02:36:44 2012 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 6F90D21F8962; Sat, 2 Jun 2012 02:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=0.175, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5gNZYwdxZL4H; Sat, 2 Jun 2012 02:36:44 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF93721F8961; Sat, 2 Jun 2012 02:36:43 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1941945vbb.31 for ; Sat, 02 Jun 2012 02:36:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ME/3HnYjTtezDYvIE6rLCnc8fzoXdRVrSygd86zVh1E=; b=d3PvknqL6eeTQqfCK5YSCz+lwHFcOuMSCoEhBDt4am8gNd5zeb688omXbQQYn7zDTJ VVWBRFnf5+iFVa5YqdtyqmN4Qit3HUosqB8u/X3w461whfH/Ds5qGnZAOPunU38c9+OV UpSKo2NZzql4kpFzZ8Xefbp8i3o0tKWuLHj2OKI/Kne9ZVoII//yzOAJf5iTg6nvOBU3 EL0TTsmEcBB0maq449IwLqtuIJUqxk82W6LGpAeyIjsgbVUKyC26/8klg4VmD0sK7z5E YAHt+1ueiwvUBLay3+1yzM0yUwVRHyXz3O8AOdLvOmQtI7OUS04WTDKse6tIQWa0XulP 9ZQA== MIME-Version: 1.0 Received: by 10.52.33.37 with SMTP id o5mr5120786vdi.86.1338629803033; Sat, 02 Jun 2012 02:36:43 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Sat, 2 Jun 2012 02:36:42 -0700 (PDT) Date: Sat, 2 Jun 2012 11:36:42 +0200 Message-ID: From: Abdussalam Baryun To: roll@ietf.org, 6lowpan@ietf.org Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Mon, 04 Jun 2012 05:48:14 -0700 Subject: [Roll] Node Ability to Participate (NAP) 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, 02 Jun 2012 09:36:44 -0000 Hi All, I want to discuss is there a need to consider the node ability to participate (NAP) in LLN functions? I think that the node ability (considering; energy consumption issue, routing issue, and environment-event issue), it is good for some node-originators to know neighbor nodes/sinks ability ( NAP to-route, or NAP continue-to-route, or NAP to-survive, NAP to-store, NAP to-manage, or other abilities), but not sure if it is available in some of the ROLL or 6lowpan protocols, nor sure if it can make side effects to LLN performance. The node-ability can be useful if we have different devices capabilities and conditions. This knowledge-factor can be useful and may be included in some technique, or forwarding table in the protocol specification. I want to know your advises and opinion, thanking you, Best regards Abdussalam Baryun, University of Glamorgan, UK. ======================================================= ( One may be wrong, or may be right, but it does not matter if we work together as a group to discuss and resolve all issues. WGs are always right ) **************************************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. The contents are comply to the IETF regulations, and WG procedures. You should not copy the email nor use it for any other purpose, nor disclose, nor distribute its contents to any other person. ***************************************************************************************** From pthubert@cisco.com Sun Jun 3 23:38:36 2012 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 88DC221F882D for ; Sun, 3 Jun 2012 23:38:36 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baKe8AxL2DX9 for ; Sun, 3 Jun 2012 23:38:35 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3E2D821F877B for ; Sun, 3 Jun 2012 23:38:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=13667; q=dns/txt; s=iport; t=1338791915; x=1340001515; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=bneNrdi13xWqMPaxVs/EiLPWv2921+/3ugAKdUC3Ewk=; b=l+sKjgXwmxQRbWOO7z9HhXH5e5cAHPp6NJqAxrBWJxLl3rI7MxB96GpB l2Nh/kEpF+KX98bZrOH8tTo5NMFqYze6WoT36cVb0qPodTQteF9K0TZ44 C6a850KV4liavb2WhzNa9nJR/vZWiEBsWDWXBQtzjN1FC+lzqkqCP2EcS U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAEBXzE+tJXG+/2dsb2JhbABFtCWBB4IYAQEBAwEBAQEPAVsLBQcEAgEIDgMEAQELHQchBgsUCQgCBAENBQgGFIdbAwYFC5chlRsNiU6KMWAahRZgA4gNhiqDCIRriWyDFYFmgmCBXw X-IronPort-AV: E=Sophos;i="4.75,711,1330905600"; d="scan'208";a="89150617" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 04 Jun 2012 06:38:34 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id q546cYbI019499 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 4 Jun 2012 06:38:34 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.42]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Mon, 4 Jun 2012 01:38:34 -0500 From: "Pascal Thubert (pthubert)" To: Ralph Droms , Michael Richardson Thread-Topic: [Roll] knowing which multiple metrics matter: MRHOF related questions Thread-Index: AQHNQC9cOUO7lV88+Ua2gzBoqwiFeJbptIpQ Date: Mon, 4 Jun 2012 06:38:22 +0000 Deferred-Delivery: Mon, 4 Jun 2012 06:38:00 +0000 Message-ID: References: <12418.1337957631@marajade.sandelman.ca> <5E46BEEE-3B9B-4E94-B54F-FE95CB8FE642@gmail.com> In-Reply-To: <5E46BEEE-3B9B-4E94-B54F-FE95CB8FE642@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.55.81.143] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18946.003 x-tm-as-result: No--40.005800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/mixed; boundary="_002_E045AECD98228444A58C61C200AE1BD802FCAE31xmbrcdx01ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 04 Jun 2012 05:48:14 -0700 Cc: "roll@ietf.org" Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 06:38:36 -0000 --_002_E045AECD98228444A58C61C200AE1BD802FCAE31xmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi: I agree with Ralph that there is a choice to be made whether this OF is one= OF or a generic OF that is instantiated by metric (a toolbox). If it is a specific OF, it is fair to require from IANA a specific OF numbe= r (1 in the IANA section) but then we can expect that all implementations o= f this OF will behave the same. Here, the behavior will vary quite dramatically with some implementation de= cisions (see the unresolved issue in the attached mail) and metric choices = (Ralph's point here).=20 As it goes, we could figure that MrHof is not one but many OFs. If that's = so then the OF number for the local variation should be assigned consistent= ly for a deployment as opposed to globally significant. There could in fact= be multiple MrHof in a same deployment. My point is somewhat analogous to the UDP ports. Should we have a range for= IANA reserved well known OFs, and then a range that would be assigned on d= emand?=20 Cheers, Pascal -----Original Message----- From: Ralph Droms [mailto:rdroms.ietf@gmail.com]=20 Sent: vendredi 1 juin 2012 21:47 To: Michael Richardson Cc: roll@ietf.org; Pascal Thubert (pthubert) Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related qu= estions On May 25, 2012, at 12:31 PM 5/25/12, Pascal Thubert (pthubert) wrote: > Hi Michael: >=20 > I think RPL does not want to take party there. The OF is a piece of logic= to tie metrics and policies together.=20 > As such, there could be multiple metrics as long as there is good logic t= o tie them in. for instance one would look at optimizing metric A within co= ntraints as expressed by metric B and the OF model will allow that. >=20 > OTOH, it a flows requires a certain optimization (say per one metric) and= another requires something different, then certainly you want two instance= s. >=20 > So ... it depends! >=20 > Pascal >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > Of Michael Richardson > Sent: vendredi 25 mai 2012 16:54 > To: roll@ietf.org > Subject: [Roll] knowing which multiple metrics matter: MRHOF related=20 > questions >=20 >=20 > Ralph asked some questions a few days ago. > His originally DISCUSS is at: > =20 > http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of/ > ballot/ >=20 > This was my reply. I am particularly interested in replies from > Pascal, Anders and Mukul about my assertion about how we would never pick= RPL instances by metrics; that they would in fact be seperate RPL Instance= numbers and DODAG values, and that these things would provisioned by the n= etwork installer. >=20 > =3D=3D=3D=3D >=20 > I'm going to reply to your comments in a different order than you asked t= hem, because I think question #3 is most important, and the rest fall out o= f it. >=20 >>>>>> "Ralph" =3D=3D Ralph Droms writes: > Ralph> 3. Based on (1) and (2), would configuration and selection > Ralph> issues be ameliorated if the five candidate selected metrics > Ralph> were each asssigned a separate objective function? Use of a > Ralph> separate OF code point for each of the five possible selected > Ralph> metrics would allow multiple RPL instances. >=20 > I think that it's important to understand that ROLL has a whole palette o= f things that need to be provisioned by the "network operator". >=20 > In contrast to the situation of ISPs and customers, where the ISP is=20 > the network operator, ROLL networks are more like highly orchestrated > Enterprises: "all your host belong to us" >=20 > so, when we write something like: > "The metric chosen by the network operator to use for path > selection." > in section 2, we really mean: > "The metric chosen by the network operator and provisioned into > the node when the firmware was flashed to use for path selection." OK, so I get that the model is that MRHOF is a toolbox, where the specific = tools are chosen when the device is flashed. In that case, I think some ad= ditional review might be needed to ensure that the MRHOF spec is internally= consistent with that point of view. As one example, I think the "selected metric" should be called out explicit= ly somewhere in section 5 and included in the list of configured parameters= in section 6.1. As another example, I read this text from section 3: Rank is undefined for these node/link metrics: node state and attributes, throughput, and link color. If the rank is undefined, the node must join one of the neighbors as a RPL Leaf node according to [RFC6550]. to mean that if the selected metric is one of the metrics for which rank is= undefined, the node joins as a lead node. But, how can that happen if the= selected metric is chosen by the network operator? > Ralph> 1. Why is one objective function defined for several potential=20 > Ralph> metrics? The details of MRHOF seem to preclude the=20 > Ralph> establishment of several RPL instances in an LLN, each of which=20 > Ralph> uses MRHOF with a different selected metric. >=20 > If one had many different RPL Instances, then we would have different > RPL Instance numbers in the RPL header. There can be many different > DODAG ("destinations") created within that instance. The instances share= a common set of (provisioned) parameters. How does a node know which RPL Instance number maps to which selected metri= c? One way would be to specify that a node advertise ONLY the selected metric = for the RPL Instance in a DIO. > (To put it into DHCP terms: if we have multiple DHCP servers on a link, = then one would expect them to all offer IP addresses in the same subnet. > If one wanted to have addresses in different subnets, and let the host =20 > pick between them, then, one would need different layer-2s: different =20 > VLANs or ESSIDs, or... ) >=20 > If you feel that RPL is rather schizo about provisioning vs configuration= , then I agree. It's not always clear to me why some things are advertised= while others are provisioned. >=20 > In BGPv4, we calculate metrics by adding AS entries in the path. > (It's always additive), and we add at least one AS entry to the path. > One can AS-stuff and add more, but proper operation of BGP does not depen= d upon the exact algorithm used. >=20 > Finally, my impression is that how the various metrics are used (singly, = or in some combination) to calculate Rank Increase is a question of further= research, experimentation, and trade secret. Well, OK, but for the purposes of the MRHOF spec, it seems pretty clear to = me there is one selected metric that is used across all nodes as a strictly= additive path cost computation. > So long as the Rank increases, and a node does not flap between parents, = the exact details do not matter. Each node can do it's parent selection ba= sed upon the available metrics on it's own. It advertises the metrics it h= as. >=20 > I hope the authors will correct me if I'm completely off here. I read the spec to require a single selected metric across the entire RPL I= nstance. - Ralph >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --_002_E045AECD98228444A58C61C200AE1BD802FCAE31xmbrcdx01ciscoc_ Content-Type: message/rfc822 Content-Disposition: attachment; creation-date="Mon, 04 Jun 2012 06:38:19 GMT"; modification-date="Mon, 04 Jun 2012 06:38:19 GMT" Received: from xbh-ams-101.cisco.com ([144.254.74.71]) by xmb-ams-108.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 08:12:06 +0200 Received: from xbh-rcd-202.cisco.com ([72.163.62.201]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 08:12:05 +0200 Received: from rcdn-iport-7.cisco.com ([173.37.86.78]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 01:12:02 -0500 Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 10 Apr 2012 06:12:02 +0000 Received: from rcdn-inbound-a.cisco.com (rcdn-inbound-a.cisco.com [72.163.7.170]) by rcdn-core2-3.cisco.com (8.14.3/8.14.3) with ESMTP id q3A6C2Cx016159; Tue, 10 Apr 2012 06:12:02 GMT Received: from mail.ietf.org ([12.22.58.30]) by rcdn-inbound-a.cisco.com with ESMTP; 10 Apr 2012 06:11:48 +0000 Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5585F21F86F7; Mon, 9 Apr 2012 23:11:48 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD4DB21F84F6 for ; Mon, 9 Apr 2012 23:11:46 -0700 (PDT) Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xrTBzChrnJa0 for ; Mon, 9 Apr 2012 23:11:46 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id B6D6C21F848E for ; Mon, 9 Apr 2012 23:11:45 -0700 (PDT) Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 10 Apr 2012 06:11:44 +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 q3A6BiZS029215; Tue, 10 Apr 2012 06:11:44 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Apr 2012 08:11:44 +0200 From: "Pascal Thubert (pthubert)" To: Philip Levis CC: "roll@ietf.org" Subject: Re: [Roll] New Version Notification-draft-ietf-roll-minrank-hysteresis-of-07.txt Thread-Topic: [Roll] New Version Notification-draft-ietf-roll-minrank-hysteresis-of-07.txt Thread-Index: Ac0Wal3lZFHU8XUwQnuggZ2Lt9w6DwAdbA9w Sender: "roll-bounces@ietf.org" Content-Class: urn:content-classes:message Date: Tue, 10 Apr 2012 06:10:29 +0000 Message-ID: References: <3B42E04B-7DFB-4C42-83C5-4ED72B3AC8A6@cs.stanford.edu> List-Help: List-Subscribe: , List-Unsubscribe: , In-Reply-To: <3B42E04B-7DFB-4C42-83C5-4ED72B3AC8A6@cs.stanford.edu> Content-Language: en-US X-MS-Has-Attach: X-Auto-Response-Suppress: All X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Phil: It's not. If I switch a device with another from a different vendor I should expect the new device to interact properly with existing devices and I should expect globally a similar behavior in my network. That's what standards are for. RPL 3.7.1 gives strong directions to avoid greediness. You may allow to stray from that but that must be under control of the admin and you must give strong recommendations for the default behavior. Cheers, Pascal -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: lundi 9 avril 2012 17:46 To: Pascal Thubert (pthubert) Cc: roll@ietf.org Subject: Re: [Roll] New Version Notification -draft-ietf-roll-minrank-hysteresis-of-07.txt On Apr 8, 2012, at 10:00 AM, Pascal Thubert (pthubert) wrote: > Phil: > > It is an implementation decision as long as it does not lead to > interop issue or unwanted behavior, which is probably the case here. > RFC 6550 demands that a node can't stray from the best Rank as > computed amongst parents by more than MaxRankIncrease. > This 3 clauses do not seem to capture this that we are discussing do > not seem to capture this. > With (my reading of) the text as it stands, it seems that the > implementation has all freedom to select parents and then is given > rules to compute a Rank. > The resulting Rank could be anything if the parent set as no constraint. > > > In particular " The largest calculated Rank among paths through the > parent set, minus MaxRankIncrease" must be less that the Rank obtained > from the preferred parent, not the final computed Rank. > > > The node should: > 1) Compute the Ranks form its parent set. > 2) Determine a preferred parent as resulting with the lowest Rank > (using the computation described in the previous paragraph) > 3) Determine which parents generate a Rank that is between that lowest > Rank and MaxRankIncrease > 4) Pick a set of parents between those > > What do you think? This is an implementation decision. I can imagine other algorithms, e.g., where if the best Rank and next best Rank differ by more than MaxRankIncrease, the node chooses to advertise a worse Rank than the preferred parent provides. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_002_E045AECD98228444A58C61C200AE1BD802FCAE31xmbrcdx01ciscoc_-- From internet-drafts@ietf.org Mon Jun 4 05:59:20 2012 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 C0BFB21F87AA; Mon, 4 Jun 2012 05:59:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VlDIaKUTLY+f; Mon, 4 Jun 2012 05:59:20 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010E321F87A8; Mon, 4 Jun 2012 05:59:20 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120604125920.1150.29963.idtracker@ietfa.amsl.com> Date: Mon, 04 Jun 2012 05:59:20 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-13.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 12:59:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power= and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-13.txt Pages : 35 Date : 2012-06-04 This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-13.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl/ From d.sturek@att.net Mon Jun 4 06:23:19 2012 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 4C3C821F8691 for ; Mon, 4 Jun 2012 06:23:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[AWL=0.499, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8GP0azyNzSN4 for ; Mon, 4 Jun 2012 06:23:18 -0700 (PDT) Received: from nm26-vm4.bullet.mail.ne1.yahoo.com (nm26-vm4.bullet.mail.ne1.yahoo.com [98.138.91.186]) by ietfa.amsl.com (Postfix) with SMTP id 0609E21F86B7 for ; Mon, 4 Jun 2012 06:23:17 -0700 (PDT) Received: from [98.138.90.49] by nm26.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jun 2012 13:23:14 -0000 Received: from [68.142.200.225] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 04 Jun 2012 13:23:14 -0000 Received: from [66.94.237.114] by t6.bullet.mud.yahoo.com with NNFMP; 04 Jun 2012 13:23:14 -0000 Received: from [127.0.0.1] by omp1019.access.mail.mud.yahoo.com with NNFMP; 04 Jun 2012 13:23:14 -0000 X-Yahoo-Newman-Id: 614207.62106.bm@omp1019.access.mail.mud.yahoo.com Received: (qmail 996 invoked from network); 4 Jun 2012 13:23:14 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1338816194; bh=r3iq4KIIOKT8Q7gN+D5OVb44dkSSalMeCv2BB9NKO3Y=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=cCXlDfjgVJai7WV3OtQdq118p0iQGoq11JEm8bOUmfxLhg3wk9icZlcqG5d5EsEeHTYlNkKwHX+2gqu31VfYcvvH6mHTnWLPBoIhTWCVcHD/UBlNywylMYQQCPo5BhuUzXWNoT3HnECK13ou6CtRpJcp5u7VA5IDwBRlRUFXuuU= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: iaAr41sVM1l2VTKr8SdvAanE45s1CkHA6zqf54rCyFi33EG jULU31AgAnVxAWXLI8dlo3W6vMYmrvj0kColhMkX3E4NDc2M3DyldhkBKaqn IKhpF8x0xOuu0usx2AQRevORVRUb9KDbgPie9ULhGwn88_peF92.zKNhSH1F 7WL1yqG5jglx0imXuCgH096tbV1O_9JH6s7RyBWyp_lqQWfdT7ZmtZOsJGZm JkhlL997b.oYlab8Ch7xCDz4Xqs8H32_5wg1yV4PcnnJuFnHu8T7.VDg1ETc DfP5Jd5GSWyq1pzJmcVWRwjA3kETshBkyt5hWiiVYSGKbihQXgIaGpbI0AGm MuTDxojnVjOWq25HzNZ7pVccbdm_162MUDtmJflep3aUB9lbjEJ_iZIvraph Js.hYErJq4BQ2VZQ9GtZTyq1SmbWZ2XhQ0fA- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.198] (d.sturek@69.105.139.102 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 04 Jun 2012 06:23:13 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Mon, 04 Jun 2012 06:20:42 -0700 From: Don Sturek To: "Pascal Thubert \(pthubert\)" , Ralph Droms , Michael Richardson Message-ID: Thread-Topic: [Roll] knowing which multiple metrics matter: MRHOF related questions In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "roll@ietf.org" Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 13:23:19 -0000 Hi Pascal, Having a range of reserved well known OF's from IANA makes sense. This is the minimum requirement to make MrHOF work. If we do intend to support flexibility in deployment (eg industry groups which may define their own OF's) then we would want a way to define on demand OF's. Don On 6/3/12 11:38 PM, "Pascal Thubert (pthubert)" wrote: >Hi: > >I agree with Ralph that there is a choice to be made whether this OF is >one OF or a generic OF that is instantiated by metric (a toolbox). > >If it is a specific OF, it is fair to require from IANA a specific OF >number (1 in the IANA section) but then we can expect that all >implementations of this OF will behave the same. > >Here, the behavior will vary quite dramatically with some implementation >decisions (see the unresolved issue in the attached mail) and metric >choices (Ralph's point here). > >As it goes, we could figure that MrHof is not one but many OFs. If >that's so then the OF number for the local variation should be assigned >consistently for a deployment as opposed to globally significant. There >could in fact be multiple MrHof in a same deployment. > >My point is somewhat analogous to the UDP ports. Should we have a range >for IANA reserved well known OFs, and then a range that would be assigned >on demand? > >Cheers, > >Pascal > >-----Original Message----- >From: Ralph Droms [mailto:rdroms.ietf@gmail.com] >Sent: vendredi 1 juin 2012 21:47 >To: Michael Richardson >Cc: roll@ietf.org; Pascal Thubert (pthubert) >Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related >questions > > >On May 25, 2012, at 12:31 PM 5/25/12, Pascal Thubert (pthubert) wrote: > >> Hi Michael: >> >> I think RPL does not want to take party there. The OF is a piece of >>logic to tie metrics and policies together. >> As such, there could be multiple metrics as long as there is good logic >>to tie them in. for instance one would look at optimizing metric A >>within contraints as expressed by metric B and the OF model will allow >>that. >> >> OTOH, it a flows requires a certain optimization (say per one metric) >>and another requires something different, then certainly you want two >>instances. >> >> So ... it depends! >> >> Pascal >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> Of Michael Richardson >> Sent: vendredi 25 mai 2012 16:54 >> To: roll@ietf.org >> Subject: [Roll] knowing which multiple metrics matter: MRHOF related >> questions >> >> >> Ralph asked some questions a few days ago. >> His originally DISCUSS is at: >> >> http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of/ >> ballot/ >> >> This was my reply. I am particularly interested in replies from >> Pascal, Anders and Mukul about my assertion about how we would never >>pick RPL instances by metrics; that they would in fact be seperate RPL >>Instance numbers and DODAG values, and that these things would >>provisioned by the network installer. >> >> ==== >> >> I'm going to reply to your comments in a different order than you asked >>them, because I think question #3 is most important, and the rest fall >>out of it. >> >>>>>>> "Ralph" == Ralph Droms writes: >> Ralph> 3. Based on (1) and (2), would configuration and selection >> Ralph> issues be ameliorated if the five candidate selected metrics >> Ralph> were each asssigned a separate objective function? Use of a >> Ralph> separate OF code point for each of the five possible selected >> Ralph> metrics would allow multiple RPL instances. >> >> I think that it's important to understand that ROLL has a whole palette >>of things that need to be provisioned by the "network operator". >> >> In contrast to the situation of ISPs and customers, where the ISP is >> the network operator, ROLL networks are more like highly orchestrated >> Enterprises: "all your host belong to us" >> >> so, when we write something like: >> "The metric chosen by the network operator to use for path >> selection." >> in section 2, we really mean: >> "The metric chosen by the network operator and provisioned into >> the node when the firmware was flashed to use for path selection." > >OK, so I get that the model is that MRHOF is a toolbox, where the >specific tools are chosen when the device is flashed. In that case, I >think some additional review might be needed to ensure that the MRHOF >spec is internally consistent with that point of view. > >As one example, I think the "selected metric" should be called out >explicitly somewhere in section 5 and included in the list of configured >parameters in section 6.1. > >As another example, I read this text from section 3: > > Rank is undefined for these node/link metrics: node state and > attributes, throughput, and link color. If the rank is undefined, > the node must join one of the neighbors as a RPL Leaf node according > to [RFC6550]. > >to mean that if the selected metric is one of the metrics for which rank >is undefined, the node joins as a lead node. But, how can that happen if >the selected metric is chosen by the network operator? > >> Ralph> 1. Why is one objective function defined for several potential >> Ralph> metrics? The details of MRHOF seem to preclude the >> Ralph> establishment of several RPL instances in an LLN, each of which >> Ralph> uses MRHOF with a different selected metric. >> >> If one had many different RPL Instances, then we would have different >> RPL Instance numbers in the RPL header. There can be many different >> DODAG ("destinations") created within that instance. The instances >>share a common set of (provisioned) parameters. > >How does a node know which RPL Instance number maps to which selected >metric? > >One way would be to specify that a node advertise ONLY the selected >metric for the RPL Instance in a DIO. > >> (To put it into DHCP terms: if we have multiple DHCP servers on a link, >> then one would expect them to all offer IP addresses in the same subnet. >> If one wanted to have addresses in different subnets, and let the host >> pick between them, then, one would need different layer-2s: different >> VLANs or ESSIDs, or... ) >> >> If you feel that RPL is rather schizo about provisioning vs >>configuration, then I agree. It's not always clear to me why some >>things are advertised while others are provisioned. >> >> In BGPv4, we calculate metrics by adding AS entries in the path. >> (It's always additive), and we add at least one AS entry to the path. >> One can AS-stuff and add more, but proper operation of BGP does not >>depend upon the exact algorithm used. >> >> Finally, my impression is that how the various metrics are used >>(singly, or in some combination) to calculate Rank Increase is a >>question of further research, experimentation, and trade secret. > >Well, OK, but for the purposes of the MRHOF spec, it seems pretty clear >to me there is one selected metric that is used across all nodes as a >strictly additive path cost computation. > >> So long as the Rank increases, and a node does not flap between >>parents, the exact details do not matter. Each node can do it's parent >>selection based upon the available metrics on it's own. It advertises >>the metrics it has. >> >> I hope the authors will correct me if I'm completely off here. > >I read the spec to require a single selected metric across the entire RPL >Instance. > >- Ralph > >> >> >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From prvs=49575ab5a=mukul@uwm.edu Mon Jun 4 07:02:20 2012 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 6332921F8864 for ; Mon, 4 Jun 2012 07:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y7tjOZIp-i1Z for ; Mon, 4 Jun 2012 07:02:18 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id E8FF021F8863 for ; Mon, 4 Jun 2012 07:02:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EADi/zE9/AAAB/2dsb2JhbABEhU6xeQEBBSNLFw8RBAEBAwINbAgGiB4LlWiOPokOiQSBI4luG4V1A4hAjFuPdoJ+gTgj Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id E649A499101 for ; Mon, 4 Jun 2012 09:01:20 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyFE25bfrXhD for ; Mon, 4 Jun 2012 09:01:20 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 7EB3B1FD0C7 for ; Mon, 4 Jun 2012 09:01:20 -0500 (CDT) Date: Mon, 4 Jun 2012 09:01:20 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <2124441382.584149.1338818480401.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20120604125920.1150.29963.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-13.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 14:02:20 -0000 Hi all This version takes are of the comments I received during the last call. The changes over the previous version are as follows: 1) Removed sequence number from Data Option. Also, the origin is prohibited from changing the Data Option during a route discovery. Same goes for target (for the Data Option inside the DRO). The main text carrying this change (Section 7.2) is: "If the Origin chooses to include a Data Option inside its DIO, it MUST include the same Data Option in all its future DIO transmissions for this temporary DAG. An Intermediate Router MUST NOT modify the Data Option received inside a parent's DIO and MUST include this Data Option in all its future DIO transmissions for this temporary DAG. The same is true for a Target that needs to propagate the DIOs further (required when the route discovery involves multiple Targets). If a Target chooses to include a Data Option inside a DRO, it MUST include the same Data Option in all retransmissions of this DRO message and MUST NOT include a different Data Option in any other DRO messages it generates for this route discovery. Also, an Intermediate Router, which needs to forward a received DRO message further, MUST include in the forwarded message a verbatim copy of the Data Option found inside the received message. " 2) Clarified the usage and rules concerning RIO/PIO in P2P mode DIOs (Section 6.1). The relevant new text is: P2P mode DIO: "MAY carry one or more Route Information Options [RFC6550]. In the context of P2P-RPL, a Route Information Option advertizes to the Target(s) the Origin's connectivity to the prefix specified in the option. o MAY carry one or more Prefix Information Options subject to the usage and rules specified in Section 6.7.10 in [RFC6550]. " Thanks Mukul ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Monday, June 4, 2012 7:59:20 AM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-13.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-13.txt Pages : 35 Date : 2012-06-04 This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-13.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-13.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From trac+roll@trac.tools.ietf.org Mon Jun 4 07:11:08 2012 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 685DA21F8745 for ; Mon, 4 Jun 2012 07:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 69obGTp7Dnkw for ; Mon, 4 Jun 2012 07:11:07 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id DC36F21F8762 for ; Mon, 4 Jun 2012 07:11:06 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SbXzq-00086Z-Sk; Mon, 04 Jun 2012 10:11:02 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Mon, 04 Jun 2012 14:11:02 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/100 Message-ID: <055.3565d9fe3bf76ad0c8fe6519c2c7aa2f@trac.tools.ietf.org> X-Trac-Ticket-ID: 100 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #100: Can P2P-RPL be used to repair broken DAO routes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 14:11:08 -0000 #100: Can P2P-RPL be used to repair broken DAO routes Resolution: Yes it can but it will be an overkill. Supporting the whole P2P-RPL apparatus for this particular reason only may not be a good idea. Need a separate mechanism to solve this problem. Discussion: ---------------- [Joseph] Section 12: ..In general, P2P-RPL operation does not affect core RPL operation.." I think this is unfortunate as P2P can be used to fix issues with core rpl. For example, in core RPL, there is no way to repair a downward route until the actual Target sends another DAO, which can take a long time. It would be very nice if the DoDag root can use P2P-RPL to discover a route to a Target node that is unreachable and then use the resulting source route as the downward route. [Mukul] What the text you quoted means is that it does not break core RPL operation. P2P-RPL can certainly be used in the manner you specified. The root of a global DODAG can certainly use P2P-RPL to discover a source route to any target. Just that it will involve creation of a separate temporary DAG. If you want to do this route discovery within the scope of the existing global permanent DAG, it can be done but needs to be written up in a separate document. I dont think this provision should be inside P2P-RPL document. This is because, for RPL deployments that would not otherwise support P2P-RPL, it may be more efficient to simply use an RPL Target Option inside a DIO to trigger DAOs that would allow desired route to be discovered. Ofcourse, this needs to be written up to (since currently Target Option cannot sit inside a non-P2P mode DIO). -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Mon Jun 4 07:11:20 2012 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 816AD21F87C5 for ; Mon, 4 Jun 2012 07:11:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6NBMAXRUyfQU for ; Mon, 4 Jun 2012 07:11:19 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id D086321F8745 for ; Mon, 4 Jun 2012 07:11:19 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SbY07-00087p-0I; Mon, 04 Jun 2012 10:11:19 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Mon, 04 Jun 2012 14:11:18 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/100#comment:1 Message-ID: <070.97c542312792c86ea3650e3907b28e8f@trac.tools.ietf.org> References: <055.3565d9fe3bf76ad0c8fe6519c2c7aa2f@trac.tools.ietf.org> X-Trac-Ticket-ID: 100 In-Reply-To: <055.3565d9fe3bf76ad0c8fe6519c2c7aa2f@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #100: Can P2P-RPL be used to repair broken DAO routes X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 14:11:20 -0000 #100: Can P2P-RPL be used to repair broken DAO routes Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: [Joseph2] Thanks for the clarification. I agree with your suggestion to consider this as subject for a separate document. [Mukul2] Thanks Joseph. I guess this issue is closed too as far as P2P-RPL is concerned. -- -----------------------------------+---------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: closed Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Mon Jun 4 07:12:12 2012 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 40B9721F8889 for ; Mon, 4 Jun 2012 07:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzFpJ1-XZkHT for ; Mon, 4 Jun 2012 07:12:11 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 6D47D21F8888 for ; Mon, 4 Jun 2012 07:12:11 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SbY0w-0008CQ-O6; Mon, 04 Jun 2012 10:12:10 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Mon, 04 Jun 2012 14:12:10 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/101 Message-ID: <055.51e9453239490c60e24001d3e8c729b3@trac.tools.ietf.org> X-Trac-Ticket-ID: 101 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #101: What purpose RIO/PIO serve in a P2P mode DIO? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 14:12:12 -0000 #101: What purpose RIO/PIO serve in a P2P mode DIO? Discussion: ----------- [Joseph1] Section 6.1: "...A P2P-DIO MAY carry one or more RIO and PIO options..." I am not sure how these options should be used by the DAG members. Later on, in 9.1, it says that "..the temporary DAG must not be used to route packets....". So what is the purpose of RIO and also PIO ? [Mukul1] The RIO would advertize to the target(s) the origin's connectivity to the specified prefix. Regarding PIO, I would very much like to allow P2P mode DIOs to carry PIOs to propagate prefixes for address selfconfiguration (i.e. have A flag set). I think we could forbid setting the R flag to one in a PIO carried in a P2P mode DIOs. Regarding the L flag, I think we could allow a P2P mode DIO to carry a PIO with L flag set subject to the following rules in RFC 6550: <...> [Joseph2] The RIO/PIO information is sent by the Origin to propagate its connectivity and prefix information. However, the route is established towards the Target. So I don’t understand why the Origin information is relevant .. [Mukul2] Here is some relevant text from Section 9.3: "A router SHOULD discard a received P2P mode DIO with no further processing if it does not have bidirectional reachability with the neighbor that generated the received DIO. Note that bidirectional reachability does not mean that the link must have the same values for a routing metric in both directions. A router SHOULD calculate the values of the link-level routing metrics included in the received DIO taking in account the metric's value in both forward and Backward directions. Bidirectional reachability along a discovered route allows the Target to use this route to reach the Origin. In particular, the DRO messages travel from the Target to the Origin along a discovered route. " So, the target can certainly use a discovered route as a source route to reach the origin. The backward direction route may not meet desired routing constraints but does provide a way to reach the origin. So, it may be useful for the target to know what destination prefixes can be reached via the origin. In fact, it makes sense to allow the target to include one or more RIOs in its DRO to let origin know what destination prefixes could be reached via the target. Regarding the PIO, I think the most critical need is to allow the propagation of address self-configuration prefixes via P2P mode DIOs. These prefixes can be used not only by the target but also the other nodes that join the temporary DAG. I am not too sure about allowing PIOs with L flag set inside the P2P mode DIOs. Would certainly like to hear your views on this. [Joseph3] Thanks for the clarification. For the PIO flags, I think the settings must not contradict the RPL spec. So I would add the same restrictions here ( i.e. L bit must not be set ). [Mukul3] So I guess I would simply refer to RFC 6550 regarding how PIOs might be used in P2P-RPL. I will also clarify that the RIO would advertize to the target(s) the origin's connectivity to the specified prefix. -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Mon Jun 4 07:12:45 2012 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 AEA8B21F8887 for ; Mon, 4 Jun 2012 07:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5AJ3PMlqopB for ; Mon, 4 Jun 2012 07:12:45 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 29C1F21F8885 for ; Mon, 4 Jun 2012 07:12:45 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SbY1U-0008EH-5J; Mon, 04 Jun 2012 10:12:44 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Mon, 04 Jun 2012 14:12:44 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/101#comment:1 Message-ID: <070.d973cf79d223847a740d01f596c57bc8@trac.tools.ietf.org> References: <055.51e9453239490c60e24001d3e8c729b3@trac.tools.ietf.org> X-Trac-Ticket-ID: 101 In-Reply-To: <055.51e9453239490c60e24001d3e8c729b3@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #101: What purpose RIO/PIO serve in a P2P mode DIO? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 14:12:45 -0000 #101: What purpose RIO/PIO serve in a P2P mode DIO? Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: RIO would advertize to the target(s) the origin's connectivity to the specified prefix. PIO serves same purpose in P2P-RPL as in core RPL, mainly it serves as a tool for address self-configuration. -- -----------------------------------+---------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: closed Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Mon Jun 4 07:15:57 2012 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 0EABB21F889D for ; Mon, 4 Jun 2012 07:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17hbeQZJrKuH for ; Mon, 4 Jun 2012 07:15:56 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 44EA721F889B for ; Mon, 4 Jun 2012 07:15:56 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SbY4Z-0001UP-DC; Mon, 04 Jun 2012 10:15:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Mon, 04 Jun 2012 14:15:55 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/102 Message-ID: <055.0400b84aef3418e790354e422e9667aa@trac.tools.ietf.org> X-Trac-Ticket-ID: 102 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #102: Why have a Data Option in P2P-RPL. Why have a sequence number in the data option? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 14:15:57 -0000 #102: Why have a Data Option in P2P-RPL. Why have a sequence number in the data option? Discussion: ----------- [Joseph] Section 9.4 Bullet 1: Under what conditions would a router receive the same DIO and a Data- Option with higher sequence number? I assume that only the Originator can include a Data-Option ? Same question also arises for section 9.5 ( para1 ) [Mukul] Yes, only the origin can include a data option for delivery to the target(s). In theory, the origin might have newer data to convey to the target(s) while the route discovery is still going on. Sequence numbers accounts for that possibility. Note that Data option did not have a sequence number earlier (before the first LC). Then, Pascal raised the possibility what if origin changes the data option. How would intermediate routers and target know that this is the newer data? Hence, we introduced the sequence number. [Joseph2] I don’t think the Origin should able to this. In fact, the Origin must not make any changes to the contents of the DIO and retransmit it without updating the version number. If the Origin wants to send data, it should simply wait until the p2p route is setup and then use it. The whole idea of sending UDP Data messages in the ICMP message payload itself doesn’t seem quite right. It is also not simple from an implementation perspective to make this kind of cross layer interactions. [Mukul2] I think that implementation concerns (regarding sending UDP data inside ICMP message) might be valid and would like to hear more opinions in this regard. But, I also think that LLNs need cross layer interactions and this experimental RFC might be the perfect place to check if this works or not. Certainly, the need to piggyback data on route discovery packets is real in many LLN applications. In my opinion, we should allow this unless there are overpowering reasons why this is a bad idea. [Jakob2] I understand the concern about the Data Option and cross-layer interactions. I also believe that it is a sensible and necessary design choice for home automation networks. Home automation frequently requires low-latency messages to be delivered to targets for which the originator has no route. An example is a remote light switch that needs to control a relocated lamp. The fastest way to do that in a reactive routing scheme is to piggyback the data on the routing packets. The other option would be to use simple flooding, with no trickle control, which would involve generating a huge number of packets. Piggybacking data on routing packets helps avoid generating extra packets. Home automation networks do not need to update the Data Option while a discovery is in progress. I am okay with removing the sequence numbers if they add too much complexity. [Joseph3] If we agree to remove the sequence numbers from the data option ( and, consequently, require that the Origin must not modify the data-option during a transmission ), that would be acceptable to me. [Mukul3] As Jakob mentioned there is no need for the origin to modify a data option during a route discovery. So I guess I can certainly make this change in P2P-RPL. Sequence numbers were introduced in Data option in response to Pascal's question whether it was possible for the origin to modify the data option during a route discovery. I should have answered no right then. :( I guess we could consider this item closed. -- -----------------------------------+--------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: new Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Keywords: -----------------------------------+--------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Mon Jun 4 07:16:14 2012 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 3453A21F88A1 for ; Mon, 4 Jun 2012 07:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cjcBQOhKk1lP for ; Mon, 4 Jun 2012 07:16:13 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id AF6C021F889D for ; Mon, 4 Jun 2012 07:16:13 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SbY4q-0001Y1-Ug; Mon, 04 Jun 2012 10:16:12 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Mon, 04 Jun 2012 14:16:12 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/102#comment:1 Message-ID: <070.760e3f2cf470c2b2b4c45f05e6975edc@trac.tools.ietf.org> References: <055.0400b84aef3418e790354e422e9667aa@trac.tools.ietf.org> X-Trac-Ticket-ID: 102 In-Reply-To: <055.0400b84aef3418e790354e422e9667aa@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #102: Why have a Data Option in P2P-RPL. Why have a sequence number in the data option? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 14:16:14 -0000 #102: Why have a Data Option in P2P-RPL. Why have a sequence number in the data option? Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: Resolution: 1) Data Option is a sensible and necessary design choice for home automation networks. Home automation frequently requires low-latency messages to be delivered to targets for which the originator has no route. The fastest way to do that in a reactive routing scheme is to piggyback the data on the routing packets. The other option would be to use simple flooding, with no trickle control, which would involve generating a huge number of packets. Piggybacking data on routing packets helps avoid generating extra packets. 2) There is no need for the origin to change the data option during a route discovery. So there is no need for a sequence number. Further, P2P- RPL would explictly forbid an origin to change the data option during a route discovery. -- -----------------------------------+---------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: closed Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------- Ticket URL: roll From mcr@sandelman.ca Mon Jun 4 07:34:04 2012 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 8C38D21F889C for ; Mon, 4 Jun 2012 07:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.916 X-Spam-Level: X-Spam-Status: No, score=-1.916 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i9waz0Vmgy+t for ; Mon, 4 Jun 2012 07:33:59 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id EA1BC21F86FD for ; Mon, 4 Jun 2012 07:33:58 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 1F73A848A; Mon, 4 Jun 2012 10:31:55 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id B7FE39823C; Mon, 4 Jun 2012 10:33:57 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B389098239; Mon, 4 Jun 2012 10:33:57 -0400 (EDT) From: Michael Richardson To: Mukul Goyal In-Reply-To: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 04 Jun 2012 10:33:57 -0400 Message-ID: <14353.1338820437@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 14:34:04 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mukul" =3D=3D Mukul Goyal writes: Mukul> Hi Michael Mukul> This would be my response to the questions Ralph asked. Thanks for this message. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT8zHVYqHRg3pndX9AQIhygQAqBnPEGetwG7cLqEq7yEr+fFnRY8YynUY CR13A/NyYYaMBodcXq7m3iU/3ekcBbZSX2nkEmCq6Pldy7dgCm6GSy1zVgg60tFH wIb2A/ncwbf0tLMmlzws5sTdvdwOzV8gJmMcbAa5kOhtDlmAKmio2Qa2AVCbLFvw jVhvyXl5fwI= =aoG/ -----END PGP SIGNATURE----- --=-=-=-- From trac+roll@trac.tools.ietf.org Mon Jun 4 08:08:16 2012 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 AFD7321F8890 for ; Mon, 4 Jun 2012 08:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Tlx3boc2bnk for ; Mon, 4 Jun 2012 08:08:16 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6BB21F8864 for ; Mon, 4 Jun 2012 08:08:15 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SbYtB-0008G9-KD; Mon, 04 Jun 2012 11:08:14 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com X-Trac-Project: roll Date: Mon, 04 Jun 2012 15:08:12 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/98#comment:2 Message-ID: <070.deb5262e37076e025942dff4c1172e93@trac.tools.ietf.org> References: <055.31669a0f4b146ab9900adac19f97cc84@trac.tools.ietf.org> X-Trac-Ticket-ID: 98 In-Reply-To: <055.31669a0f4b146ab9900adac19f97cc84@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #98: Who decides what metrics go in the metric container inside the Measurement Request? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 15:08:16 -0000 #98: Who decides what metrics go in the metric container inside the Measurement Request? Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: From: "Philip Levis" To: "Mukul Goyal" Cc: "roll" Sent: Wednesday, May 9, 2012 7:31:39 PM Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-05.txt The new draft addresses all of my comments. The overview section is much clearer and unambiguous. Phil On May 9, 2012, at 4:27 PM, Mukul Goyal wrote: This version takes care of ticket #98 (created in response to LC comment by Phil Levis) and has the following changes: 1) Updated the overview section. This section now has better explanation of the mechanism and explicitly clarifies the following: 1.1) The route being measured is from the origin to the target. 1.2) The origin decides what metrics are measured. 2) Section 4 (Originating a Measurement Request) now clearly says: "The Origin MUST also include the routing metric objects of interest inside one or more Metric Container options inside the MO. " 3) Section 5 (Processing a Measurement Request at an Intermediate Router) now clearly says: "An Intermediate Router can only update the existing metric objects and MUST NOT add any new routing metric object to the Metric Container. An Intermediate Router MUST drop the MO if it cannot update a routing metric object specified inside the Metric Container." 4) Updated the IANA section to include the correct language as per RFC5226. These modifications should remove the perceived ambiguity (regarding who decides which metrics would be measured) reported in Ticket #98. Thanks Mukul -- -----------------------------------+---------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: closed Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------- Ticket URL: roll From prvs=49575ab5a=mukul@uwm.edu Mon Jun 4 08:27:23 2012 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 E32A421F88A2 for ; Mon, 4 Jun 2012 08:27:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=0.208, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZamRao0OVqUJ for ; Mon, 4 Jun 2012 08:27:23 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4E14621F8899 for ; Mon, 4 Jun 2012 08:27:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAEjSzE9/AAAB/2dsb2JhbABEhU6xfQEBBSNWDA8RBAEBAwINGQJRCBmICwukLYkUiQSBI4luJIJWggSBEgOIQIxbgQ+OZ4J+ Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id DE26E12E3BB; Mon, 4 Jun 2012 10:26:34 -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 w1IcbgFFMtWJ; Mon, 4 Jun 2012 10:26:34 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 8DB7612E3AE; Mon, 4 Jun 2012 10:26:34 -0500 (CDT) Date: Mon, 4 Jun 2012 10:26:34 -0500 (CDT) From: Mukul Goyal To: roll@ietf.org Message-ID: <1870397086.585705.1338823594421.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <070.a64a44b40e6b8c9748cd7b59e581cd55@trac.tools.ietf.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: mcr@sandelman.ca Subject: Re: [Roll] [roll] #88: Data option and ULP X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 15:27:24 -0000 Michael Could you please close this ticket. I fixed the IANA text long ago. Cheers Mukul ----- Original Message ----- From: "roll issue tracker" To: mukul@UWM.EDU, jpv@cisco.com, mcr@sandelman.ca Cc: roll@ietf.org Sent: Sunday, May 6, 2012 2:14:59 PM Subject: Re: [roll] #88: Data option and ULP #88: Data option and ULP Comment (by mcr@=E2=80=A6): The resolution in -10 is acceptable, but is not complete. "The other values are reserved at present." is not enough. We need an amending formula as part of the IANA instructions. I suggest Standards Action. http://tools.ietf.org/html/rfc5226 section 4.2 gives details. IANA also asks that you refer to the registry by URL that you want to allocate. --=20 -----------------------------------+---------------------- Reporter: jpv@=E2=80=A6 | Owner: mukul@=E2=80=A6 Type: defect | Status: closed Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------- Ticket URL: roll From prvs=49575ab5a=mukul@uwm.edu Mon Jun 4 08:28:27 2012 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 B27D721F8898 for ; Mon, 4 Jun 2012 08:28:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TnxZPMEQUMRi for ; Mon, 4 Jun 2012 08:28:27 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 139E321F85D3 for ; Mon, 4 Jun 2012 08:28:27 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAC/TzE9/AAAB/2dsb2JhbABEhU6xfQEBAQQBAQEgSwsMIAQBAQMCDRkCKSgIBhMJiAILpCuJFIkEgSOJbhsJhFqBEgOIQIxbj3aCfg Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 9405B1FD0C7; Mon, 4 Jun 2012 10:28:26 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ocsmjL-tXGhI; Mon, 4 Jun 2012 10:28:26 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 5D845499101; Mon, 4 Jun 2012 10:28:26 -0500 (CDT) Date: Mon, 4 Jun 2012 10:28:26 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <905873004.585769.1338823706319.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <326961085.315388.1336495338781.JavaMail.root@mail17.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: Michael Richardson Subject: [Roll] Ticket #88 Fwd: I-D Action: draft-ietf-roll-p2p-rpl-12.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 15:28:27 -0000 p2p-rpl-12 had the resolution of this ticket. This version onwards the draft has the correct IANA text. Thanks Mukul ----- Forwarded Message ----- From: "Mukul Goyal" To: "roll" Sent: Tuesday, May 8, 2012 11:42:18 AM Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-12.txt This version includes the correct IANA-related text that resolves ticket #88 recently reopened by Michael. Version 11 already included the text in response to discussion with Federico and suggestion by Adrian. This version includes one additional sentence (at the very end of Section 9.2) that applicability statements specifying the use of P2P-RPL MUST provide guidance for setting Trickle parameters, particularly Imin and the redundancy constant. I dont think there is a need for a more elaborate template for the applicability statements to follow. Thanks Mukul ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Tuesday, May 8, 2012 11:35:23 AM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-12.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-12.txt Pages : 34 Date : 2012-05-08 This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-12.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From trac+roll@trac.tools.ietf.org Mon Jun 4 09:06:15 2012 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 227BF21F88B7 for ; Mon, 4 Jun 2012 09:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DmrQb5DQYYcJ for ; Mon, 4 Jun 2012 09:06:14 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 062F421F88A7 for ; Mon, 4 Jun 2012 09:06:13 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SbZn4-0000iL-BU; Mon, 04 Jun 2012 12:05:58 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Mon, 04 Jun 2012 16:05:58 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/88#comment:4 Message-ID: <070.3fc238d20d830d06d7c34f6aed817a80@trac.tools.ietf.org> References: <055.6ee5f9af0660881f34d198ae081e0ce4@trac.tools.ietf.org> X-Trac-Ticket-ID: 88 In-Reply-To: <055.6ee5f9af0660881f34d198ae081e0ce4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #88: Data option and ULP X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 16:06:15 -0000 #88: Data option and ULP Changes (by jpv@…): * status: reopened => closed * resolution: => fixed Comment: ----- Forwarded Message ----- From: "Michael Richardson" To: "Mukul Goyal" Cc: "roll" Sent: Wednesday, May 9, 2012 2:53:10 PM Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-12.txt "Mukul" == Mukul Goyal writes: Mukul> This version includes the correct IANA-related text that Mukul> resolves ticket #88 recently reopened by Michael. Thank you! -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ -- -----------------------------------+---------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: closed Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------- Ticket URL: roll From rdroms.ietf@gmail.com Mon Jun 4 09:31:45 2012 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 DE42A21F88BC for ; Mon, 4 Jun 2012 09:31:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 14qywpbhY8xa for ; Mon, 4 Jun 2012 09:31:45 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id C99E221F866D for ; Mon, 4 Jun 2012 09:31:44 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2919467vbb.31 for ; Mon, 04 Jun 2012 09:31:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=oNlEp4oc5kCsqVOO6r8+13FDlPo5JgYxV2z4Ouo+pCU=; b=EB/GRIzyoT7z2nG44OOEI82PPaEF7nro5+Vsi755VCRw1Q7c6/fcCsvHVxa3etC0FO uiKI8NWrcq9qFNG1cEv5SB0hQcMInH2U/WEvXb9ZyMZo9j/mSyOlS+zGGtHMtsSAk0FA T+XP+7Irr1mbzEpfce8p+LVOHLheQ+71vKJ9XxgnrK2FcOzA2vGPMpmpSPlbLHbOcObe tnRqHTqp4xd+zJhvmx+IPKOCBkEWw2nyo4BvPfZ6OLiFrNLjQaIoLqMpRf9RqC3gwob0 zRwaYmAxneJw2lOwfp0apUMxTsOMwVOM+HMyaPT+Ic39OrBjpJDwEMBjD4d47k2JN5zg Xm+w== Received: by 10.52.73.42 with SMTP id i10mr11086755vdv.116.1338827499033; Mon, 04 Jun 2012 09:31:39 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id o15sm18014398vdi.15.2012.06.04.09.31.36 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jun 2012 09:31:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Mon, 4 Jun 2012 12:31:34 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1278) Cc: roll , Stiemerling Martin , Michael Richardson , Haberman Brian Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 16:31:46 -0000 On May 26, 2012, at 1:26 AM 5/26/12, Mukul Goyal wrote: > Hi Michael >=20 > This would be my response to the questions Ralph asked. >=20 > Thanks > Mukul Mukul - thanks for responding to my questions... > [Ralph] > 1. Why is one objective function defined for several potential > metrics? The details of MRHOF seem to preclude the establishment of > several RPL instances in an LLN, each of which uses MRHOF with a > different selected metric. >=20 > [Mukul] > It is certainly possible to establish multiple RPL Instances in an LLN = with MRHOF (or any other OF) as the OF. These RPL Instances may or may = not use different routing metrics. An RPL Instance is associated with = one particular OF as per RFC 6550. The OF converts the aggregated = routing metric values to a rank value. Whether a particular OF could = work with a particular metric depends on the OF. E.g. MRHOF = specification says that MRHOF only works with additive metrics. So, the = choice of routing metrics to be used in a particular DODAG (identified = by the DODAGID) inside a particular RPL Instance may depend on the = particular OF being used but, in general, the choice of OF and the = choice of routing metrics are separate/independent issues. My question here is why a single objective function "MRHOF" is defined = to use several different metrics. My understanding is that any specific = RPL instance will use one metric as its "selected metric" for MRHOF. = Another way to organize the objective functions would be to define a = different OF number for each metric, binding the OF number to the = selected metric. > [Ralph] > 2. How are the nodes in the RPL instance informed about the selected > metric? My understanding of RPL is that only the objective function > is included in the DIO received as an advertisement for a particular > RPL instance, which means a node can't know the selected metric for > that RPL instance and can't meaningfully decide among multiple RPL > instances all using MRHOF as the objective function. >=20 > As a followup to (1), if there were a way to encode the selected > metric for a RPL instance in the DAO, a node would be able to select > which RPL instance to use for a particular type of traffic. >=20 > [Mukul] > The root of a DODAG includes the selected metric objects in the Metric = Container Option(s) inside its DIO. The nodes that join this DODAG = include the same metric objects in their DIOs and so on. Thats how the = nodes come to know which routing metrics are in use in a particular = DODAG in a particular RPL Instance.=20 As I wrote above, my understanding is that a particular RPL instance = that specifies MRHOF will use one metric as the selected metric across = the entire RPL instance. Is it the case that a node includes only the = metric object for the selected metric in a DIO (or no metric object in = the case of ETX as the selected metric)? Does a receiving node infer = the selected metric for the RPL instance from the existence of a single = metric in the DIO or does a node need to be explicitly provisioned to = know the selected metric for each RPL instance? Are these details = specified in draft-ietf-roll-minrank-hysteresis-of-10? Or, am I confused about the binding between a DIO and a RPL instance? > [Ralph] >=20 > 3. Based on (1) and (2), would configuration and selection issues be > ameliorated if the five candidate selected metrics were each assigned > a separate objective function? Use of a separate OF code point for > each of the five possible selected metrics would allow multiple RPL > instances. >=20 > [Mukul] > Multiple RPL instances with same OF are already allowed. The whole = idea behind OF is to separate the rank selection logic from the routing = metrics. OK, but if multiple RPL instances use MRHOF, there is no way for a node = to determine which metric is the selected metric for the various RPL = instances. > [Ralph] > 4. Related to the above, I don't see anything in section 6 about > managing the selected metric. Don't all of the nodes that join a RPL > instance using MRHOF have to be configured to use the same selected > metric? >=20 > [Mukul] > Yes. As mentioned above, the root of a DODAG selects which routing = metrics would be used and includes these metric objects inside the = Metric Container inside the DIO. A node can join this DAG only if it = supports the routin metrics being used. You refer to "routing metrics". Isn't it the case that a specific RPL = instance uses only one metric as the selected metric across all nodes in = the RPL instance? Are the nodes configured in the "installer provisioning" (section 6.1) = or do nodes infer the selected metric from the metric included in the = DIO? > [Ralph] > 5. In section 3.2.2: >=20 > a > node MAY use a different objective function to select which of these > neighbors should be considered to have the lowest cost. >=20 > seems to contradict the statement in the Introduction that "all nodes > in a network use a common OF." Should "different objective function" > be replaced with "some other selection criteria?" >=20 > [Mukul] > That makes sense to me. OK. > [Ralph] > 6. In section 5, are the RECOMMENDED values appropriate for all > selected metrics or just for ETX? Are there any references that might > be cited that would give background on the working group experience > with ETX and the development of the recommended values? >=20 > 7. In section 6.1, why not "MUST support the DODAG Configuration > option?" I don't see any RFC 2119 requirements on the implementation > of the DODAG Configuration option (which would appera to be an > oversight), but I don't understand how a node can operate in a RPL > instance without, for example, being able to determine the Objective > Function used by that instance. >=20 > [Mukul] > That particular statement indeed sounds redundant to me. I think every = RPL implementation MUST understand the DODAG Configuration Option. OK. - Ralph From rdroms.ietf@gmail.com Mon Jun 4 09:36:25 2012 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 3FDD811E8080 for ; Mon, 4 Jun 2012 09:36:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E93qqBFlSCc0 for ; Mon, 4 Jun 2012 09:36:24 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 867CD11E8079 for ; Mon, 4 Jun 2012 09:36:24 -0700 (PDT) Received: by vcqp1 with SMTP id p1so2924161vcq.31 for ; Mon, 04 Jun 2012 09:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=sgxMLCwPLWLyNo34pZazHA3uZx4Z8BuDRRiNfDzZZeU=; b=YTrnA+450aMgBVdMYKKS35lSrwkUAfiF+lbRFudjm7oIy804rCy7tIt98ehnFa+3KY 2PGo1bDxkhKhR0Bc3qUlc177g1myOQhS+7pLkFg89rZq/YdjKaGMRxI9A9cc375onsEV kjFp/wP69un3QJT8PqF0Jf6YtjMG1lbbOW4w1pRbJ8C4EMNcy38XLb4UFgxv4FoSDWkG unnb4slTbohyIhzqlIB1zbUszhHdpMWfOBbm7Mr1EUI4hXz/5cPnm6PK06wwwGnBaafQ mvpiGDQ1xOyxYsi2aU8V5qlpqXshS/+c6LoOgnwH1ZNntDlIJUlohVgGFb8J3hTv5kpV J8ZA== Received: by 10.52.35.15 with SMTP id d15mr11260073vdj.128.1338827783901; Mon, 04 Jun 2012 09:36:23 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id ej4sm18054837vdb.0.2012.06.04.09.36.20 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jun 2012 09:36:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <669980998.521393.1338012053807.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Mon, 4 Jun 2012 12:36:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <599545E1-7B6A-4649-97F7-E28107C3ECF2@gmail.com> References: <669980998.521393.1338012053807.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal , Michael Richardson X-Mailer: Apple Mail (2.1278) Cc: roll , Stiemerling Martin , Haberman Brian Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 16:36:25 -0000 On May 26, 2012, at 2:00 AM 5/26/12, Mukul Goyal wrote: > Hi Michael >=20 > Here is my take: >=20 > [MCR] > - do the nodes of a DODAG have to use the same metrics to pick a = parent, > (and if so, how do they agree) > I think that they do not, so long as they use an algorithm (such as > MRHOF) which has certain properties. >=20 > [Mukul] > Yes, the nodes in a DODAG have to use the same metrics. Otherwise, it = is not possible for an OF to map the aggregated (from root till this = node) values of the metrics to a rank. "metrics" or "metric"? Can different nodes use different metrics in a = RPL instance that specifies MRHOF? I would think the answer is "no"; = i.e., all nodes in a RPL instance MUST use the same metric as the = "selected metric". > [MCR]=20 > - if we had multiple RPL instances in an LLN, using different metrics, > then we would have multiple RPL Instances and DODAGs. The different > set of metrics would not co-exist in the same RPL Instance. > [Mukul] > Not sure what does the first sentence mean. About the second, = different sets of metrics can certainly coexist in the same RPL = instance. An RPL Instance is associated with a particular OF but = different DODAGs in the RPL Instance can certainly use different routing = metrics. Perhaps I am confused. Do all the nodes in a single DODAG use the same = metric while nodes in different DODAGs (in the same RPL instance) can = use different metrics? I.e., for a RPL instance with tow DODAGs, all = the nodes in DODAG1 use ETX while all the nodes in DODAG2 use hop count? - Ralph >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "Michael Richardson" > To: "Pascal Thubert (pthubert)" > Cc: roll@ietf.org > Sent: Friday, May 25, 2012 2:29:49 PM > Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF = related questions >=20 >=20 >>>>>> "Pascal" =3D=3D Pascal Thubert <(pthubert)" > = writes: > Pascal> I think RPL does not want to take party there. The OF is a > Pascal> piece of logic to tie metrics and policies together. =20 >=20 > My question is: >=20 > - do the nodes of a DODAG have to use the same metrics to pick a = parent, > (and if so, how do they agree) > I think that they do not, so long as they use an algorithm (such as > MRHOF) which has certain properties. >=20 > - if we had multiple RPL instances in an LLN, using different metrics, > then we would have multiple RPL Instances and DODAGs. The different > set of metrics would not co-exist in the same RPL Instance. >=20 >=20 > --=20 > Michael Richardson , Sandelman Software Works=20= > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From rdroms.ietf@gmail.com Mon Jun 4 09:42:18 2012 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 9010111E808C for ; Mon, 4 Jun 2012 09:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_53=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xMnyZpppyI-7 for ; Mon, 4 Jun 2012 09:42:18 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D5D1311E8088 for ; Mon, 4 Jun 2012 09:42:17 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2927456vbb.31 for ; Mon, 04 Jun 2012 09:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=6R6wl4spJvqFkRWkzhJA44Og1ON5LwURd13xoEfwyUw=; b=vapBhj3C9q9bUiY3QYVaFQOS4W4a+1ak34H9sYhohXFMu0+RHi+W+1UQF9IRJK7TSr WEVNuGYREEqgzbjbWw9RTtgfQhpzDotjDvMjASToeqxuLMGMg0qY55IaR8QZ9+vEAqmy 0b9ihf3qXn5JVxzm9k85zlqaxFTldSK+OgzMtFhNgErQnnStbOlBTKJtNkmFDB/GNCAc ETd/fd03ekKhxgloBSq0TZzuiwAn+mApB9v4XcndtvvdcND2WyXb3uw14psrmtQyNIZj n6HUo08k7QCGDP5VKxjjwXIS5uGaLxIjJK8Z9hqCew8Bp0y7y+1OrTVFzI0yzjT9sm7n JT2g== Received: by 10.52.69.110 with SMTP id d14mr11132857vdu.124.1338828137375; Mon, 04 Jun 2012 09:42:17 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id g10sm18076301vdk.2.2012.06.04.09.42.15 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jun 2012 09:42:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Mon, 4 Jun 2012 12:42:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <12418.1337957631@marajade.sandelman.ca> <31164.1337974189@marajade.sandelman.ca> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1278) Cc: roll , Stiemerling Martin , Haberman Brian Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 16:42:18 -0000 On May 28, 2012, at 3:04 PM 5/28/12, Pascal Thubert (pthubert) wrote: > Hello Micheal >=20 >>>>>> "Pascal" =3D=3D Pascal Thubert <(pthubert)" > = writes: > Pascal> I think RPL does not want to take party there. The OF is a > Pascal> piece of logic to tie metrics and policies together. =20 >=20 > My question is: >=20 > - do the nodes of a DODAG have to use the same metrics to pick a = parent, > (and if so, how do they agree) > I think that they do not, so long as they use an algorithm (such as > MRHOF) which has certain properties. >=20 > [Pascal] The current spec requires that all players of an instance = play by the same rule, that is same OF, in order to guarantee the = expected result.=20 Well ... given the current definitions of OF, I would say that even = specifying the same OF across a RPL instance does not guarantee a = consistent result. OF0 allows pretty much any mechanism at all - within = some constraints on the range of the computed rank - so there are no = guarantees about how different nodes will compute their ranks under OF0. = If different nodes use a different metric under MRHOF, there will be no = guarantees of consistency for MRHOF. > The goal there was deeper than the OF, like same OF with same = parameterization. MRHOF is generic and allows various incarnations, = depending in the metrics; all those incarnations are to be seen as = different OFs WRT to RPL 's uniqueness rule. So, MRHOF+ETX is a different OF than MRHOF+link-quality? > Note that this rule is not for looplessness, the Rank would assure = that anyway. OK. > - if we had multiple RPL instances in an LLN, using different metrics, > then we would have multiple RPL Instances and DODAGs. The different > set of metrics would not co-exist in the same RPL Instance. >=20 > [Pascal] I think we agree. An instance can use multiple metrics bound = by some logic. But those metrics and that logic must be identical = throughout the instance.=20 > A different (set of) metric means a different OF even if MRHOF is = behind both. I'm not sure how to reconcile your first two sentences with the MRHOF = spec. As I read the MRHOF spec, any individual node uses a single = metric to compute its rank. I infer that all the nodes in a RPL = instance (using MRHOF) would use the same metric. I understand that other OFs might use a rank computation that combines = several metrics. Do I have it right that MRHOF uses a single metric? - Ralph >=20 > Cheers, >=20 > Pascal >=20 > --=20 > Michael Richardson , Sandelman Software Works=20= > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From rdroms.ietf@gmail.com Mon Jun 4 09:48:57 2012 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 4086C21F873B for ; Mon, 4 Jun 2012 09:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.499 X-Spam-Level: X-Spam-Status: No, score=-103.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuKwo-FXDQ-0 for ; Mon, 4 Jun 2012 09:48:56 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D50221F870E for ; Mon, 4 Jun 2012 09:48:56 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2932219vbb.31 for ; Mon, 04 Jun 2012 09:48:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=DzUFNM9Nw9IoCAvccM7hGdgZvf5gbQ3vOlgAosGDOt8=; b=sKhRwIh22Ry9q/lMDpyU7xfN1VRBhdof5CCexgEWiO5xgVkUR/L6DDOF+e/YUIAXZx GH/hh4wF6AATGcWDQInvK6cswUIA2SqjXsj2mLSImevfMST+cbIMbHU5bMZeJMfxvzRc EIHDAXINBVN50Ohvo3XC4Y9NWDQYFyDBloUkf2DGpYZvzVb5Q9FBMG1ttqrsq4T6vnxE tu0sbTIFvgwMAg1O1s3GDa2uLmU9y8GQqNKWdXx+ICG2u4yga0cGIrgtlyc5DWQN8dw2 865xbOfhMpJJ0wvPOCN5ITy+g7DS/ln1pjXTMS5puRAqSrqm15nrgxdK/pxYYiQOEp1w 3Lpg== Received: by 10.52.20.143 with SMTP id n15mr11094367vde.112.1338828535887; Mon, 04 Jun 2012 09:48:55 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id g10sm18101351vdk.2.2012.06.04.09.48.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jun 2012 09:48:54 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Ralph Droms In-Reply-To: <67497215-FAB5-4AC1-B5D0-7FB9963AF3B9@cisco.com> Date: Mon, 4 Jun 2012 12:48:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <943C0516-F78E-43FD-AECD-F66A8B930F21@gmail.com> <67497215-FAB5-4AC1-B5D0-7FB9963AF3B9@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1278) Cc: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, roll , Stiemerling Martin , Haberman Brian Subject: Re: [Roll] "Node energy" as a metric for MRHOF X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 16:48:57 -0000 On Jun 2, 2012, at 10:22 AM 6/2/12, JP Vasseur wrote: > Thanks Ralph. When you say "path cost based on node energy", you refer = to using a cumulative metric where node metric are inversely=20 > proportional to the remaining energy ? I am asking since there are = several approaches to compute the metric, it could be coupled with=20 > the remaining energy used as a constraint, =85 > Thanks. JP - I'm trying to relate the path cost computation in MRHOF using "node = energy" as the selected metric. I infer from section 3 and table 1 that = node energy is OK to use as the selected metric for MRHOF. I don't see = how simply adding node energy, defined as "estimated percentage of = remaining battery capacity" [RFC 6551], is viable as a metric for MRHOF. = If it is viable, I think the way in which it is used to compute path = cost and rank needs to be explained in more detail. - Ralph >=20 > JP. >=20 > On Jun 1, 2012, at 9:53 PM, Ralph Droms wrote: >=20 >> I came across a new puzzle while re-reading = draft-ietf-roll-minrank-hysteresis-of. >>=20 >> "Node energy" doesn't appear to be listed as an additive metric in = RFC 6551. Reading the description of the node energy metric, which = carries remaining battery capacity as a percentage of initial capacity, = I have no clue how a node using MRHOF would compute a path cost based on = node energy. Does node energy really fit as one of the metrics that = MRHOF can use? >>=20 >> - Ralph >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 From rdroms.ietf@gmail.com Mon Jun 4 10:12:02 2012 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 367A811E807F for ; Mon, 4 Jun 2012 10:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.524 X-Spam-Level: X-Spam-Status: No, score=-103.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b+LE0duTFHP7 for ; Mon, 4 Jun 2012 10:12:01 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 071A211E8079 for ; Mon, 4 Jun 2012 10:12:00 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2948094vbb.31 for ; Mon, 04 Jun 2012 10:12:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=IdQ3ixa5seVSUMDKzrMyUf167DZgkCpqHvnqbFfOWwA=; b=CvmQ8jpYqIq4j/Zq5czE2+DzXcYQPOq0Q87cRIBI812Ymr9iBx8d3g0/O1En1lpCX7 BZ4Y9s0PEhma4Q10tB//qsXsffT/sE2KQZTd84DfG/wX3tO/lhPPXSWQPYCWx3cO8FRu boY5knXZddGRvDLPi4h8IPRYyMtRspd2WjfwjzmCxBSZMi1Hhj4VH9B6/lsrzkAYfU53 AOD4mKKYauNMNElVkBVfKJdiqm9saY1BGXp+aqzYaPeYVseoC02bG0FsWxSN9WQjKSg6 dR+a2ThbSDvGoxoUdRXAYFhzD3rD3e3CIs75gSjxoKGa0QnrCHBgEqq90F1v+pPyRptv x7ww== Received: by 10.52.99.167 with SMTP id er7mr11327924vdb.57.1338829920404; Mon, 04 Jun 2012 10:12:00 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id g10sm18190010vdk.2.2012.06.04.10.11.57 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jun 2012 10:11:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Mon, 4 Jun 2012 13:11:56 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <01E26F80-7341-48DC-9523-3164F2729EE5@gmail.com> References: <12418.1337957631@marajade.sandelman.ca> <5E46BEEE-3B9B-4E94-B54F-FE95CB8FE642@gmail.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1278) Cc: roll , Stiemerling Martin , Haberman Brian Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 17:12:02 -0000 On Jun 4, 2012, at 2:38 AM 6/4/12, Pascal Thubert (pthubert) wrote: > Hi: >=20 > I agree with Ralph that there is a choice to be made whether this OF = is one OF or a generic OF that is instantiated by metric (a toolbox). >=20 > If it is a specific OF, it is fair to require from IANA a specific OF = number (1 in the IANA section) but then we can expect that all = implementations of this OF will behave the same. >=20 > Here, the behavior will vary quite dramatically with some = implementation decisions (see the unresolved issue in the attached mail) = and metric choices (Ralph's point here).=20 Yes, I'm curious about the expected behavior - using a single OF number = with multiple selected metrics will yield very different behaviors for a = single OF. My understanding of the purpose for OFs is to have = predictable behavior in any RPL instance specifying the use of that OF. = In that case > As it goes, we could figure that MrHof is not one but many OFs. If = that's so then the OF number for the local variation should be assigned = consistently for a deployment as opposed to globally significant. There = could in fact be multiple MrHof in a same deployment. >=20 > My point is somewhat analogous to the UDP ports. Should we have a = range for IANA reserved well known OFs, and then a range that would be = assigned on demand?=20 The details of the IANA assignment can be settled after the fundamental = issue about the relationship between MRHOF and the selected metric is = decided. At this point, MRHOF is defined to work with exactly 5 = metrics. It might be easiest to simply assign separate OF number to = those 5 examples - e.g., OF1: MRHOF/ETX; OF2: MRHOF/latency - and = assigning other OF numbers as other metrics are defined in the future. As an aside, the hysteresis function described in MRHOF may be useful = advice for other OFs, even those that combine multiple metrics into a = single path computation. - Ralph > Cheers, >=20 > Pascal >=20 > -----Original Message----- > From: Ralph Droms [mailto:rdroms.ietf@gmail.com]=20 > Sent: vendredi 1 juin 2012 21:47 > To: Michael Richardson > Cc: roll@ietf.org; Pascal Thubert (pthubert) > Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF = related questions >=20 >=20 > On May 25, 2012, at 12:31 PM 5/25/12, Pascal Thubert (pthubert) wrote: >=20 >> Hi Michael: >>=20 >> I think RPL does not want to take party there. The OF is a piece of = logic to tie metrics and policies together.=20 >> As such, there could be multiple metrics as long as there is good = logic to tie them in. for instance one would look at optimizing metric A = within contraints as expressed by metric B and the OF model will allow = that. >>=20 >> OTOH, it a flows requires a certain optimization (say per one metric) = and another requires something different, then certainly you want two = instances. >>=20 >> So ... it depends! >>=20 >> Pascal >>=20 >>=20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20= >> Of Michael Richardson >> Sent: vendredi 25 mai 2012 16:54 >> To: roll@ietf.org >> Subject: [Roll] knowing which multiple metrics matter: MRHOF related=20= >> questions >>=20 >>=20 >> Ralph asked some questions a few days ago. >> His originally DISCUSS is at: >>=20 >> = http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of/ >> ballot/ >>=20 >> This was my reply. I am particularly interested in replies from >> Pascal, Anders and Mukul about my assertion about how we would never = pick RPL instances by metrics; that they would in fact be seperate RPL = Instance numbers and DODAG values, and that these things would = provisioned by the network installer. >>=20 >> =3D=3D=3D=3D >>=20 >> I'm going to reply to your comments in a different order than you = asked them, because I think question #3 is most important, and the rest = fall out of it. >>=20 >>>>>>> "Ralph" =3D=3D Ralph Droms writes: >> Ralph> 3. Based on (1) and (2), would configuration and selection >> Ralph> issues be ameliorated if the five candidate selected metrics >> Ralph> were each asssigned a separate objective function? Use of a >> Ralph> separate OF code point for each of the five possible = selected >> Ralph> metrics would allow multiple RPL instances. >>=20 >> I think that it's important to understand that ROLL has a whole = palette of things that need to be provisioned by the "network operator". >>=20 >> In contrast to the situation of ISPs and customers, where the ISP is=20= >> the network operator, ROLL networks are more like highly orchestrated >> Enterprises: "all your host belong to us" >>=20 >> so, when we write something like: >> "The metric chosen by the network operator to use for path >> selection." >> in section 2, we really mean: >> "The metric chosen by the network operator and provisioned into >> the node when the firmware was flashed to use for path selection." >=20 > OK, so I get that the model is that MRHOF is a toolbox, where the = specific tools are chosen when the device is flashed. In that case, I = think some additional review might be needed to ensure that the MRHOF = spec is internally consistent with that point of view. >=20 > As one example, I think the "selected metric" should be called out = explicitly somewhere in section 5 and included in the list of configured = parameters in section 6.1. >=20 > As another example, I read this text from section 3: >=20 > Rank is undefined for these node/link metrics: node state and > attributes, throughput, and link color. If the rank is undefined, > the node must join one of the neighbors as a RPL Leaf node according > to [RFC6550]. >=20 > to mean that if the selected metric is one of the metrics for which = rank is undefined, the node joins as a lead node. But, how can that = happen if the selected metric is chosen by the network operator? >=20 >> Ralph> 1. Why is one objective function defined for several = potential=20 >> Ralph> metrics? The details of MRHOF seem to preclude the=20 >> Ralph> establishment of several RPL instances in an LLN, each of = which=20 >> Ralph> uses MRHOF with a different selected metric. >>=20 >> If one had many different RPL Instances, then we would have different >> RPL Instance numbers in the RPL header. There can be many different >> DODAG ("destinations") created within that instance. The instances = share a common set of (provisioned) parameters. >=20 > How does a node know which RPL Instance number maps to which selected = metric? >=20 > One way would be to specify that a node advertise ONLY the selected = metric for the RPL Instance in a DIO. >=20 >> (To put it into DHCP terms: if we have multiple DHCP servers on a = link, then one would expect them to all offer IP addresses in the same = subnet. >> If one wanted to have addresses in different subnets, and let the = host =20 >> pick between them, then, one would need different layer-2s: different = =20 >> VLANs or ESSIDs, or... ) >>=20 >> If you feel that RPL is rather schizo about provisioning vs = configuration, then I agree. It's not always clear to me why some = things are advertised while others are provisioned. >>=20 >> In BGPv4, we calculate metrics by adding AS entries in the path. >> (It's always additive), and we add at least one AS entry to the path. >> One can AS-stuff and add more, but proper operation of BGP does not = depend upon the exact algorithm used. >>=20 >> Finally, my impression is that how the various metrics are used = (singly, or in some combination) to calculate Rank Increase is a = question of further research, experimentation, and trade secret. >=20 > Well, OK, but for the purposes of the MRHOF spec, it seems pretty = clear to me there is one selected metric that is used across all nodes = as a strictly additive path cost computation. >=20 >> So long as the Rank increases, and a node does not flap between = parents, the exact details do not matter. Each node can do it's parent = selection based upon the available metrics on it's own. It advertises = the metrics it has. >>=20 >> I hope the authors will correct me if I'm completely off here. >=20 > I read the spec to require a single selected metric across the entire = RPL Instance. >=20 > - Ralph >=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > From rdroms.ietf@gmail.com Mon Jun 4 11:29:45 2012 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 4F82711E80B6 for ; Mon, 4 Jun 2012 11:29:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.539 X-Spam-Level: X-Spam-Status: No, score=-103.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oLSfhJWdCYXx for ; Mon, 4 Jun 2012 11:29:44 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9833811E809B for ; Mon, 4 Jun 2012 11:29:44 -0700 (PDT) Received: by vcqp1 with SMTP id p1so3004283vcq.31 for ; Mon, 04 Jun 2012 11:29:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=pWKfp9+u5h0BTJGmILsB8Nngl2aTd1476ZwpTWhA/+8=; b=sOrPiOcb601JnF1jVv5xVGSqVZbaL2hZhobZ1ouKgnfHeCI06Pwu5YxffhQBQ15cJf sq81uEVgMbmjMexI0SFXbSfwtJ/IgOvUILTdrB19p9XlPl98MODTiElb0+EOs7EfNKGM UgH1CeUjEvvXE7zU6va6DQ7c+4KtwBzFLmxMp2bCgc9d2OWLgZL/kzfohnLll/aiQiQc 2+ySwrs+PtQFb1b2Iw9AHMwjInZ0Qmz7ja3XxTBr4gzWM1SWhlS7m6XgB49c9nAGCQPN g5X7TXeOxfr+UvF1afUILHC6etvC1f2Amgh88fWVxbk6qicbep6/FJ/MeC8zhRXNdgK3 kdaQ== Received: by 10.220.154.2 with SMTP id m2mr13226358vcw.2.1338834583900; Mon, 04 Jun 2012 11:29:43 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id j2sm18472314vde.16.2012.06.04.11.29.41 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 04 Jun 2012 11:29:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Ralph Droms In-Reply-To: Date: Mon, 4 Jun 2012 14:29:40 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <29FA5C28-F803-45E6-8C2F-DC0EBCA563D9@gmail.com> References: <058.aaa3fc2efaae8e26a2ada588bce49a89@trac.tools.ietf.org> <19632.1337959850@marajade.sandelman.ca> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1278) Cc: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, Stiemerling Martin , roll , Haberman Brian Subject: Re: [Roll] [roll] #99: clarify for readers how/where provisioning of devices occurs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Jun 2012 18:29:45 -0000 On Jun 2, 2012, at 5:06 AM 6/2/12, Omprakash Gnawali wrote: > On Fri, Jun 1, 2012 at 2:28 PM, Ralph Droms = wrote: >>=20 >> On May 25, 2012, at 11:30 AM 5/25/12, Michael Richardson wrote: >>=20 >>>=20 >>>>>>>> "Omprakash" =3D=3D Omprakash Gnawali = writes: >>> Omprakash> I was wondering if the first paragraph of 6.1 is = enough for things >>> Omprakash> that need to be configured/provisioned for MRHOF. >>>=20 >>> I think that it works for *MRHOF*, but I think that we have a bigger >>> picture problem here. >>=20 >> Given that the ZigBee IP spec prescribes the details of how to use = MRHOF, a node that implements ZigBee IP and will not be used in any = other deployment scenario can be configured at manufacturing time and = there is no need for the node to "allow the [...] parameters to be = configured at installation time". However, I think = draft-ietf-roll-minrank-hysteresis-of would be improved by expanding the = sense of the text to something like: >>=20 >> An implementation needs specific values for the following >> paramters: [...] These parameters may be set at device >> manufacturing time or configured at installation time. RPL/MRHOF >> do not provide a way for the appropriate values for these >> parameters to be discovered through the network. >=20 >=20 > This is a good feedback based on what is happening in practice. Happy > to incorporate this by changing the existing text from: >=20 > An implementation SHOULD allow the following parameters to be > configured at installation time: MAX_LINK_METRIC, MAX_PATH_COST, > PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT. > An implementation MAY allow these parameters to be configured > dynamically at run time once a network has been deployed. >=20 > to: >=20 > An implementation needs specific values for the following > parameters: MAX_LINK_METRIC, MAX_PATH_COST, > PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT. Should "selected metric" be added to this list? > These parameters may be set at device > manufacturing time, configured at installation time, or configured > at run time once a network has been deployed. MRHOF > does not directly help determine the values for these > parameters. Text looks good to me. - Ralph >=20 > - om_p From gnawali@cs.uh.edu Mon Jun 4 17:25:02 2012 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 D2F7E11E80C9 for ; Mon, 4 Jun 2012 17:25:02 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2F3azhOwltXv for ; Mon, 4 Jun 2012 17:25:02 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 4F09711E80C2 for ; Mon, 4 Jun 2012 17:25:02 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 94FDD23CA9E for ; Mon, 4 Jun 2012 19:24:59 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdygSjK+11fm for ; Mon, 4 Jun 2012 19:24:59 -0500 (CDT) Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id DD4B223CAA2 for ; Mon, 4 Jun 2012 19:24:56 -0500 (CDT) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by it.cs.uh.edu (Postfix) with ESMTP id 2313C2A280CE for ; Mon, 4 Jun 2012 19:22:16 -0500 (CDT) Received: by werb13 with SMTP id b13so3684365wer.31 for ; Mon, 04 Jun 2012 17:24:57 -0700 (PDT) Received: by 10.216.213.163 with SMTP id a35mr2097844wep.131.1338855897447; Mon, 04 Jun 2012 17:24:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.101.168 with HTTP; Mon, 4 Jun 2012 17:24:36 -0700 (PDT) In-Reply-To: <037178D2-ED90-4204-ACAA-982472DA767B@gmail.com> References: <535F88D6-7E39-417A-BEB7-CC67B1FFE788@cisco.com> <037178D2-ED90-4204-ACAA-982472DA767B@gmail.com> From: Omprakash Gnawali Date: Mon, 4 Jun 2012 19:24:36 -0500 Message-ID: To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org" , "roll@ietf.org" , Ralph Droms Subject: Re: [Roll] "Link quality" as a metric for MRHIF 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, 05 Jun 2012 00:25:02 -0000 On Sun, Jun 3, 2012 at 6:59 AM, Ralph Droms wrote: > > > > > On Jun 2, 2012, at 4:51 AM, Omprakash Gnawali wrote: > >> On Fri, Jun 1, 2012 at 3:14 PM, Ralph Droms wrote: >>> How is the "link quality" metric used as a selected metric in MRHOF? = =A0As I read RFC 6551, the link quality container carries a list of individ= ual link qualities. =A0To use the link quality metric in MRHOF, does the co= mputing node add up all the link qualities from the container option to com= pute the parent path cost? =A0What about link quality sub-objects with link= quality value "0"? >> >> Yes, adding up all the link quality level to compute the path cost. >> Adding up all the link quality level, including a 0, will result in >> some value which is converted to rank but it is not clear if MRHOF >> would be the best objective function to use if you want to use link >> quality level metric. > > Ok, then the MRHOF spec should be revised to drop link quality level as o= ne of the candidate selected metrics or to specify in detail how to use lin= k quality level as the selected metric. Good suggestion. We will drop link quality level metrics as one of the metrics that can be used with MRHOF. - om_p From prvs=496b680bf=mukul@uwm.edu Mon Jun 4 23:33:34 2012 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 E976421F86EC for ; Mon, 4 Jun 2012 23:33:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.423 X-Spam-Level: X-Spam-Status: No, score=-6.423 tagged_above=-999 required=5 tests=[AWL=0.176, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uG3YHe5TD+3l for ; Mon, 4 Jun 2012 23:33:34 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1EB8D21F86EB for ; Mon, 4 Jun 2012 23:33:33 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAD6nzU9/AAAB/2dsb2JhbABFhU6yAAEBAQQBAQEgSwQHDA8RBAEBAwINGQIpKAgGE4gLC6RDiVOJBIEjiXCEfoESA4hAjFuBD45ngn4 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 69BDDE6A72; Tue, 5 Jun 2012 01:33:33 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ThXP5jN7RrWj; Tue, 5 Jun 2012 01:33:33 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 09A80E6A8D; Tue, 5 Jun 2012 01:33:33 -0500 (CDT) Date: Tue, 5 Jun 2012 01:33:32 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <537951918.595398.1338878012914.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions 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, 05 Jun 2012 06:33:35 -0000 Hi Pascal >An instance can use multiple metrics bound by some logic. But those metrics and that logic must be identical throughout the instance. A different (set of) metric means a different OF even if MRHOF is behind both. Could you please explain. This is not how I understand the relationship among an RPL Instance, an OF and metrics to be. As per my understanding, there is one OF associated with an RPL Instance and the metrics in use are chosen by the root. Accordingly, an RPL Instance _can_ have different DODAGIDs using different sets of metrics. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Michael Richardson" Cc: roll@ietf.org Sent: Monday, May 28, 2012 2:04:59 PM Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions Hello Micheal >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> I think RPL does not want to take party there. The OF is a Pascal> piece of logic to tie metrics and policies together. My question is: - do the nodes of a DODAG have to use the same metrics to pick a parent, (and if so, how do they agree) I think that they do not, so long as they use an algorithm (such as MRHOF) which has certain properties. [Pascal] The current spec requires that all players of an instance play by the same rule, that is same OF, in order to guarantee the expected result. The goal there was deeper than the OF, like same OF with same parameterization. MRHOF is generic and allows various incarnations, depending in the metrics; all those incarnations are to be seen as different OFs WRT to RPL 's uniqueness rule. Note that this rule is not for looplessness, the Rank would assure that anyway. - if we had multiple RPL instances in an LLN, using different metrics, then we would have multiple RPL Instances and DODAGs. The different set of metrics would not co-exist in the same RPL Instance. [Pascal] I think we agree. An instance can use multiple metrics bound by some logic. But those metrics and that logic must be identical throughout the instance. A different (set of) metric means a different OF even if MRHOF is behind both. Cheers, Pascal -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Jun 4 23:52:29 2012 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 34A6921F86FD for ; Mon, 4 Jun 2012 23:52:29 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGOhMIbobJ8O for ; Mon, 4 Jun 2012 23:52:28 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id BDF0121F86EB for ; Mon, 4 Jun 2012 23:52:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4270; q=dns/txt; s=iport; t=1338879147; x=1340088747; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=oJ44s2AtSvDQOZUWUxsRmbaOg98Xn7H68n3VnHKsOGI=; b=T/a+C2IO783LkAFrNqIqeNU/y/w6Gq8B2virqik60jmwxLnPbra+3hKx Dv2faImtXCd0gULVdtyKny0AiC4lwHjmh3vtrp0+VRtUgCUscODscwCRU zfL4EV8Le5zKYic0uwJk3eWg7z3ivZuqf3hysMHV8SXgUGyu4fQ5nnFHA Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAP2rzU+tJXG8/2dsb2JhbABFDoVArUmBGYEHghgBAQEEAQEBDwEQEToEBwwEAgEIEQQBAQMCBh0DAgICJQsUAQgIAgQOBQgah2kLly2NFpJVgSOJcIR+MmADliqNAYFmgic5 X-IronPort-AV: E=Sophos;i="4.75,716,1330905600"; d="scan'208";a="89526309" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 05 Jun 2012 06:52:27 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id q556qRVg010815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Jun 2012 06:52:27 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.42]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0298.004; Tue, 5 Jun 2012 01:52:26 -0500 From: "Pascal Thubert (pthubert)" To: Mukul Goyal Thread-Topic: [Roll] knowing which multiple metrics matter: MRHOF related questions Thread-Index: AQHNQuUjfxzrAlPxnEKyHkVKqzzUOZbrSM2w Date: Tue, 5 Jun 2012 06:52:09 +0000 Deferred-Delivery: Tue, 5 Jun 2012 06:52:00 +0000 Message-ID: References: <537951918.595398.1338878012914.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <537951918.595398.1338878012914.JavaMail.root@mail17.pantherlink.uwm.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.88.173] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18948.003 x-tm-as-result: No--40.886200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions 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, 05 Jun 2012 06:52:29 -0000 SGkgUmFscGg6DQoNCldlbGwsIG5vLiBXaGV0aGVyIGFuIGluc3RhbmNlIGlzIGEgc2luZ2xlIERP REFHIChvbmUgcm9vdCkgb3IgbXVsdGlwbGUsIHRoZSBpbnN0YW5jZSBoYXMgdG8gYmUgaG9tb2dl bmVvdXMuIA0KVGhpcyBpcyBiZWNhdXNlIG5vZGVzIHdpbGwgbW92ZSBmcm9tIG9uZSBET0RBRyB0 byB0aGUgbmV4dCB3aGVuIHRoZSBlbnZpcm9ubWVudCByZXF1aXJlcyB0aGUgY2hhbmdlLCBhbmQg dGhlIHJ1bGVzIG11c3Qgbm90IGNoYW5nZS4gDQoNCkNoZWVycywNCg0KUGFzY2FsDQoNCg0KLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE11a3VsIEdveWFsIFttYWlsdG86bXVrdWxA dXdtLmVkdV0gDQpTZW50OiBtYXJkaSA1IGp1aW4gMjAxMiAwODozNA0KVG86IFBhc2NhbCBUaHVi ZXJ0IChwdGh1YmVydCkNCkNjOiByb2xsQGlldGYub3JnOyBNaWNoYWVsIFJpY2hhcmRzb24NClN1 YmplY3Q6IFJlOiBbUm9sbF0ga25vd2luZyB3aGljaCBtdWx0aXBsZSBtZXRyaWNzIG1hdHRlcjog TVJIT0YgcmVsYXRlZCBxdWVzdGlvbnMNCg0KSGkgUGFzY2FsDQoNCj5BbiBpbnN0YW5jZSBjYW4g dXNlIG11bHRpcGxlIG1ldHJpY3MgYm91bmQgYnkgc29tZSBsb2dpYy4gQnV0IHRob3NlIG1ldHJp Y3MgYW5kIHRoYXQgbG9naWMgbXVzdCBiZSBpZGVudGljYWwgdGhyb3VnaG91dCB0aGUgaW5zdGFu Y2UuIEEgZGlmZmVyZW50IChzZXQgb2YpIG1ldHJpYyBtZWFucyBhIGRpZmZlcmVudCBPRiBldmVu IGlmIE1SSE9GIGlzIGJlaGluZCBib3RoLg0KDQpDb3VsZCB5b3UgcGxlYXNlIGV4cGxhaW4uIFRo aXMgaXMgbm90IGhvdyBJIHVuZGVyc3RhbmQgdGhlIHJlbGF0aW9uc2hpcCBhbW9uZyBhbiBSUEwg SW5zdGFuY2UsIGFuIE9GIGFuZCBtZXRyaWNzIHRvIGJlLiBBcyBwZXIgbXkgdW5kZXJzdGFuZGlu ZywgdGhlcmUgaXMgb25lIE9GIGFzc29jaWF0ZWQgd2l0aCBhbiBSUEwgSW5zdGFuY2UgYW5kIHRo ZSBtZXRyaWNzIGluIHVzZSBhcmUgY2hvc2VuIGJ5IHRoZSByb290LiBBY2NvcmRpbmdseSwgYW4g UlBMIEluc3RhbmNlIF9jYW5fIGhhdmUgZGlmZmVyZW50IERPREFHSURzIHVzaW5nIGRpZmZlcmVu dCBzZXRzIG9mIG1ldHJpY3MuDQoNClRoYW5rcw0KTXVrdWwgDQoNCg0KDQoNCi0tLS0tIE9yaWdp bmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206ICJQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIiA8cHRo dWJlcnRAY2lzY28uY29tPg0KVG86ICJNaWNoYWVsIFJpY2hhcmRzb24iIDxtY3IraWV0ZkBzYW5k ZWxtYW4uY2E+DQpDYzogcm9sbEBpZXRmLm9yZw0KU2VudDogTW9uZGF5LCBNYXkgMjgsIDIwMTIg MjowNDo1OSBQTQ0KU3ViamVjdDogUmU6IFtSb2xsXSBrbm93aW5nIHdoaWNoIG11bHRpcGxlIG1l dHJpY3MgbWF0dGVyOiBNUkhPRiByZWxhdGVkIHF1ZXN0aW9ucw0KDQpIZWxsbyBNaWNoZWFsDQoN Cj4+Pj4+ICJQYXNjYWwiID09IFBhc2NhbCBUaHViZXJ0IDwocHRodWJlcnQpIiA8cHRodWJlcnRA Y2lzY28uY29tPj4gd3JpdGVzOg0KICAgIFBhc2NhbD4gSSB0aGluayBSUEwgZG9lcyBub3Qgd2Fu dCB0byB0YWtlIHBhcnR5IHRoZXJlLiBUaGUgT0YgaXMgYQ0KICAgIFBhc2NhbD4gcGllY2Ugb2Yg bG9naWMgdG8gdGllIG1ldHJpY3MgYW5kIHBvbGljaWVzIHRvZ2V0aGVyLiAgDQoNCk15IHF1ZXN0 aW9uIGlzOg0KDQotIGRvIHRoZSBub2RlcyBvZiBhIERPREFHIGhhdmUgdG8gdXNlIHRoZSBzYW1l IG1ldHJpY3MgdG8gcGljayBhIHBhcmVudCwNCiAgKGFuZCBpZiBzbywgaG93IGRvIHRoZXkgYWdy ZWUpDQogIEkgdGhpbmsgdGhhdCB0aGV5IGRvIG5vdCwgc28gbG9uZyBhcyB0aGV5IHVzZSBhbiBh bGdvcml0aG0gKHN1Y2ggYXMNCiAgTVJIT0YpIHdoaWNoIGhhcyBjZXJ0YWluIHByb3BlcnRpZXMu DQoNCltQYXNjYWxdICBUaGUgY3VycmVudCBzcGVjIHJlcXVpcmVzIHRoYXQgYWxsIHBsYXllcnMg b2YgYW4gaW5zdGFuY2UgcGxheSBieSB0aGUgc2FtZSBydWxlLCB0aGF0IGlzIHNhbWUgT0YsIGlu IG9yZGVyIHRvIGd1YXJhbnRlZSB0aGUgZXhwZWN0ZWQgcmVzdWx0LiANClRoZSBnb2FsIHRoZXJl IHdhcyBkZWVwZXIgdGhhbiB0aGUgT0YsIGxpa2Ugc2FtZSBPRiB3aXRoIHNhbWUgcGFyYW1ldGVy aXphdGlvbi4gTVJIT0YgaXMgZ2VuZXJpYyBhbmQgYWxsb3dzIHZhcmlvdXMgaW5jYXJuYXRpb25z LCBkZXBlbmRpbmcgaW4gdGhlIG1ldHJpY3M7IGFsbCB0aG9zZSBpbmNhcm5hdGlvbnMgYXJlIHRv IGJlIHNlZW4gYXMgZGlmZmVyZW50IE9GcyBXUlQgdG8gUlBMICdzIHVuaXF1ZW5lc3MgcnVsZS4N Cg0KTm90ZSB0aGF0IHRoaXMgcnVsZSBpcyBub3QgZm9yIGxvb3BsZXNzbmVzcywgdGhlIFJhbmsg d291bGQgYXNzdXJlIHRoYXQgYW55d2F5Lg0KDQoNCi0gaWYgd2UgaGFkIG11bHRpcGxlIFJQTCBp bnN0YW5jZXMgaW4gYW4gTExOLCB1c2luZyBkaWZmZXJlbnQgbWV0cmljcywNCiAgdGhlbiB3ZSB3 b3VsZCBoYXZlIG11bHRpcGxlIFJQTCBJbnN0YW5jZXMgYW5kIERPREFHcy4gIFRoZSBkaWZmZXJl bnQNCiAgc2V0IG9mIG1ldHJpY3Mgd291bGQgbm90IGNvLWV4aXN0IGluIHRoZSBzYW1lIFJQTCBJ bnN0YW5jZS4NCg0KW1Bhc2NhbF0gSSB0aGluayB3ZSBhZ3JlZS4gQW4gaW5zdGFuY2UgY2FuIHVz ZSBtdWx0aXBsZSBtZXRyaWNzIGJvdW5kIGJ5IHNvbWUgbG9naWMuIEJ1dCB0aG9zZSBtZXRyaWNz IGFuZCB0aGF0IGxvZ2ljIG11c3QgYmUgaWRlbnRpY2FsIHRocm91Z2hvdXQgdGhlIGluc3RhbmNl LiANCkEgZGlmZmVyZW50IChzZXQgb2YpIG1ldHJpYyBtZWFucyBhIGRpZmZlcmVudCBPRiBldmVu IGlmIE1SSE9GIGlzIGJlaGluZCBib3RoLg0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQotLSANCk1p Y2hhZWwgUmljaGFyZHNvbiA8bWNyK0lFVEZAc2FuZGVsbWFuLmNhPiwgU2FuZGVsbWFuIFNvZnR3 YXJlIFdvcmtzIA0KSUVURiBST0xMIFdHIGNvLWNoYWlyLiAgICBodHRwOi8vZGF0YXRyYWNrZXIu aWV0Zi5vcmcvd2cvcm9sbC9jaGFydGVyLw0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmcNCmh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K From prvs=496b680bf=mukul@uwm.edu Tue Jun 5 00:11:47 2012 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 9125811E8073 for ; Tue, 5 Jun 2012 00:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.436 X-Spam-Level: X-Spam-Status: No, score=-6.436 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daZrctx2EGzZ for ; Tue, 5 Jun 2012 00:11:46 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id BA8F921F8661 for ; Tue, 5 Jun 2012 00:11:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EALivzU9/AAAB/2dsb2JhbABFhU6yAQEBAQQBAQEgSwQHDA8RBAEBAwINFgMCKR8JCAYTiAsLpD+JV4kEgSOJcIR+gRIDiECMW4EPjmeCfg Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id F34E912E3BA; Tue, 5 Jun 2012 02:11:45 -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 1oQfRzcfH1XV; Tue, 5 Jun 2012 02:11:45 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 9311D12E3AE; Tue, 5 Jun 2012 02:11:45 -0500 (CDT) Date: Tue, 5 Jun 2012 02:11:45 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <1970964124.595435.1338880305480.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions 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, 05 Jun 2012 07:11:47 -0000 Hi Pascal So, what you are suggesting is that an RPLInstanceID is associated with (OF, metrics) pair and not just OF? This would not be in accordance with RC 6550, which associates an RPLInstanceID with an OF. My understanding is: 1) An RPLInstanceID is associated with an OF. 2) (RPLInstanceID, DODAGID) pair is associated with (OF, metrics) pair. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: roll@ietf.org, "Michael Richardson" Sent: Tuesday, June 5, 2012 1:52:09 AM Subject: RE: [Roll] knowing which multiple metrics matter: MRHOF related questions Hi Ralph: Well, no. Whether an instance is a single DODAG (one root) or multiple, the instance has to be homogeneous. This is because nodes will move from one DODAG to the next when the environment requires the change, and the rules must not change. Cheers, Pascal -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu] Sent: mardi 5 juin 2012 08:34 To: Pascal Thubert (pthubert) Cc: roll@ietf.org; Michael Richardson Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions Hi Pascal >An instance can use multiple metrics bound by some logic. But those metrics and that logic must be identical throughout the instance. A different (set of) metric means a different OF even if MRHOF is behind both. Could you please explain. This is not how I understand the relationship among an RPL Instance, an OF and metrics to be. As per my understanding, there is one OF associated with an RPL Instance and the metrics in use are chosen by the root. Accordingly, an RPL Instance _can_ have different DODAGIDs using different sets of metrics. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Michael Richardson" Cc: roll@ietf.org Sent: Monday, May 28, 2012 2:04:59 PM Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions Hello Micheal >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> I think RPL does not want to take party there. The OF is a Pascal> piece of logic to tie metrics and policies together. My question is: - do the nodes of a DODAG have to use the same metrics to pick a parent, (and if so, how do they agree) I think that they do not, so long as they use an algorithm (such as MRHOF) which has certain properties. [Pascal] The current spec requires that all players of an instance play by the same rule, that is same OF, in order to guarantee the expected result. The goal there was deeper than the OF, like same OF with same parameterization. MRHOF is generic and allows various incarnations, depending in the metrics; all those incarnations are to be seen as different OFs WRT to RPL 's uniqueness rule. Note that this rule is not for looplessness, the Rank would assure that anyway. - if we had multiple RPL instances in an LLN, using different metrics, then we would have multiple RPL Instances and DODAGs. The different set of metrics would not co-exist in the same RPL Instance. [Pascal] I think we agree. An instance can use multiple metrics bound by some logic. But those metrics and that logic must be identical throughout the instance. A different (set of) metric means a different OF even if MRHOF is behind both. Cheers, Pascal -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue Jun 5 00:55:23 2012 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 122B721F86DC for ; Tue, 5 Jun 2012 00:55:23 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NWAnwcXQUtx4 for ; Tue, 5 Jun 2012 00:55:22 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6EE21F85E6 for ; Tue, 5 Jun 2012 00:55:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=5982; q=dns/txt; s=iport; t=1338882922; x=1340092522; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Rc91cFEBaO542R4lvPu1IEv4P8hzVFco6FoINb9Qhqs=; b=E6tkPxtF1bsz4JigaFRIxuGG3IQeswGaZ5DbgGYoX8cgNp1b480FGWh2 5iUAaw4rsAaEniVNgb+6p8H0hz4QrBbRzQnqTuf2+hEXQB2Nil+Q7UMOD +jGzrFNxC5swGlWNJlD0Imxiz+kso/aaJFU8DFx3R19/JZrJBSQ1VTlpY 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAAC7zU+tJXG9/2dsb2JhbABFDoVArUqBGYEHghgBAQEEAQEBDwEQEToEBwwEAgEIEQQBAQMCBh0DAgICJQsUAQgIAgQOBQgah2kLlyyNFpJkgSOJcIR+MmADliqNAYFmgic5 X-IronPort-AV: E=Sophos;i="4.75,716,1330905600"; d="scan'208";a="89534858" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 05 Jun 2012 07:55:21 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q557tLO8019503 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Jun 2012 07:55:21 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.42]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0298.004; Tue, 5 Jun 2012 02:55:21 -0500 From: "Pascal Thubert (pthubert)" To: Mukul Goyal Thread-Topic: [Roll] knowing which multiple metrics matter: MRHOF related questions Thread-Index: AQHNQup6ULy3hBmkIkCSkVrMBfXX/JbrWlqg Date: Tue, 5 Jun 2012 07:55:04 +0000 Deferred-Delivery: Tue, 5 Jun 2012 07:55:00 +0000 Message-ID: References: <1970964124.595435.1338880305480.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <1970964124.595435.1338880305480.JavaMail.root@mail17.pantherlink.uwm.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.88.173] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18948.003 x-tm-as-result: No--47.475000-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions 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, 05 Jun 2012 07:55:23 -0000 SGVsbG8gTXVrdWw6DQoNCkknbSBjdXJpb3VzOiB3aGVyZSBkaWQgeW91IGdldCB0aGUgc2Vjb25k IHBvaW50IGZyb20/DQoNCk5vLCB5b3UgY2FuJ3Qgc3dpdGNoIG1ldHJpYyBhcyB5b3Ugc3dpdGNo IERPREFHSUQgd2l0aGluIGFuIGluc3RhbmNlLiBCZWNhdXNlIG5vZGVzIGNhbiBtb3ZlIChqdW1w IGlzIHRoZSB3b3JkIGluIHRoZSBzcGVjKSBmcm9tIGEgRE9EQUcgdG8gdGhlIG5leHQsIGFuZCBu ZWVkIHRvIGNvbXBhcmUgYXBwbGUgdG8gYXBwbGUgd2hlbiB0aGV5IGRvIHNvLi4uDQoNCkNoZWVy cywNCg0KUGFzY2FsDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE11a3Vs IEdveWFsIFttYWlsdG86bXVrdWxAdXdtLmVkdV0gDQpTZW50OiBtYXJkaSA1IGp1aW4gMjAxMiAw OToxMg0KVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkNCkNjOiByb2xsQGlldGYub3JnOyBN aWNoYWVsIFJpY2hhcmRzb24NClN1YmplY3Q6IFJlOiBbUm9sbF0ga25vd2luZyB3aGljaCBtdWx0 aXBsZSBtZXRyaWNzIG1hdHRlcjogTVJIT0YgcmVsYXRlZCBxdWVzdGlvbnMNCg0KSGkgUGFzY2Fs DQoNClNvLCB3aGF0IHlvdSBhcmUgc3VnZ2VzdGluZyBpcyB0aGF0IGFuIFJQTEluc3RhbmNlSUQg aXMgYXNzb2NpYXRlZCB3aXRoIChPRiwgbWV0cmljcykgcGFpciBhbmQgbm90IGp1c3QgT0Y/IFRo aXMgd291bGQgbm90IGJlIGluIGFjY29yZGFuY2Ugd2l0aCBSQyA2NTUwLCB3aGljaCBhc3NvY2lh dGVzIGFuIFJQTEluc3RhbmNlSUQgd2l0aCBhbiBPRi4gTXkgdW5kZXJzdGFuZGluZyBpczoNCg0K MSkgQW4gUlBMSW5zdGFuY2VJRCBpcyBhc3NvY2lhdGVkIHdpdGggYW4gT0YuDQoyKSAoUlBMSW5z dGFuY2VJRCwgRE9EQUdJRCkgcGFpciBpcyBhc3NvY2lhdGVkIHdpdGggKE9GLCBtZXRyaWNzKSBw YWlyLg0KDQpUaGFua3MNCk11a3VsDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZy b206ICJQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIiA8cHRodWJlcnRAY2lzY28uY29tPg0KVG86 ICJNdWt1bCBHb3lhbCIgPG11a3VsQHV3bS5lZHU+DQpDYzogcm9sbEBpZXRmLm9yZywgIk1pY2hh ZWwgUmljaGFyZHNvbiIgPG1jcitpZXRmQHNhbmRlbG1hbi5jYT4NClNlbnQ6IFR1ZXNkYXksIEp1 bmUgNSwgMjAxMiAxOjUyOjA5IEFNDQpTdWJqZWN0OiBSRTogW1JvbGxdIGtub3dpbmcgd2hpY2gg bXVsdGlwbGUgbWV0cmljcyBtYXR0ZXI6IE1SSE9GIHJlbGF0ZWQgcXVlc3Rpb25zDQoNCkhpIFJh bHBoOg0KDQpXZWxsLCBuby4gV2hldGhlciBhbiBpbnN0YW5jZSBpcyBhIHNpbmdsZSBET0RBRyAo b25lIHJvb3QpIG9yIG11bHRpcGxlLCB0aGUgaW5zdGFuY2UgaGFzIHRvIGJlIGhvbW9nZW5lb3Vz LiANClRoaXMgaXMgYmVjYXVzZSBub2RlcyB3aWxsIG1vdmUgZnJvbSBvbmUgRE9EQUcgdG8gdGhl IG5leHQgd2hlbiB0aGUgZW52aXJvbm1lbnQgcmVxdWlyZXMgdGhlIGNoYW5nZSwgYW5kIHRoZSBy dWxlcyBtdXN0IG5vdCBjaGFuZ2UuIA0KDQpDaGVlcnMsDQoNClBhc2NhbA0KDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNdWt1bCBHb3lhbCBbbWFpbHRvOm11a3VsQHV3bS5l ZHVdIA0KU2VudDogbWFyZGkgNSBqdWluIDIwMTIgMDg6MzQNClRvOiBQYXNjYWwgVGh1YmVydCAo cHRodWJlcnQpDQpDYzogcm9sbEBpZXRmLm9yZzsgTWljaGFlbCBSaWNoYXJkc29uDQpTdWJqZWN0 OiBSZTogW1JvbGxdIGtub3dpbmcgd2hpY2ggbXVsdGlwbGUgbWV0cmljcyBtYXR0ZXI6IE1SSE9G IHJlbGF0ZWQgcXVlc3Rpb25zDQoNCkhpIFBhc2NhbA0KDQo+QW4gaW5zdGFuY2UgY2FuIHVzZSBt dWx0aXBsZSBtZXRyaWNzIGJvdW5kIGJ5IHNvbWUgbG9naWMuIEJ1dCB0aG9zZSBtZXRyaWNzIGFu ZCB0aGF0IGxvZ2ljIG11c3QgYmUgaWRlbnRpY2FsIHRocm91Z2hvdXQgdGhlIGluc3RhbmNlLiBB IGRpZmZlcmVudCAoc2V0IG9mKSBtZXRyaWMgbWVhbnMgYSBkaWZmZXJlbnQgT0YgZXZlbiBpZiBN UkhPRiBpcyBiZWhpbmQgYm90aC4NCg0KQ291bGQgeW91IHBsZWFzZSBleHBsYWluLiBUaGlzIGlz IG5vdCBob3cgSSB1bmRlcnN0YW5kIHRoZSByZWxhdGlvbnNoaXAgYW1vbmcgYW4gUlBMIEluc3Rh bmNlLCBhbiBPRiBhbmQgbWV0cmljcyB0byBiZS4gQXMgcGVyIG15IHVuZGVyc3RhbmRpbmcsIHRo ZXJlIGlzIG9uZSBPRiBhc3NvY2lhdGVkIHdpdGggYW4gUlBMIEluc3RhbmNlIGFuZCB0aGUgbWV0 cmljcyBpbiB1c2UgYXJlIGNob3NlbiBieSB0aGUgcm9vdC4gQWNjb3JkaW5nbHksIGFuIFJQTCBJ bnN0YW5jZSBfY2FuXyBoYXZlIGRpZmZlcmVudCBET0RBR0lEcyB1c2luZyBkaWZmZXJlbnQgc2V0 cyBvZiBtZXRyaWNzLg0KDQpUaGFua3MNCk11a3VsIA0KDQoNCg0KDQotLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tDQpGcm9tOiAiUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSIgPHB0aHViZXJ0 QGNpc2NvLmNvbT4NClRvOiAiTWljaGFlbCBSaWNoYXJkc29uIiA8bWNyK2lldGZAc2FuZGVsbWFu LmNhPg0KQ2M6IHJvbGxAaWV0Zi5vcmcNClNlbnQ6IE1vbmRheSwgTWF5IDI4LCAyMDEyIDI6MDQ6 NTkgUE0NClN1YmplY3Q6IFJlOiBbUm9sbF0ga25vd2luZyB3aGljaCBtdWx0aXBsZSBtZXRyaWNz IG1hdHRlcjogTVJIT0YgcmVsYXRlZCBxdWVzdGlvbnMNCg0KSGVsbG8gTWljaGVhbA0KDQo+Pj4+ PiAiUGFzY2FsIiA9PSBQYXNjYWwgVGh1YmVydCA8KHB0aHViZXJ0KSIgPHB0aHViZXJ0QGNpc2Nv LmNvbT4+IHdyaXRlczoNCiAgICBQYXNjYWw+IEkgdGhpbmsgUlBMIGRvZXMgbm90IHdhbnQgdG8g dGFrZSBwYXJ0eSB0aGVyZS4gVGhlIE9GIGlzIGENCiAgICBQYXNjYWw+IHBpZWNlIG9mIGxvZ2lj IHRvIHRpZSBtZXRyaWNzIGFuZCBwb2xpY2llcyB0b2dldGhlci4gIA0KDQpNeSBxdWVzdGlvbiBp czoNCg0KLSBkbyB0aGUgbm9kZXMgb2YgYSBET0RBRyBoYXZlIHRvIHVzZSB0aGUgc2FtZSBtZXRy aWNzIHRvIHBpY2sgYSBwYXJlbnQsDQogIChhbmQgaWYgc28sIGhvdyBkbyB0aGV5IGFncmVlKQ0K ICBJIHRoaW5rIHRoYXQgdGhleSBkbyBub3QsIHNvIGxvbmcgYXMgdGhleSB1c2UgYW4gYWxnb3Jp dGhtIChzdWNoIGFzDQogIE1SSE9GKSB3aGljaCBoYXMgY2VydGFpbiBwcm9wZXJ0aWVzLg0KDQpb UGFzY2FsXSAgVGhlIGN1cnJlbnQgc3BlYyByZXF1aXJlcyB0aGF0IGFsbCBwbGF5ZXJzIG9mIGFu IGluc3RhbmNlIHBsYXkgYnkgdGhlIHNhbWUgcnVsZSwgdGhhdCBpcyBzYW1lIE9GLCBpbiBvcmRl ciB0byBndWFyYW50ZWUgdGhlIGV4cGVjdGVkIHJlc3VsdC4gDQpUaGUgZ29hbCB0aGVyZSB3YXMg ZGVlcGVyIHRoYW4gdGhlIE9GLCBsaWtlIHNhbWUgT0Ygd2l0aCBzYW1lIHBhcmFtZXRlcml6YXRp b24uIE1SSE9GIGlzIGdlbmVyaWMgYW5kIGFsbG93cyB2YXJpb3VzIGluY2FybmF0aW9ucywgZGVw ZW5kaW5nIGluIHRoZSBtZXRyaWNzOyBhbGwgdGhvc2UgaW5jYXJuYXRpb25zIGFyZSB0byBiZSBz ZWVuIGFzIGRpZmZlcmVudCBPRnMgV1JUIHRvIFJQTCAncyB1bmlxdWVuZXNzIHJ1bGUuDQoNCk5v dGUgdGhhdCB0aGlzIHJ1bGUgaXMgbm90IGZvciBsb29wbGVzc25lc3MsIHRoZSBSYW5rIHdvdWxk IGFzc3VyZSB0aGF0IGFueXdheS4NCg0KDQotIGlmIHdlIGhhZCBtdWx0aXBsZSBSUEwgaW5zdGFu Y2VzIGluIGFuIExMTiwgdXNpbmcgZGlmZmVyZW50IG1ldHJpY3MsDQogIHRoZW4gd2Ugd291bGQg aGF2ZSBtdWx0aXBsZSBSUEwgSW5zdGFuY2VzIGFuZCBET0RBR3MuICBUaGUgZGlmZmVyZW50DQog IHNldCBvZiBtZXRyaWNzIHdvdWxkIG5vdCBjby1leGlzdCBpbiB0aGUgc2FtZSBSUEwgSW5zdGFu Y2UuDQoNCltQYXNjYWxdIEkgdGhpbmsgd2UgYWdyZWUuIEFuIGluc3RhbmNlIGNhbiB1c2UgbXVs dGlwbGUgbWV0cmljcyBib3VuZCBieSBzb21lIGxvZ2ljLiBCdXQgdGhvc2UgbWV0cmljcyBhbmQg dGhhdCBsb2dpYyBtdXN0IGJlIGlkZW50aWNhbCB0aHJvdWdob3V0IHRoZSBpbnN0YW5jZS4gDQpB IGRpZmZlcmVudCAoc2V0IG9mKSBtZXRyaWMgbWVhbnMgYSBkaWZmZXJlbnQgT0YgZXZlbiBpZiBN UkhPRiBpcyBiZWhpbmQgYm90aC4NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KLS0gDQpNaWNoYWVs IFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRlbG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBX b3JrcyANCklFVEYgUk9MTCBXRyBjby1jaGFpci4gICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYu b3JnL3dnL3JvbGwvY2hhcnRlci8NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NClJvbGwgbWFpbGluZyBsaXN0DQpSb2xsQGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== From prvs=496b680bf=mukul@uwm.edu Tue Jun 5 01:09:51 2012 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 B385721F8577 for ; Tue, 5 Jun 2012 01:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.152, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57v7bZnLZyV8 for ; Tue, 5 Jun 2012 01:09:50 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 620CB21F8570 for ; Tue, 5 Jun 2012 01:09:50 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAJO9zU9/AAAB/2dsb2JhbABFhU6yAgEBAQQBAQEgSwQHDA8RBAEBAwINFgMCKR8JCAYTiAsLpDyJYokEgSOJcIR+gRIDiECMW4EPjmeCfg Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id D4DA22B3EF6; Tue, 5 Jun 2012 03:09:30 -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 0xJTw-Zo2bv2; Tue, 5 Jun 2012 03:09:30 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 7EEBC2B3EF5; Tue, 5 Jun 2012 03:09:30 -0500 (CDT) Date: Tue, 5 Jun 2012 03:09:49 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <563814430.595510.1338883789071.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions 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, 05 Jun 2012 08:09:51 -0000 Hi Pascal >I'm curious: where did you get the second point from? The mapping from (RPLInstanceID, DODAGID) pair to (OF, metrics) pair comes from my understanding that the root (the provider of DODAGID) decides what metrics to use. >No, you can't switch metric as you switch DODAGID within an instance. Because nodes can move (jump is the word in the spec) from a DODAG to the next, and need to compare apple to apple when they do so... That makes sense. I stand corrected. Cheers Mukul -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu] Sent: mardi 5 juin 2012 09:12 To: Pascal Thubert (pthubert) Cc: roll@ietf.org; Michael Richardson Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions Hi Pascal So, what you are suggesting is that an RPLInstanceID is associated with (OF, metrics) pair and not just OF? This would not be in accordance with RC 6550, which associates an RPLInstanceID with an OF. My understanding is: 1) An RPLInstanceID is associated with an OF. 2) (RPLInstanceID, DODAGID) pair is associated with (OF, metrics) pair. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" Cc: roll@ietf.org, "Michael Richardson" Sent: Tuesday, June 5, 2012 1:52:09 AM Subject: RE: [Roll] knowing which multiple metrics matter: MRHOF related questions Hi Ralph: Well, no. Whether an instance is a single DODAG (one root) or multiple, the instance has to be homogeneous. This is because nodes will move from one DODAG to the next when the environment requires the change, and the rules must not change. Cheers, Pascal -----Original Message----- From: Mukul Goyal [mailto:mukul@uwm.edu] Sent: mardi 5 juin 2012 08:34 To: Pascal Thubert (pthubert) Cc: roll@ietf.org; Michael Richardson Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions Hi Pascal >An instance can use multiple metrics bound by some logic. But those metrics and that logic must be identical throughout the instance. A different (set of) metric means a different OF even if MRHOF is behind both. Could you please explain. This is not how I understand the relationship among an RPL Instance, an OF and metrics to be. As per my understanding, there is one OF associated with an RPL Instance and the metrics in use are chosen by the root. Accordingly, an RPL Instance _can_ have different DODAGIDs using different sets of metrics. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Michael Richardson" Cc: roll@ietf.org Sent: Monday, May 28, 2012 2:04:59 PM Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions Hello Micheal >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> I think RPL does not want to take party there. The OF is a Pascal> piece of logic to tie metrics and policies together. My question is: - do the nodes of a DODAG have to use the same metrics to pick a parent, (and if so, how do they agree) I think that they do not, so long as they use an algorithm (such as MRHOF) which has certain properties. [Pascal] The current spec requires that all players of an instance play by the same rule, that is same OF, in order to guarantee the expected result. The goal there was deeper than the OF, like same OF with same parameterization. MRHOF is generic and allows various incarnations, depending in the metrics; all those incarnations are to be seen as different OFs WRT to RPL 's uniqueness rule. Note that this rule is not for looplessness, the Rank would assure that anyway. - if we had multiple RPL instances in an LLN, using different metrics, then we would have multiple RPL Instances and DODAGs. The different set of metrics would not co-exist in the same RPL Instance. [Pascal] I think we agree. An instance can use multiple metrics bound by some logic. But those metrics and that logic must be identical throughout the instance. A different (set of) metric means a different OF even if MRHOF is behind both. Cheers, Pascal -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=496b680bf=mukul@uwm.edu Tue Jun 5 01:29:48 2012 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 DCEBB21F85E6 for ; Tue, 5 Jun 2012 01:29:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zxwLUz-dhNUf for ; Tue, 5 Jun 2012 01:29:47 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7D52F21F86B3 for ; Tue, 5 Jun 2012 01:29:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAKbCzU9/AAAB/2dsb2JhbABFhU6yCSNWGw4MAg0ZAlkGiB6kRIljiQSBI45ugRIDiECMW492gn4 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id C7DF81FD0C9; Tue, 5 Jun 2012 03:29:46 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eud1QsWrdWv9; Tue, 5 Jun 2012 03:29:46 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 652E01FD0C7; Tue, 5 Jun 2012 03:29:46 -0500 (CDT) Date: Tue, 5 Jun 2012 03:29:46 -0500 (CDT) From: Mukul Goyal To: Ralph Droms Message-ID: <386577058.595535.1338884986250.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll , Stiemerling Martin , Michael Richardson , Haberman Brian Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec 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, 05 Jun 2012 08:29:49 -0000 Hi Ralph ****************************************************************************** [Ralph1] > 1. Why is one objective function defined for several potential > metrics? The details of MRHOF seem to preclude the establishment of > several RPL instances in an LLN, each of which uses MRHOF with a > different selected metric. > [Mukul1] > It is certainly possible to establish multiple RPL Instances in an LLN with MRHOF (or any other OF) as the OF. These RPL Instances may or may not use different routing metrics. An RPL Instance is associated with one particular OF as per RFC 6550. The OF converts the aggregated routing metric values to a rank value. Whether a particular OF could work with a particular metric depends on the OF. E.g. MRHOF specification says that MRHOF only works with additive metrics. So, the choice of routing metrics to be used in a particular DODAG (identified by the DODAGID) inside a particular RPL Instance may depend on the particular OF being used but, in general, the choice of OF and the choice of routing metrics are separate/independent issues. [Ralph2] My question here is why a single objective function "MRHOF" is defined to use several different metrics. My understanding is that any specific RPL instance will use one metric as its "selected metric" for MRHOF. Another way to organize the objective functions would be to define a different OF number for each metric, binding the OF number to the selected metric. [Mukul2] An OF is a function and hence is supposed to be independent of the variables (the metrics) on which it operates. If we were to link an OF with a particular metric, we would end up with a very large number of OFs. **************************************************************************************************** [Ralph1] > 2. How are the nodes in the RPL instance informed about the selected > metric? My understanding of RPL is that only the objective function > is included in the DIO received as an advertisement for a particular > RPL instance, which means a node can't know the selected metric for > that RPL instance and can't meaningfully decide among multiple RPL > instances all using MRHOF as the objective function. > > As a followup to (1), if there were a way to encode the selected > metric for a RPL instance in the DAO, a node would be able to select > which RPL instance to use for a particular type of traffic. > [Mukul1] > The root of a DODAG includes the selected metric objects in the Metric Container Option(s) inside its DIO. The nodes that join this DODAG include the same metric objects in their DIOs and so on. Thats how the nodes come to know which routing metrics are in use in a particular DODAG in a particular RPL Instance. [Ralph2] As I wrote above, my understanding is that a particular RPL instance that specifies MRHOF will use one metric as the selected metric across the entire RPL instance. Is it the case that a node includes only the metric object for the selected metric in a DIO (or no metric object in the case of ETX as the selected metric)? [Mukul2] Yes. Only the "metric object" corresponding to the selected metric should be included in the metric container. What purpose would any other "metric object" serve? The metric container can still contain other "constraint" objects. If the MRHOF draft does not say so, it should. If the metric container were to contain multiple "metric objects", a node implementing MRHOF would not know which metric is the "selected" one. [Ralph2] Does a receiving node infer the selected metric for the RPL instance from the existence of a single metric in the DIO [Mukul2] Yes that is how it should work in my opinion. [Ralph2] or does a node need to be explicitly provisioned to know the selected metric for each RPL instance? [Mukul2] Requiring explicit provisioning of the selected metric does not make sense when the alternative is so easy - just require the meric container to carry one metric object, the one for the selected metric. [Ralph2] Are these details specified in draft-ietf-roll-minrank-hysteresis-of-10? [Mukul2] No. They should be. [Ralph2] Or, am I confused about the binding between a DIO and a RPL instance? [Mukul2] I think you are not confused. MRHOF spec should be clear in this respect. *********************************************************************************** [Ralph1] > > 3. Based on (1) and (2), would configuration and selection issues be > ameliorated if the five candidate selected metrics were each assigned > a separate objective function? Use of a separate OF code point for > each of the five possible selected metrics would allow multiple RPL > instances. > [Mukul1] > Multiple RPL instances with same OF are already allowed. The whole idea behind OF is to separate the rank selection logic from the routing metrics. [Ralph2] OK, but if multiple RPL instances use MRHOF, there is no way for a node to determine which metric is the selected metric for the various RPL instances. [Mukul2] I think the selected metric can easily be identified by requiring it to be the only metric in the metric container. Linking an OF to a particular metric does not seem like a good idea because it would mean exponential increase in the number of OFs as more "rank calculation rules" and more metrics come in use. ********************************************************************************* [Ralph1] > 4. Related to the above, I don't see anything in section 6 about > managing the selected metric. Don't all of the nodes that join a RPL > instance using MRHOF have to be configured to use the same selected > metric? > [Mukul1] > Yes. As mentioned above, the root of a DODAG selects which routing metrics would be used and includes these metric objects inside the Metric Container inside the DIO. A node can join this DAG only if it supports the routin metrics being used. [Ralph2] You refer to "routing metrics". Isn't it the case that a specific RPL instance uses only one metric as the selected metric across all nodes in the RPL instance? Are the nodes configured in the "installer provisioning" (section 6.1) or do nodes infer the selected metric from the metric included in the DIO? [Mukul2] When I said "routing metrics", I was referring to how, in general, the routing metrics in use in a particular instance are identified. You are right, MRHOF works with one selected metric and not multiple metrics. You are also right that Section 6 should say some thing about managing the selected metric. Even if the selected metric is to be identified as the only metric in the metric container, the Manageability section should still say some thing to the effect that all nodes that are supposed to join a particular instance using a particular selected metric must have inbuilt support for that metric. *************************************************************************************************** Thanks Mukul > [Ralph] > 5. In section 3.2.2: > > a > node MAY use a different objective function to select which of these > neighbors should be considered to have the lowest cost. > > seems to contradict the statement in the Introduction that "all nodes > in a network use a common OF." Should "different objective function" > be replaced with "some other selection criteria?" > > [Mukul] > That makes sense to me. OK. > [Ralph] > 6. In section 5, are the RECOMMENDED values appropriate for all > selected metrics or just for ETX? Are there any references that might > be cited that would give background on the working group experience > with ETX and the development of the recommended values? > > 7. In section 6.1, why not "MUST support the DODAG Configuration > option?" I don't see any RFC 2119 requirements on the implementation > of the DODAG Configuration option (which would appera to be an > oversight), but I don't understand how a node can operate in a RPL > instance without, for example, being able to determine the Objective > Function used by that instance. > > [Mukul] > That particular statement indeed sounds redundant to me. I think every RPL implementation MUST understand the DODAG Configuration Option. OK. - Ralph From prvs=496b680bf=mukul@uwm.edu Tue Jun 5 01:55:38 2012 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 C6F5921F86BE for ; Tue, 5 Jun 2012 01:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3iXj7WEH5lAp for ; Tue, 5 Jun 2012 01:55:38 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id E603721F865F for ; Tue, 5 Jun 2012 01:55:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAH3IzU9/AAAB/2dsb2JhbABFhU6yAwEBAQQBAQEgSwsMDw4DBAEBAwINGQIpKAgGE4gLC6Q3iWWJBIEjiXCEfoESA4hAjFuBD45ngn4 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 65B2112E3BA; Tue, 5 Jun 2012 03:55:37 -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 dHc3MTYStPAO; Tue, 5 Jun 2012 03:55:36 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id F03FD12E3AE; Tue, 5 Jun 2012 03:55:36 -0500 (CDT) Date: Tue, 5 Jun 2012 03:55:36 -0500 (CDT) From: Mukul Goyal To: Ralph Droms Message-ID: <1064008108.595562.1338886536842.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <599545E1-7B6A-4649-97F7-E28107C3ECF2@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll , Stiemerling Martin , Haberman Brian Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions 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, 05 Jun 2012 08:55:39 -0000 Hi Ralph ***************************************************************************** [MCR] > - do the nodes of a DODAG have to use the same metrics to pick a parent, > (and if so, how do they agree) > I think that they do not, so long as they use an algorithm (such as > MRHOF) which has certain properties. > [Mukul] Yes, the nodes in a DODAG have to use the same metrics. Otherwise, it is not possible for an OF to map the aggregated (from root till this node) values of the metrics to a rank. [Ralph2] "metrics" or "metric"? [Mukul2] "Metrics" if we are talking about OF in general. "Metric" if we are talking about MRHOF in particular. [Ralph2] Can different nodes use different metrics in a RPL instance that specifies MRHOF? I would think the answer is "no"; i.e., all nodes in a RPL instance MUST use the same metric as the "selected metric". [Mukul2] You are right. ********************************************************************************** [MCR] > - if we had multiple RPL instances in an LLN, using different metrics, > then we would have multiple RPL Instances and DODAGs. The different > set of metrics would not co-exist in the same RPL Instance. [Mukul] > Not sure what does the first sentence mean. About the second, different sets of metrics can certainly coexist in the same RPL instance. An RPL Instance is associated with a particular OF but different DODAGs in the RPL Instance can certainly use different routing metrics. [Ralph2] Perhaps I am confused. Do all the nodes in a single DODAG use the same metric while nodes in different DODAGs (in the same RPL instance) can use different metrics? I.e., for a RPL instance with tow DODAGs, all the nodes in DODAG1 use ETX while all the nodes in DODAG2 use hop count? [Mukul2] I thought so until Pascal told me today that this is not correct. The reason is that a node may want to jump from one DAG to another (e.g. if both DAGs provide connectivity to a particular prefix and the node will have a better rank in the other DAG). But, in order to allow a node to compare its rank in different DAGs, both OF and metrics in use should be same for both DAGs. Thanks Mukul > > ----- Original Message ----- > From: "Michael Richardson" > To: "Pascal Thubert (pthubert)" > Cc: roll@ietf.org > Sent: Friday, May 25, 2012 2:29:49 PM > Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions > > >>>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: > Pascal> I think RPL does not want to take party there. The OF is a > Pascal> piece of logic to tie metrics and policies together. > > My question is: > > - do the nodes of a DODAG have to use the same metrics to pick a parent, > (and if so, how do they agree) > I think that they do not, so long as they use an algorithm (such as > MRHOF) which has certain properties. > > - if we had multiple RPL instances in an LLN, using different metrics, > then we would have multiple RPL Instances and DODAGs. The different > set of metrics would not co-exist in the same RPL Instance. > > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > 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 abdussalambaryun@gmail.com Tue Jun 5 08:37:00 2012 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 01ABC21F86B0 for ; Tue, 5 Jun 2012 08:37:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.489 X-Spam-Level: X-Spam-Status: No, score=-3.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vExE8SUdjAz for ; Tue, 5 Jun 2012 08:36:59 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 625D721F85A5 for ; Tue, 5 Jun 2012 08:36:59 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so3633622vbb.31 for ; Tue, 05 Jun 2012 08:36:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=slzpmvugEDyTt/B16kOWHR2Rk0f0NNXgA8HnKttWZP0=; b=AJy93LRen7HRf9JBzl3kd/aA7mRrxI5Eu+fXPH5PaSdDSPFAuoekRVKwBFAklSVs4a XBrvfT4jX3PORN9ef0dGQ8X+4f3qd/jPoL+K1+zkyz+8RgsqqSWpQSvfzVJ/yjJ1jlIS lg1RkFzuqvEhAKfXnKodvWp7ysmArdWnpPTzC5cYnhsT8sNpmKoO00WZDHiSncU7ZLBu 9SfUxgj9SYleXDYybZzioARbzGbAeGH7c7oTJZyRphNs1T+5h4Exz108arfwR2GV/Ozr InK86ksdkkTGveiWY6dswuHwezAhQqBOowqirqYPCCsgfNq7M27cH/88ekkwo/NtgbFj xcAw== MIME-Version: 1.0 Received: by 10.220.140.193 with SMTP id j1mr4737921vcu.4.1338910618935; Tue, 05 Jun 2012 08:36:58 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Tue, 5 Jun 2012 08:36:58 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jun 2012 17:36:58 +0200 Message-ID: From: Abdussalam Baryun To: roll Content-Type: text/plain; charset=ISO-8859-1 Subject: [Roll] Node Ability to Participate (NAP) 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, 05 Jun 2012 15:37:00 -0000 ++++++++++++++++++ Possible Duplication ++++++++++++++++++++ Hi All, I want to discuss is there a need to consider the node ability to participate (NAP) in LLN functions? I think that the node ability (considering; energy consumption issue, routing issue, and environment-event issue), it is good for some node-originators to know neighbor nodes/sinks ability ( NAP to-route, or NAP continue-to-route, or NAP to-survive, NAP to-store, NAP to-manage, or other abilities), but not sure if it is available in some of the ROLL or 6lowpan protocols, nor sure if it can make side effects to LLN performance. The node-ability can be useful if we have different devices capabilities and conditions. This knowledge-factor can be useful and may be included in some technique, or forwarding table in the protocol specification. I want to know your advises and opinion, thanking you, Best regards Abdussalam Baryun, University of Glamorgan, UK. ======================================================= ( One may be wrong, or may be right, but it does not matter if we work together as a group to discuss and resolve all issues. WGs are always right ) **************************************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. The contents are comply to the IETF regulations, and WG procedures. You should not copy the email nor use it for any other purpose, nor disclose, nor distribute its contents to any other person. ***************************************************************************************** From pal@cs.stanford.edu Wed Jun 6 07:40:53 2012 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 CF8A321F879F for ; Wed, 6 Jun 2012 07:40:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w24aBTgqvYLB for ; Wed, 6 Jun 2012 07:40:52 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id C48C621F873C for ; Wed, 6 Jun 2012 07:40:52 -0700 (PDT) Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[192.168.1.106]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1ScHPm-0002gZ-GJ; Wed, 06 Jun 2012 07:40:51 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: <59F4B025-990D-4738-8424-D8078EF9FB7C@ThomasClausen.org> Date: Wed, 6 Jun 2012 07:25:50 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu> <59F4B025-990D-4738-8424-D8078EF9FB7C@ThomasClausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1257) X-Scan-Signature: bf2d39bfc2650c7e8471b46ddb5f48c6 Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences 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, 06 Jun 2012 14:40:53 -0000 Responses inline. On Jun 3, 2012, at 5:27 PM, Thomas Heide Clausen wrote: >> 10 assumes that a node only uses DIO reception to allow a parent; the = specification is pretty clear that you should check the parent is usable = (section 1.1). You're taking a bad implementation decision and assuming = there isn't another way to do things.=20 >>=20 >=20 > That is definitely a fair point to bring up. >=20 > We agree that various external mechanisms can contribute to make a = smart, or even very smart, parent selection - but, as section 1.1 points = out, as bi-directional links are a minimum requirement, the fact that = RPL doesn't specify a minimum, basic mechanism for ensuring that is = highly problematic. NUD is the only mechanism explicitly called out in = RPL (section 8.2, 9.8, for example), which is why the observations in = section 10 concern RPL when using NUD (and not some other "good (but = unspecified) design decision"). >=20 > We do, however, understand (but correct us if we are wrong) that you = agree that the mechanisms for this problem, as specified in the RPL RFC, = are insufficient for building and operating networks. That is exactly = the point that we are trying to make also. >=20 > Where we may differ in opinion (do we?) is, that we think that the = IETF should specify such mechanisms: in order to make interoperable = implementations, some sort of agreement on what a "good implementation = decision" is required, in particular if such requires messages being = exchanged. In the abstract, I agree -- the IETF should specify such mechanisms = (assuming their specification is needed for interoperability). However, = I think you're taking a dubious philosophical position which is contrary = to all other IETF specifications. No RFC specifies every single detail = of implementation in its entirety. There seems to be a pull for this = from the industrial side, and it's completely mistaken. If we specify = everything immediately, in some cases we will be forced to make = decisions with very limited information and some of those decisions will = be bad. Take a look at the early ZigBee standards. An RFC is not an = implementer's guide: it's a tension between clarity and flexibility, so = that we can continue to produce interoperable implementations with = increasingly better techniques and algorithms. TCP is a canonical = example of this. In that way, I think your draft, as currently written, is disingenuous. = I'm sure I could point out plenty of similar examples in OLSR, or = OLSRv2, or almost any other IETF specification of non-trivial = complexity. This concern or criticism is not specific to RFC6550, but to = the RFC process and the notion of an RFC itself. I'm open to having such = a debate, but my guess is that your position would collapse once you = consider the implications of applying it generally.=20 >> For 11, there are implementations of RPL smaller than 50kB; they do = not implement every feature, but that was kind of the point of the = protocol, that it could be implemented on a sliding scale of = implementation complexity. The TinyOS implementation, for example, is, I = believe, ~20kB, less than half the size. You don't report what = architecture the 50kB is for, clearly it would be more for a 32-bit than = a 16-bit architecture.=20 >=20 > Phil, would you clarify this for us?=20 >=20 > As the specification reads, there is only the MOP flag that can = specify that which the DODAG root expects from the routers in the = network; if a router receives a MOP flag that it doesn't support, it = won't be able to join as anything as a leaf. >=20 > There are no negotiations, or discovery of capabilities, we think, nor = is it clear what exactly the "sliding scale" you refer to is. (sure, we = can see the MOP-scale: DIO only, DAO-nonstoring, DAO-storing - but = beyond that, what do we miss?) Leaf-only operation. Whether or not you'll float.=20 >=20 > Short of heavy-handed administrative configuration, the only realistic = way of ensuring interoperability of devices from different vendors is to = support the full spec. >=20 > But, don't just take our words for complexity issues: >=20 > http://comments.gmane.org/gmane.os.contiki.devel/12102 >=20 > The implementation that we cite (URL is in the draft) is the = ContikiRPL implementation, which only supports storing mode, and which = consumes these ~50 KB (in the above link, they talk about 44KB being = their code size). This on a 16bit MSP 430 tmote sky. Right -- what fraction of the 44kB is RPL, and what fraction is the = Contiki kernel? Saying 44kB is the size of RPL is similar to saying that = xml2rfc is >2GB because Windows is >2GB. I realize that my analogy is = far more extreme than the one above, but it seems that you're playing = fast and loose with numbers in a way to support your argument and so = again being disingenuous. That erodes my confidence in your claims. >> For 12, "implementations may exhibit a bad performance if not = carefully implemented." I think it is safe to say this is true for = almost ANY protocol. >=20 > We think we get your point, and this phrase is indeed a little like = "You can write Fortran77 in any language" ;) >=20 >> A specification is not intended to be a complete statement of = efficient implementation, otherwise you give little latitude to future = improvements and good engineering. >=20 > This is very true, and we agree that a specification should = (necessarily) be indicating the most efficient way of doing something.=20= >=20 > Alas, for example, for DAO messages, as the diffusion mechanism is not = well specified, this may lead to not just inefficiency, but actual = traffic loss by way of connectivity not being accurately reflected in = the information sets on RPL, in very mechanical way.=20 >=20 > It would, of course, be perfectly fine to specify an inefficient - but = working - method, and allow future improvements and good engineering to = better that. Unfortunately, in this case, no working diffusion method is = given (i.e., it may lead to the above issues). >=20 > In addition, it is not just about efficient implementation from one = vendor that could mitigate these problems, but rather about allowing for = interoperable implementations in the same routing domain. I don't think anyone expects an RFC to be perfectly precise. This is one = reason why there are bake-offs. It could be that we take 4 RPL = implementations, each of which has a slightly different DAO diffusion = approach, and they all work together fine. Or they don't -- at which = point we, as a working group, have found a specific issue through = practice, and can write an RFC to better specify the solution. >> For 13, this assumes that a wireless network has a stable topology = which the protocol can converge to. Wireless networks are often NOT = stable: one cannot expect a protocol to converge on a dynamic graph. >=20 > That it absolutely correct. This observation absolutely applies to the = testbed, in which these trickle experiments were conducted. >=20 > The point we want to make here is, that contrary to what we observe in = simulations and modeling, when deploying trickle in wireless networks, = one should expect more control traffic than seen in theory and = simulations. We may be able to do an editorial pass to make this section = clearer -- especially as it seems that we do agree on the fundamental = property that's being discussed? If your point is that simulation and theoretical analysis of wireless = networks are typically far from reality and therefore generally not very = elucidating for real-world behavior, I'd agree with that. But I think = there have been a bunch of experimental studies of how Trickle behaves = in a dynamic and challenging network. The CTP paper, for example. One of = things we found in CTP is that the routing topology is most dynamic when = the network first starts up. Over time, if implemented carefully, nodes = settle on stable rather than dynamic links and the control traffic = continually decreases over the period of hours and even days. = Fundamentally, nodes have to probe the RF environment to figure out = which links are good and stable, and this takes time. There are some = shortcuts (e.g., using physical layer information), but including = something PHY-specific in an RFC is a big no-no. >=20 >> 14 is similarly confused about what a wireless network looks like. = How can the state of a distributed system based on a dynamic topology be = "consistent?" I think this is a fundamental misunderstanding of how the = network works. >=20 > We are a little unclear on what you mean here, or what you suggest = that we disagree on. Is it the use of "inconsistent" in the penultimate = paragraph of page 24?=20 >=20 Yes. Phil From pal@cs.stanford.edu Wed Jun 6 07:42:48 2012 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 8D25621F8842 for ; Wed, 6 Jun 2012 07:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VLbyEbMhmuCp for ; Wed, 6 Jun 2012 07:42:48 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 14B3C21F884C for ; Wed, 6 Jun 2012 07:42:48 -0700 (PDT) Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[192.168.1.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1ScHRe-0006NT-NS; Wed, 06 Jun 2012 07:42:46 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> Date: Wed, 6 Jun 2012 07:43:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 764eb63bb4c91aa8ddbf2de6f9e489d2 Cc: Stiemerling Martin , roll , Michael Richardson , Haberman Brian Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec 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, 06 Jun 2012 14:42:48 -0000 Responses inline. On Jun 4, 2012, at 9:31 AM, Ralph Droms wrote: >>=20 >=20 > My question here is why a single objective function "MRHOF" is defined = to use several different metrics. My understanding is that any specific = RPL instance will use one metric as its "selected metric" for MRHOF. = Another way to organize the objective functions would be to define a = different OF number for each metric, binding the OF number to the = selected metric. This was a design decision made early in RPL. There were two options: = OFs are metric-specific, or OFs can be general with respect to metrics. = The design team concluded the second approach was better, as the former = would lead to a possibly huge number of OFs that would be hard to = manage. Phil From jpv@cisco.com Wed Jun 6 11:47:52 2012 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 60C9921F8762 for ; Wed, 6 Jun 2012 11:47:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.383 X-Spam-Level: X-Spam-Status: No, score=-110.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ziRmXMSvkFEy for ; Wed, 6 Jun 2012 11:47:51 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id ADACF21F869D for ; Wed, 6 Jun 2012 11:47:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=535; q=dns/txt; s=iport; t=1339008471; x=1340218071; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=C4vlMXQtF/0cXpsnjzD0fcpU0fjZeVJuPVvYU49rk4I=; b=UTPXgr2VRWecZ/9vqWDS5D2PUmIDjdYEgJKWC/HuvsRvLNdzDlZLooHy rHiJXajEV2pndZeipgG4LVfdEGkD7KZ9JXTXQLk3b3r5Pj/hXSMZWfyZ1 jS4A73RgwXFTefTwhssOttDrTIlNV8BHueiBzHMSGybfn81RYxnavd3EY Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAN+kz09Io8UY/2dsb2JhbABFtT2CMQEKHT+BPjWHaQuYT59vBIs8hRVgA5UdhVOIQYFmgmI X-IronPort-AV: E=Sophos;i="4.75,725,1330905600"; d="scan'208";a="13886822" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 06 Jun 2012 18:47:48 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by bgl-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q56Ilm75005729; Wed, 6 Jun 2012 18:47:48 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); Thu, 7 Jun 2012 02:47:48 +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); Thu, 7 Jun 2012 02:47:46 +0800 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 6 Jun 2012 20:47:44 +0200 Message-Id: To: roll WG Mime-Version: 1.0 (Apple Message framework v1278) X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 06 Jun 2012 18:47:47.0058 (UTC) FILETIME=[DD8BE520:01CD4414] Subject: [Roll] Publication request for draft-ietf-roll-p2p-rpl-13 and draft-ietf-roll-p2p-measurement-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: Wed, 06 Jun 2012 18:47:52 -0000 Dear all, Both draft-ietf-roll-p2p-rpl-13 and draft-ietf-roll-p2p-measurement-05 = are now ready for publication. As a reminder, we had two WG last call for these documents, which led to = the following tickets: 85 86 87 88 89 90 91 92 93 94 95 96 97 89 100 101 = and 102 (see https://svn.tools.ietf.org/wg/roll/trac/report/6 for = details); thanks to all of you who comments and to the editors of the = documents who actively worked to get to a closure. Publication requests will be issued shortly. JP and Michael.= From abdussalambaryun@gmail.com Thu Jun 7 02:00:25 2012 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 3254821F85C7; Thu, 7 Jun 2012 02:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.507 X-Spam-Level: X-Spam-Status: No, score=-3.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UuaucO8ELrSB; Thu, 7 Jun 2012 02:00:24 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 05E6921F84EC; Thu, 7 Jun 2012 02:00:23 -0700 (PDT) Received: by vcqp1 with SMTP id p1so216930vcq.31 for ; Thu, 07 Jun 2012 02:00:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=sK3qMWCUEhfZkWthTeHumBBxlNjtY9YtxJGeqJVyfuY=; b=seaf4W4TAni6AlzmObScmRglowmAtMsMKFDq8H2k/Uc2GwLJZvXexS20FkKV8aGkFQ O1h0+NhSMUklSBz1C0HA01bku6x6CxczQFXff+fiobJjOWvmj/v2ewwlF8lkBfJTmY0X O+pHxb83XI8cE6mrkWGVTv92dKM3Q+ciuAKcdAZMNNsLbnjTZaD+nhTIMSZN2xlVJa+4 WtLNgtUeUdWSsBtOStatP95ED3EGw7L/h+TLxtCogvpmL+2PAuq4BRumDFqa+TFZyTG6 Ppt1aYDkU7xspc6fLSzovmej3dFgponSHqSNZztyMQe/RKKgcYgkgBTKF6hfcz0J6vpf 9iKw== MIME-Version: 1.0 Received: by 10.52.33.37 with SMTP id o5mr1058750vdi.86.1339059622651; Thu, 07 Jun 2012 02:00:22 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Thu, 7 Jun 2012 02:00:22 -0700 (PDT) In-Reply-To: <17448.1339014690@marajade.sandelman.ca> References: <1FFD6787-3529-462B-B59A-115ADC99B842@cisco.com> <13731.1338814785@marajade.sandelman.ca> <4787.1338995178@marajade.sandelman.ca> <17448.1339014690@marajade.sandelman.ca> Date: Thu, 7 Jun 2012 11:00:22 +0200 Message-ID: From: Abdussalam Baryun To: roll Content-Type: text/plain; charset=ISO-8859-1 Cc: roll-owner Subject: [Roll] Node Ability to Participate (NAP) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 09:00:25 -0000 +++++++++++++++++ Possible Duplication +++++++++++++++++++++++ Hi All, I want to discuss is there a need to consider the node ability to participate (NAP) in LLN functions? I think that the node ability (considering; energy consumption issue, routing issue, and environment-event issue), it is good for some node-originators to know neighbor nodes/sinks ability ( NAP to-route, or NAP continue-to-route, or NAP to-survive, NAP to-store, NAP to-manage, or other abilities), but not sure if it is available in some of the ROLL or 6lowpan protocols, nor sure if it can make side effects to LLN performance. The node-ability can be useful if we have different devices capabilities and conditions. This knowledge-factor can be useful and may be included in some technique, or forwarding table in the protocol specification. I want to know your advises and opinion, thanking you, Best regards Abdussalam Baryun, University of Glamorgan, UK. ======================================================= < One may be wrong, or may be right, but it does not matter if we work together as a group to discuss and resolve all issues. IETF WGs are always right > **************************************************************************************** This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. The contents are comply to the IETF regulations, and WG procedures. You should not copy the email nor use it for any purpose other than IETF procedures' purposes. ***************************************************************************************** From rdroms.ietf@gmail.com Thu Jun 7 12:48:31 2012 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 ACE3621F8670 for ; Thu, 7 Jun 2012 12:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.385 X-Spam-Level: X-Spam-Status: No, score=-103.385 tagged_above=-999 required=5 tests=[AWL=0.214, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ICd-+IUi8sB for ; Thu, 7 Jun 2012 12:48:31 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE5B21F8680 for ; Thu, 7 Jun 2012 12:48:31 -0700 (PDT) Received: by vcqp1 with SMTP id p1so598896vcq.31 for ; Thu, 07 Jun 2012 12:48:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=hEmTl3YRny8en/jBpjIsA3gJ6JdQXmSYtyM7M0hItn0=; b=wggkJyLTqepaz6wME9pq6Xda8VVnBKEq8SnEbJxd5hW7BpyZ8U6w3rpqPSgKniBlcQ EStD0UECb3DPFMfgDap9wNmm0nXmvPM2KeGsa7ljcOtL741OzE7esaOwa1h813/2lx/V bgAbnEK8h2wQ3pht9J/eI1mPSnd4aJ0hhACuQlqKroF9Wwsj5IDXBYIpNbCof5uFpdgf BR07rnF19HJ10viSGdDOqqSME2T/8Z+4Jd9WZXIVt8p9Aa9/OrWKEaYhcU9KJ39t+6Ec 0Cp1sOI6yw4zW74yw1SRaIW0xSiW1SbFEd6z0Ne78sMrnYd9QYG/UdlqrJx4DmTZ4c8h IZaA== Received: by 10.220.153.80 with SMTP id j16mr3327709vcw.55.1339098510454; Thu, 07 Jun 2012 12:48:30 -0700 (PDT) Received: from bxb-vpn3-696.cisco.com (198-135-0-233.cisco.com. [198.135.0.233]) by mx.google.com with ESMTPS id i10sm5909894vdw.21.2012.06.07.12.48.26 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 07 Jun 2012 12:48:28 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> Date: Thu, 7 Jun 2012 15:48:24 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> To: Philip Levis X-Mailer: Apple Mail (2.1278) Cc: Haberman Brian , Stiemerling Martin , Michael Richardson , roll Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 19:48:31 -0000 On Jun 6, 2012, at 10:43 AM 6/6/12, Philip Levis wrote: > Responses inline. >=20 > On Jun 4, 2012, at 9:31 AM, Ralph Droms wrote: >=20 >>>=20 >>=20 >> My question here is why a single objective function "MRHOF" is = defined to use several different metrics. My understanding is that any = specific RPL instance will use one metric as its "selected metric" for = MRHOF. Another way to organize the objective functions would be to = define a different OF number for each metric, binding the OF number to = the selected metric. >=20 > This was a design decision made early in RPL. There were two options: = OFs are metric-specific, or OFs can be general with respect to metrics. = The design team concluded the second approach was better, as the former = would lead to a possibly huge number of OFs that would be hard to = manage. Now that a real OF has actually been designed and specified, perhaps = this would be a good time to reconfirm that design decision. Given that MRHOF is a pretty general objective function, and works over = 5 (or perhaps 3) metrics, 16 bits would seem to provide plenty of code = points for metric-specific OFs. A bigger issue, I think, is expressing the semantics or behavior of an = OF in its OCP. I read section 18.6 of RFC 6550 to indicate that a node = will use information including the OF (as indicated by the OCP) to = compare against the node's policy for joining a DODAG. As an aside, is = there a reason why a node would choose to join a specific DODAG within a = RPL Instance and on what basis would it make that choice? Anyway, = wouldn't the selected metric used by MRHOF in a particular RPL Instance = be a useful parameter for the policy rules? For example, I can imagine = a node preferring to join a RPL Instance providing minimal latency over = one providing best ETX. If the OCP is metric-specific, that selected = metric will be immediately available for the policy rules. - Ralph >=20 > Phil >=20 From pthubert@cisco.com Thu Jun 7 14:04:10 2012 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 2E11121F86A6; Thu, 7 Jun 2012 14:04:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OEV8Mzhiz3qZ; Thu, 7 Jun 2012 14:04:09 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id EC79121F86A0; Thu, 7 Jun 2012 14:04:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=3101; q=dns/txt; s=iport; t=1339103049; x=1340312649; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UJDIyjtzRM2Fex+/9IsmYdrwtPShMrzhr+jqaM7kODg=; b=l/ndFirvu7F5HAboaFGOtEasJug6SAV86QkD+9g+x7q0LQIJaO1pPL8J sTjDqdn3EDvgWmSPER+Spo105YK93d5WXMGtQUB6169rf4jr0lE0vNXmN Vj3Qnny5StCE/loUnCgYpsbofwBUcbfPjO3oQILPGNEXlvr6WK4KduFIJ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADsW0U+tJXG9/2dsb2JhbABFtE2BB4IYAQEBBAEBAQ8BJzQLDAQCAQgRBAEBCwISCQcnCxQJCAIEAQ0FCAEZh2kLmTGfcosdGoUGYAOjMYFmgmCBXw X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="90524047" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 07 Jun 2012 21:04:06 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q57L46RY007179 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Jun 2012 21:04:06 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.238]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0298.004; Thu, 7 Jun 2012 16:04:06 -0500 From: "Pascal Thubert (pthubert)" To: Abdussalam Baryun , roll Thread-Topic: [Roll] Node Ability to Participate (NAP) Thread-Index: AQHNRIwAf/4MdCQwJU6OqNpRkXdUw5bvBkaw Date: Thu, 7 Jun 2012 21:04:06 +0000 Deferred-Delivery: Thu, 7 Jun 2012 21:04:00 +0000 Message-ID: References: <1FFD6787-3529-462B-B59A-115ADC99B842@cisco.com> <13731.1338814785@marajade.sandelman.ca> <4787.1338995178@marajade.sandelman.ca> <17448.1339014690@marajade.sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.101.223] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18954.001 x-tm-as-result: No--49.132200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: roll-owner Subject: Re: [Roll] Node Ability to Participate (NAP) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 21:04:10 -0000 Hello Abdussalam: I'd say it is a great discussion that might end up impacting routing. But a= lso basic network operations (DNS, DHCP ...) and services. So where is the right place to start with? Tthe COMA mailing list is starting about network management, and I'd have t= hought that your discussion could begin there. What do you think? " List address: coma@ietf.org Archive: http://www.ietf.org/mail-archive/web/coma/ To subscribe: https://www.ietf.org/mailman/listinfo/coma=20 Purpose: This list is for the discussion related to the management of const= rained networks and devices. The IETF so far has not developed specific tec= hnologies for the management of constrained networks. There is a need to un= derstand the requirements for the management of such a constrained network = and its devices.=20 " Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Abd= ussalam Baryun Sent: jeudi 7 juin 2012 11:00 To: roll Cc: roll-owner Subject: [Roll] Node Ability to Participate (NAP) +++++++++++++++++ Possible Duplication +++++++++++++++++++++++ Hi All, I want to discuss is there a need to consider the node ability to participa= te (NAP) in LLN functions? I think that the node ability (considering; energy consumption issue, routi= ng issue, and environment-event issue), it is good for some node-originator= s to know neighbor nodes/sinks ability ( NAP to-route, or NAP continue-to-r= oute, or NAP to-survive, NAP to-store, NAP to-manage, or other abilities), = but not sure if it is available in some of the ROLL or 6lowpan protocols, n= or sure if it can make side effects to LLN performance. The node-ability ca= n be useful if we have different devices capabilities and conditions. This = knowledge-factor can be useful and may be included in some technique, or fo= rwarding table in the protocol specification. I want to know your advises and opinion, thanking you, Best regards Abdussalam Baryun, University of Glamorgan, UK. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D < One may be wrong, or may be right, but it does not matter if we work tog= ether as a group to discuss and resolve all issues. IETF WGs are always rig= ht > ***************************************************************************= ************* This email and any attachments are confidential to the intended recipient a= nd may also be privileged. If you are not the intended recipient please del= ete it from your system and notify the sender. The contents are comply to t= he IETF regulations, and WG procedures. You should not copy the email nor u= se it for any purpose other than IETF procedures' purposes. ***************************************************************************= ************** _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Thu Jun 7 14:49:10 2012 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 3E30C11E8154 for ; Thu, 7 Jun 2012 14:49:10 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IP3uYXEPkGf8 for ; Thu, 7 Jun 2012 14:49:09 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 8EADC21F8523 for ; Thu, 7 Jun 2012 14:49:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2669; q=dns/txt; s=iport; t=1339105749; x=1340315349; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Hu4chfzFHJ5kFaEFkX/7WNp5eBuww//SjgmjS5K6IQA=; b=OjIddSK6Bevahq2vFfmxoLZVirawXA3nF/UvO9ePIjOlTwP/RqaRYYt6 6eHgG8FEIERcunAyt8thqj+p/gqoOVni/unsIRc1kSYuI6JyYGtis5flt Arl9IbtDh4br68rL9Fhv/I5W382keJfv6WqXD9zA/3ghgJhbpibqzDB84 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAPkg0U+tJV2b/2dsb2JhbABFDrQ/gQeCGAEBAQMBAQEBDwEnNAsFCwIBCA4KChQQJwslAgQBDQUIGodkBQuZKp9vBIsdhSBgA6MxgWaCJzk X-IronPort-AV: E=Sophos;i="4.75,732,1330905600"; d="scan'208";a="90554081" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-8.cisco.com with ESMTP; 07 Jun 2012 21:49:09 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q57Ln9An003926 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Jun 2012 21:49:09 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.238]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0298.004; Thu, 7 Jun 2012 16:49:08 -0500 From: "Pascal Thubert (pthubert)" To: Ralph Droms , Philip Levis Thread-Topic: [Roll] Ralph's DISCUSS on MRHOF spec Thread-Index: AQHNROaHASEccMIy+EC596uJfU+pA5bvYuSA Date: Thu, 7 Jun 2012 21:49:08 +0000 Deferred-Delivery: Thu, 7 Jun 2012 21:49:00 +0000 Message-ID: References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.101.223] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18954.001 x-tm-as-result: No--33.458100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Haberman Brian , roll , Stiemerling Martin , Michael Richardson Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 21:49:10 -0000 On Jun 6, 2012, at 10:43 AM 6/6/12, Philip Levis wrote: > Responses inline. >=20 > On Jun 4, 2012, at 9:31 AM, Ralph Droms wrote: >=20 >>>=20 >>=20 >> My question here is why a single objective function "MRHOF" is defined t= o use several different metrics. My understanding is that any specific RPL= instance will use one metric as its "selected metric" for MRHOF. Another = way to organize the objective functions would be to define a different OF n= umber for each metric, binding the OF number to the selected metric. >=20 > This was a design decision made early in RPL. There were two options: OFs= are metric-specific, or OFs can be general with respect to metrics. The de= sign team concluded the second approach was better, as the former would lea= d to a possibly huge number of OFs that would be hard to manage. Now that a real OF has actually been designed and specified, perhaps this w= ould be a good time to reconfirm that design decision. Given that MRHOF is a pretty general objective function, and works over 5 (= or perhaps 3) metrics, 16 bits would seem to provide plenty of code points = for metric-specific OFs. A bigger issue, I think, is expressing the semantics or behavior of an OF i= n its OCP. I read section 18.6 of RFC 6550 to indicate that a node will us= e information including the OF (as indicated by the OCP) to compare against= the node's policy for joining a DODAG. As an aside, is there a reason why= a node would choose to join a specific DODAG within a RPL Instance and on = what basis would it make that choice? Anyway, wouldn't the selected metric= used by MRHOF in a particular RPL Instance be a useful parameter for the = policy rules? For example, I can imagine a node preferring to join a RPL I= nstance providing minimal latency over one providing best ETX. If the OCP = is metric-specific, that selected metric will be immediately available for = the policy rules. [Pascal] I agree with Ralph here. I fail to be convinced that there will an= explosion of OCPs if we fail to factorize the metrics. But I see how the d= evice implementation can be simplified if the OCP says it all. Also, we do = not want to force a device that implements MRHOF to have to implement all m= etrics in the I-D. Conversely, say we extend MrHof to other metrics with fu= rther work, wouldn't it become OCP 2 anyway? I wouldn't mind blocking OCP 1= ..9 for current and future MrHof metric variations. Cheers, =20 - Ralph >=20 > Phil >=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From gnawali@cs.uh.edu Thu Jun 7 16:24:45 2012 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 7439111E80E4 for ; Thu, 7 Jun 2012 16:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.717 X-Spam-Level: X-Spam-Status: No, score=-5.717 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcYNL1wXVr2F for ; Thu, 7 Jun 2012 16:24:44 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id BE2C811E8088 for ; Thu, 7 Jun 2012 16:24:44 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id A075423CAFE for ; Thu, 7 Jun 2012 18:24:41 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ngXknwu3SpL for ; Thu, 7 Jun 2012 18:24:41 -0500 (CDT) Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 4DF8C23CAFF for ; Thu, 7 Jun 2012 18:24:38 -0500 (CDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by it.cs.uh.edu (Postfix) with ESMTP id 6A8402A280CF for ; Thu, 7 Jun 2012 18:22:11 -0500 (CDT) Received: by eaaq13 with SMTP id q13so675165eaa.31 for ; Thu, 07 Jun 2012 16:24:39 -0700 (PDT) Received: by 10.14.95.67 with SMTP id o43mr2192694eef.13.1339111478959; Thu, 07 Jun 2012 16:24:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.101.168 with HTTP; Thu, 7 Jun 2012 16:24:18 -0700 (PDT) In-Reply-To: <4FD137A4.3080801@innovationslab.net> References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <4FD137A4.3080801@innovationslab.net> From: Omprakash Gnawali Date: Thu, 7 Jun 2012 18:24:18 -0500 Message-ID: To: Brian Haberman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Stiemerling Martin , Michael Richardson , roll Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 23:24:45 -0000 On Thu, Jun 7, 2012 at 6:22 PM, Brian Haberman w= rote: > On 6/7/12 6:12 PM, Omprakash Gnawali wrote: >> >> On Thu, Jun 7, 2012 at 4:49 PM, Pascal Thubert (pthubert) >> =A0wrote: >>> >>> >>> On Jun 6, 2012, at 10:43 AM 6/6/12, Philip Levis wrote: >>> >>>> Responses inline. >>>> >>>> On Jun 4, 2012, at 9:31 AM, Ralph Droms wrote: >>>> >>>>>> >>>>> >>>>> My question here is why a single objective function "MRHOF" is >>>>> defined to use several different metrics. =A0My understanding is >>>>> that any specific RPL instance will use one metric as its >>>>> "selected metric" for MRHOF. =A0Another way to organize the >>>>> objective functions would be to define a different OF number >>>>> for each metric, binding the OF number to the selected metric. >>>> >>>> >>>> This was a design decision made early in RPL. There were two >>>> options: OFs are metric-specific, or OFs can be general with >>>> respect to metrics. The design team concluded the second approach >>>> was better, as the former would lead to a possibly huge number of >>>> OFs that would be hard to manage. >>> >>> >>> Now that a real OF has actually been designed and specified, >>> perhaps this would be a good time to reconfirm that design >>> decision. >>> >>> Given that MRHOF is a pretty general objective function, and works >>> over 5 (or perhaps 3) metrics, 16 bits would seem to provide plenty >>> of code points for metric-specific OFs. >>> >>> A bigger issue, I think, is expressing the semantics or behavior of >>> an OF in its OCP. =A0I read section 18.6 of RFC 6550 to indicate that >>> a node will use information including the OF (as indicated by the >>> OCP) to compare against the node's policy for joining a DODAG. =A0As >>> an aside, is there a reason why a node would choose to join a >>> specific DODAG within a RPL Instance and on what basis would it >>> make that choice? =A0Anyway, wouldn't the selected metric =A0used by >>> MRHOF in a particular RPL Instance be a useful parameter for the >>> policy rules? =A0For example, I can imagine a node preferring to join >>> a RPL Instance providing minimal latency over one providing best >>> ETX. =A0If the OCP is metric-specific, that selected metric will be >>> immediately available for the policy rules. >>> >>> >>> [Pascal] I agree with Ralph here. I fail to be convinced that there >>> will an explosion of OCPs if we fail to factorize the metrics. But >>> I see how the device implementation can be simplified if the OCP >>> says it all. Also, we do not want to force a device that implements >>> MRHOF to have to implement all metrics in the I-D. Conversely, say >>> we extend MrHof to other metrics with further work, wouldn't it >>> become OCP 2 anyway? I wouldn't mind blocking OCP 1..9 for current >>> and future MrHof metric variations. >> >> >> Just one clarification - MRHOF does not require the devices to >> support all the metrics listed in the I-D. All it says is it must >> implement at least one metric. > > > Excuse the pedantic question, but won't there be an issue if half the > devices in an RPL instance implement one metric and the other half implem= ent > a different metric? =A0This would seem to force users to select all their > devices based on which metric they want to use. If metrics are not the same, the nodes can work as leaf. The I-D says nodes SHOULD support ETX so there is a hope that the networks might support ETX. - om_p From dat@exegin.com Thu Jun 7 16:34:35 2012 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 D3EA021F85C9 for ; Thu, 7 Jun 2012 16:34: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=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mS6RmFQidIfy for ; Thu, 7 Jun 2012 16:34:35 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6B16F21F85C2 for ; Thu, 7 Jun 2012 16:34:35 -0700 (PDT) Received: by dacx6 with SMTP id x6so1555715dac.31 for ; Thu, 07 Jun 2012 16:34:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=JKEJipADJramXawyZPMkDEUEsJncdisDrQVl/l546vU=; b=dNXcQZl2qr/sIyzwK79yGBSN9bCzgCIpAFKgYmS6SedDcifB15Ij3Bf8BTcyqOdzE0 Vy3U3te6mEazeX0jscVW4g8K3gS+xs3bmauuP7xHaARSGzdFUmLW/i7OWAFLUEzLdiLk 6Cv78DDVzePdLfmjp0w0unRA3alPnmRRuKYsCvEjjyIv8FhsSCo130fVNqjCFf8appK/ Db/J4NbGBGbBkeMEGduoJiGTcO18fA2FjUk2N8XApNSdmSCvvvofR4JvdkP6oiqGhrjd UK+06I3Q6qy/+EeVqn/0u9T7ISSNK1HnRXl0IqP/uqNJ/SJeOVgDapwKrniYvGkV4uGG Jh6A== Received: by 10.68.227.163 with SMTP id sb3mr14007959pbc.74.1339112075267; Thu, 07 Jun 2012 16:34:35 -0700 (PDT) Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id ku7sm5652093pbc.31.2012.06.07.16.34.34 (version=SSLv3 cipher=OTHER); Thu, 07 Jun 2012 16:34:34 -0700 (PDT) Message-ID: <4FD13A8D.2010703@exegin.com> Date: Thu, 07 Jun 2012 16:34:37 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkoA6x9UXQgPObrS4n2g97dnbiOzuBGIH+HAPaQoomra77+HsUye07oals32fnPZAUSM9K+ Cc: 'ROLL WG' Subject: [Roll] MRHOF ETX X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 23:34:36 -0000 Hi Philip When MRHOF refers to ETX, is it the ETX value as defined in RFC6551 (i.e. ETX * 128) or some ETX value defined by implementation? Could this be made more clear in the spec, because we are currently having a discussion in ZigBee-IP as to what this value should be? Dario From gnawali@cs.uh.edu Thu Jun 7 16:45:37 2012 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 A8D8A11E80FE for ; Thu, 7 Jun 2012 16:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.749 X-Spam-Level: X-Spam-Status: No, score=-5.749 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COOWJSudrJJD for ; Thu, 7 Jun 2012 16:45:37 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1AC1611E80FD for ; Thu, 7 Jun 2012 16:45:37 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 6A75523CB05 for ; Thu, 7 Jun 2012 18:45:34 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HHPxnNljt7XY for ; Thu, 7 Jun 2012 18:45:31 -0500 (CDT) Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 2EFC923CB04 for ; Thu, 7 Jun 2012 18:45:31 -0500 (CDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by it.cs.uh.edu (Postfix) with ESMTP id 5BEF72A280C4 for ; Thu, 7 Jun 2012 18:43:04 -0500 (CDT) Received: by eaaq13 with SMTP id q13so685854eaa.31 for ; Thu, 07 Jun 2012 16:45:32 -0700 (PDT) Received: by 10.14.40.20 with SMTP id e20mr2476469eeb.119.1339112731996; Thu, 07 Jun 2012 16:45:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.101.168 with HTTP; Thu, 7 Jun 2012 16:45:11 -0700 (PDT) In-Reply-To: <4FD13A8D.2010703@exegin.com> References: <4FD13A8D.2010703@exegin.com> From: Omprakash Gnawali Date: Thu, 7 Jun 2012 18:45:11 -0500 Message-ID: To: Dario Tedeschi Content-Type: text/plain; charset=ISO-8859-1 Cc: ROLL WG Subject: Re: [Roll] MRHOF ETX X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 23:45:38 -0000 On Thu, Jun 7, 2012 at 6:34 PM, Dario Tedeschi wrote: > Hi Philip > > When MRHOF refers to ETX, is it the ETX value as defined in RFC6551 (i.e. > ETX * 128) or some ETX value defined by implementation? > > Could this be made more clear in the spec, because we are currently having a > discussion in ZigBee-IP as to what this value should be? ETX * 128 as in 6551. The suggested value for parent switch threshold with ETX is given in 6551 format in -10. But I just noticed that I forgot to convert it to 6551 format for max link and max path values. They should all be ETX * 128. - om_p From abdussalambaryun@gmail.com Thu Jun 7 20:48:29 2012 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 7AA9B11E816C; Thu, 7 Jun 2012 20:48:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xO-HXi45QNtB; Thu, 7 Jun 2012 20:48:28 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6257911E80B3; Thu, 7 Jun 2012 20:48:24 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so873087vbb.31 for ; Thu, 07 Jun 2012 20:48:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7SzKFibBbDZXylEigmUHPxIhKr195tGLZJSDazSih1o=; b=JaJ5MV2t09vzqkpKMkJXRRpBDipTc9gMIrfNsiVhiffG+fFKEI3Moc0Fl0fYku6vYq RQ6EaAFVOymjPfV/ek2Vey48e+Zd+3XqDK+/R13GBWBv+Qhe5IbXJFGYkN/TpdSNQTT+ kz2Yn1PiDmz+Haibuz6q98BDR8thbkr7FBpCRwQO5e6w93GK7nLZEstYxAqPqN2TDEZt QS8ymJ2Cs88DRfIF67N1yJjJN4sr3qlUb6D9lknTVtewsIiRY7Q2zLSYbTRbRyh8otSY P8m7tcv2uhtNwAriHj+yvdG8bRhukrNu7AZEmjloHtVZkfFkjOFCjDOMYxF3ocn28XJt FeOg== MIME-Version: 1.0 Received: by 10.52.90.196 with SMTP id by4mr3988010vdb.103.1339127303929; Thu, 07 Jun 2012 20:48:23 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Thu, 7 Jun 2012 20:48:23 -0700 (PDT) In-Reply-To: References: <1FFD6787-3529-462B-B59A-115ADC99B842@cisco.com> <13731.1338814785@marajade.sandelman.ca> <4787.1338995178@marajade.sandelman.ca> <17448.1339014690@marajade.sandelman.ca> Date: Fri, 8 Jun 2012 05:48:23 +0200 Message-ID: From: Abdussalam Baryun To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 Cc: roll , roll-owner Subject: Re: [Roll] Node Ability to Participate (NAP) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 03:48:29 -0000 Hi Pascal, I was thinking of route-control enhancement, not network management, however, I agree it is an iteresting issue as well, you gave me a new point, thanks, Abdussalam Baryun ======================= On 6/7/12, Pascal Thubert (pthubert) wrote: > Hello Abdussalam: > > I'd say it is a great discussion that might end up impacting routing. But > also basic network operations (DNS, DHCP ...) and services. > So where is the right place to start with? > Tthe COMA mailing list is starting about network management, and I'd have > thought that your discussion could begin there. > > What do you think? > > > " > List address: coma@ietf.org > Archive: http://www.ietf.org/mail-archive/web/coma/ > To subscribe: https://www.ietf.org/mailman/listinfo/coma > > Purpose: This list is for the discussion related to the management of > constrained networks and devices. The IETF so far has not developed specific > technologies for the management of constrained networks. There is a need to > understand the requirements for the management of such a constrained network > and its devices. > " > > Cheers, > > Pascal > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Abdussalam Baryun > Sent: jeudi 7 juin 2012 11:00 > To: roll > Cc: roll-owner > Subject: [Roll] Node Ability to Participate (NAP) > > +++++++++++++++++ Possible Duplication +++++++++++++++++++++++ > Hi All, > > I want to discuss is there a need to consider the node ability to > participate (NAP) in LLN functions? > > I think that the node ability (considering; energy consumption issue, > routing issue, and environment-event issue), it is good for some > node-originators to know neighbor nodes/sinks ability ( NAP to-route, or NAP > continue-to-route, or NAP to-survive, NAP to-store, NAP to-manage, or other > abilities), but not sure if it is available in some of the ROLL or 6lowpan > protocols, nor sure if it can make side effects to LLN performance. The > node-ability can be useful if we have different devices capabilities and > conditions. This knowledge-factor can be useful and may be included in some > technique, or forwarding table in the protocol specification. > > I want to know your advises and opinion, thanking you, > > Best regards > > Abdussalam Baryun, > University of Glamorgan, UK. > ======================================================= > < One may be wrong, or may be right, but it does not matter if we work > together as a group to discuss and resolve all issues. IETF WGs are always > right > > **************************************************************************************** > This email and any attachments are confidential to the intended recipient > and may also be privileged. If you are not the intended recipient please > delete it from your system and notify the sender. The contents are comply to > the IETF regulations, and WG procedures. You should not copy the email nor > use it for any purpose other than IETF procedures' purposes. > ***************************************************************************************** > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pal@cs.stanford.edu Thu Jun 7 21:02:27 2012 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 4D52111E8171 for ; Thu, 7 Jun 2012 21:02:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MtOy6TxARaaf for ; Thu, 7 Jun 2012 21:02:26 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id B491B11E80B2 for ; Thu, 7 Jun 2012 21:02:26 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.103]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1ScqP2-0001wu-JD; Thu, 07 Jun 2012 21:02:24 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Thu, 7 Jun 2012 21:02:23 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 3fe17504c5843e76b9e439a63759b02e Cc: Haberman Brian , roll , Stiemerling Martin , Michael Richardson Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 04:02:27 -0000 On Jun 7, 2012, at 2:49 PM, Pascal Thubert (pthubert) wrote: >=20 > On Jun 6, 2012, at 10:43 AM 6/6/12, Philip Levis wrote: >=20 >> Responses inline. >>=20 >> On Jun 4, 2012, at 9:31 AM, Ralph Droms wrote: >>=20 >>>>=20 >>>=20 >>> My question here is why a single objective function "MRHOF" is = defined to use several different metrics. My understanding is that any = specific RPL instance will use one metric as its "selected metric" for = MRHOF. Another way to organize the objective functions would be to = define a different OF number for each metric, binding the OF number to = the selected metric. >>=20 >> This was a design decision made early in RPL. There were two options: = OFs are metric-specific, or OFs can be general with respect to metrics. = The design team concluded the second approach was better, as the former = would lead to a possibly huge number of OFs that would be hard to = manage. >=20 > Now that a real OF has actually been designed and specified, perhaps = this would be a good time to reconfirm that design decision. >=20 > Given that MRHOF is a pretty general objective function, and works = over 5 (or perhaps 3) metrics, 16 bits would seem to provide plenty of = code points for metric-specific OFs. >=20 > A bigger issue, I think, is expressing the semantics or behavior of an = OF in its OCP. I read section 18.6 of RFC 6550 to indicate that a node = will use information including the OF (as indicated by the OCP) to = compare against the node's policy for joining a DODAG. As an aside, is = there a reason why a node would choose to join a specific DODAG within a = RPL Instance and on what basis would it make that choice? Anyway, = wouldn't the selected metric used by MRHOF in a particular RPL Instance = be a useful parameter for the policy rules? For example, I can imagine = a node preferring to join a RPL Instance providing minimal latency over = one providing best ETX. If the OCP is metric-specific, that selected = metric will be immediately available for the policy rules. >=20 >=20 > [Pascal] I agree with Ralph here. I fail to be convinced that there = will an explosion of OCPs if we fail to factorize the metrics. But I see = how the device implementation can be simplified if the OCP says it all. = Also, we do not want to force a device that implements MRHOF to have to = implement all metrics in the I-D. Conversely, say we extend MrHof to = other metrics with further work, wouldn't it become OCP 2 anyway? I = wouldn't mind blocking OCP 1..9 for current and future MrHof metric = variations. I agree that this is a good question to ask. I disagree that now is an = appropriate time to answer it definitively; we currently have only one = OCP. We made a concrete and deliberate design decision. I'd argue we = should stick with it to at least see it play out a bit more. E.g., once = MRHOF is actually a proposed standard and we have significant experience = using it. It's so critical in systems design to not waffle on design = decisions, otherwise you end up with a contradictory and messy system. = You do want to correct, but not lightly and only when the benefits of = the change significantly outweigh the costs. I'm not at all sure this is = the case here. Phil From prvs=4996a14c8=mukul@uwm.edu Thu Jun 7 21:09:40 2012 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 DD9AC11E8176 for ; Thu, 7 Jun 2012 21:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ON2hYvhW3Brz for ; Thu, 7 Jun 2012 21:09:39 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 06E9911E8175 for ; Thu, 7 Jun 2012 21:09:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAAx60U9/AAAB/2dsb2JhbABFDoVEsh8BAQEDAQEBASBLCwwPDgMEAQEBAgINGQIpKAgGE4d9AwYFC6ZLiHANSokABIEjiSJhhG6BEgOIQIxej3uCJ1c Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 60426E6A8D; Thu, 7 Jun 2012 23:09:36 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qxneUJtXsQLd; Thu, 7 Jun 2012 23:09:36 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id F0759E6A72; Thu, 7 Jun 2012 23:09:35 -0500 (CDT) Date: Thu, 7 Jun 2012 23:09:35 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <714073396.628993.1339128575855.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: Haberman Brian , Stiemerling Martin , roll , Michael Richardson Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 04:09:40 -0000 I agree with Philip. Thanks Mukul ----- Original Message ----- From: "Philip Levis" To: "Pascal Thubert (pthubert)" Cc: "Haberman Brian" , "roll" , "Stiemerling Martin" , "Michael Richardson" Sent: Thursday, June 7, 2012 11:02:23 PM Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec On Jun 7, 2012, at 2:49 PM, Pascal Thubert (pthubert) wrote: > > On Jun 6, 2012, at 10:43 AM 6/6/12, Philip Levis wrote: > >> Responses inline. >> >> On Jun 4, 2012, at 9:31 AM, Ralph Droms wrote: >> >>>> >>> >>> My question here is why a single objective function "MRHOF" is defined to use several different metrics. My understanding is that any specific RPL instance will use one metric as its "selected metric" for MRHOF. Another way to organize the objective functions would be to define a different OF number for each metric, binding the OF number to the selected metric. >> >> This was a design decision made early in RPL. There were two options: OFs are metric-specific, or OFs can be general with respect to metrics. The design team concluded the second approach was better, as the former would lead to a possibly huge number of OFs that would be hard to manage. > > Now that a real OF has actually been designed and specified, perhaps this would be a good time to reconfirm that design decision. > > Given that MRHOF is a pretty general objective function, and works over 5 (or perhaps 3) metrics, 16 bits would seem to provide plenty of code points for metric-specific OFs. > > A bigger issue, I think, is expressing the semantics or behavior of an OF in its OCP. I read section 18.6 of RFC 6550 to indicate that a node will use information including the OF (as indicated by the OCP) to compare against the node's policy for joining a DODAG. As an aside, is there a reason why a node would choose to join a specific DODAG within a RPL Instance and on what basis would it make that choice? Anyway, wouldn't the selected metric used by MRHOF in a particular RPL Instance be a useful parameter for the policy rules? For example, I can imagine a node preferring to join a RPL Instance providing minimal latency over one providing best ETX. If the OCP is metric-specific, that selected metric will be immediately available for the policy rules. > > > [Pascal] I agree with Ralph here. I fail to be convinced that there will an explosion of OCPs if we fail to factorize the metrics. But I see how the device implementation can be simplified if the OCP says it all. Also, we do not want to force a device that implements MRHOF to have to implement all metrics in the I-D. Conversely, say we extend MrHof to other metrics with further work, wouldn't it become OCP 2 anyway? I wouldn't mind blocking OCP 1..9 for current and future MrHof metric variations. I agree that this is a good question to ask. I disagree that now is an appropriate time to answer it definitively; we currently have only one OCP. We made a concrete and deliberate design decision. I'd argue we should stick with it to at least see it play out a bit more. E.g., once MRHOF is actually a proposed standard and we have significant experience using it. It's so critical in systems design to not waffle on design decisions, otherwise you end up with a contradictory and messy system. You do want to correct, but not lightly and only when the benefits of the change significantly outweigh the costs. I'm not at all sure this is the case here. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From rdroms.ietf@gmail.com Fri Jun 8 03:39:51 2012 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 DD79C21F850F for ; Fri, 8 Jun 2012 03:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PFAxyktti9Lg for ; Fri, 8 Jun 2012 03:39:51 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E1F1C21F8503 for ; Fri, 8 Jun 2012 03:39:50 -0700 (PDT) Received: by qcsq13 with SMTP id q13so925299qcs.31 for ; Fri, 08 Jun 2012 03:39:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=mi3qPyYrQtnUa+x859hkFNxRUsfxU1bbYkECtuPC38k=; b=qAMPvFH/m/uH77tvs3NCDfNX85coDMXc1kDSSCF8LZNQ6YzGJe0kGSbXeHvZFJ/jX/ g6Jbt7DmwDOw5zny2qTLzjxK+oX64v/mW64b2XAWgNjHwVLIMZG/AyTeQa6gV+P8Amg4 5PLUiX403Q+M8H3q6vVZQhKuy0A/o7llkaKTbk6XZ35ZoFk55pWZomxiOnbSPcgC8F1m CyIW/5ESMQTM2ZPZZb1E+rHoD4nWuIKdH739p5wEUoEbYunmN9XwNG/vBj3k5z2t0oVP DX4rjgBm4HFrmdKUx43FYnAdWhrwvx2caLtz9lh0WrDZj/eF48CV4twIaYDOt0PX4V9k E6SQ== Received: by 10.229.136.135 with SMTP id r7mr1675365qct.79.1339151990387; Fri, 08 Jun 2012 03:39:50 -0700 (PDT) Received: from [192.168.1.109] (c-50-133-157-96.hsd1.ct.comcast.net. [50.133.157.96]) by mx.google.com with ESMTPS id dx8sm10120293qab.8.2012.06.08.03.39.47 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 03:39:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> Date: Fri, 8 Jun 2012 06:39:46 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <72AFC659-4E19-4F51-AB2B-8FA943DB30AD@gmail.com> References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> To: Philip Levis X-Mailer: Apple Mail (2.1278) Cc: Stiemerling Martin , Michael Richardson , roll , Haberman Brian Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 10:39:52 -0000 On Jun 8, 2012, at 12:02 AM 6/8/12, Philip Levis wrote: >=20 > On Jun 7, 2012, at 2:49 PM, Pascal Thubert (pthubert) wrote: >=20 >>=20 >> On Jun 6, 2012, at 10:43 AM 6/6/12, Philip Levis wrote: >>=20 >>> Responses inline. >>>=20 >>> On Jun 4, 2012, at 9:31 AM, Ralph Droms wrote: >>>=20 >>>>>=20 >>>>=20 >>>> My question here is why a single objective function "MRHOF" is = defined to use several different metrics. My understanding is that any = specific RPL instance will use one metric as its "selected metric" for = MRHOF. Another way to organize the objective functions would be to = define a different OF number for each metric, binding the OF number to = the selected metric. >>>=20 >>> This was a design decision made early in RPL. There were two = options: OFs are metric-specific, or OFs can be general with respect to = metrics. The design team concluded the second approach was better, as = the former would lead to a possibly huge number of OFs that would be = hard to manage. >>=20 >> Now that a real OF has actually been designed and specified, perhaps = this would be a good time to reconfirm that design decision. >>=20 >> Given that MRHOF is a pretty general objective function, and works = over 5 (or perhaps 3) metrics, 16 bits would seem to provide plenty of = code points for metric-specific OFs. >>=20 >> A bigger issue, I think, is expressing the semantics or behavior of = an OF in its OCP. I read section 18.6 of RFC 6550 to indicate that a = node will use information including the OF (as indicated by the OCP) to = compare against the node's policy for joining a DODAG. As an aside, is = there a reason why a node would choose to join a specific DODAG within a = RPL Instance and on what basis would it make that choice? Anyway, = wouldn't the selected metric used by MRHOF in a particular RPL Instance = be a useful parameter for the policy rules? For example, I can imagine = a node preferring to join a RPL Instance providing minimal latency over = one providing best ETX. If the OCP is metric-specific, that selected = metric will be immediately available for the policy rules. >>=20 >>=20 >> [Pascal] I agree with Ralph here. I fail to be convinced that there = will an explosion of OCPs if we fail to factorize the metrics. But I see = how the device implementation can be simplified if the OCP says it all. = Also, we do not want to force a device that implements MRHOF to have to = implement all metrics in the I-D. Conversely, say we extend MrHof to = other metrics with further work, wouldn't it become OCP 2 anyway? I = wouldn't mind blocking OCP 1..9 for current and future MrHof metric = variations. >=20 >=20 > I agree that this is a good question to ask. I disagree that now is an = appropriate time to answer it definitively; we currently have only one = OCP. We made a concrete and deliberate design decision. I'd argue we = should stick with it to at least see it play out a bit more. E.g., once = MRHOF is actually a proposed standard and we have significant experience = using it. It's so critical in systems design to not waffle on design = decisions, otherwise you end up with a contradictory and messy system. = You do want to correct, but not lightly and only when the benefits of = the change significantly outweigh the costs. I'm not at all sure this is = the case here. What are the costs of the change? Without encoding the metric in the OCP, how does a node know what metric = is in use in an advertised RPL Instance. How does a node choose which = RPL Instance(s) to join without learning which metrics are in use? - Ralph >=20 > Phil >=20 From prvs=4996a14c8=mukul@uwm.edu Fri Jun 8 04:16:37 2012 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 098B421F884F for ; Fri, 8 Jun 2012 04:16:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.485 X-Spam-Level: X-Spam-Status: No, score=-6.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHWmLOe0-5XM for ; Fri, 8 Jun 2012 04:16:36 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 77C4821F8637 for ; Fri, 8 Jun 2012 04:16:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAOjd0U9/AAAB/2dsb2JhbABFhVKyGwEBAQMBAQEBIEoBCwUWDgwCDRkCKTAGE4gGBQumQIldiQAEgSOOcYESA4hAjF6Pe4J+ Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 0D16B2B3EF6; Fri, 8 Jun 2012 06:16:15 -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 h32ky8k8mntR; Fri, 8 Jun 2012 06:16:14 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 917352B3EF5; Fri, 8 Jun 2012 06:16:14 -0500 (CDT) Date: Fri, 8 Jun 2012 06:16:35 -0500 (CDT) From: Mukul Goyal To: Ralph Droms Message-ID: <1717970634.629420.1339154195384.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <72AFC659-4E19-4F51-AB2B-8FA943DB30AD@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll , Stiemerling Martin , Michael Richardson , Haberman Brian Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:16:37 -0000 >Without encoding the metric in the OCP, how does a node know what metric is in use in an advertised RPL Instance. The metrics inside the metric container inside the DIOs it receives from its candidate parents. Only the DAG root needs to be configured regarding merics in use. Other nodes would know the metrics in use by looking inside the metric container of the DIOs they receive. Mukul > How does a node choose which RPL Instance(s) to join without learning which metrics are in use? - Ralph > > Phil > _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From rdroms.ietf@gmail.com Fri Jun 8 04:19:01 2012 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 EABBB21F888A for ; Fri, 8 Jun 2012 04:19:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OvAOKdkfUwyo for ; Fri, 8 Jun 2012 04:19:01 -0700 (PDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 30AED21F8889 for ; Fri, 8 Jun 2012 04:19:01 -0700 (PDT) Received: by ggnc4 with SMTP id c4so1335642ggn.31 for ; Fri, 08 Jun 2012 04:19:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=PpVQANuD2RL+4kc/DWV1WmOlA0eBAqhdR6pYhlznZdw=; b=r8zuZRE/eAeIZCE04ifzI+ak6FQtyLGrOKOVPtaBhRihkDL4hVgWx0g+udyMDgGIF7 UfYzBrdaqC0KzyldNU92wqGWh4tqTSr1aIL3pJmbuZ5g9LyBWquWiuSRBhppBEwx8iiM AoxF4Oxxi60tt3PxiqQRDyCqqOD3TE412/tOqmOzboAbS14MKKxLKnSR11Jt7fTs+FDP YqywCGStYI34Or9nvkZtrdDMuZTCzep9MGQsMXdeQ/UFc2iCYt7o6OxgsXo6OAaEaMEi eyDNuwj9qWSnAbpY3Y/O/mYRchHc83QnO9iy5yTwSb+wWOh5y1c9Aa/o4JxmNSHbMXyB 2KbA== Received: by 10.236.192.169 with SMTP id i29mr6353039yhn.100.1339154340806; Fri, 08 Jun 2012 04:19:00 -0700 (PDT) Received: from ?IPv6:2001:420:2481:20:585:aa77:c1a2:a793? ([2001:420:2481:20:585:aa77:c1a2:a793]) by mx.google.com with ESMTPS id r45sm20318455yhg.18.2012.06.08.04.18.57 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 04:18:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <1717970634.629420.1339154195384.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Fri, 8 Jun 2012 07:18:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <60FC86B5-A51E-487E-A419-889F6AE34B51@gmail.com> References: <1717970634.629420.1339154195384.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1278) Cc: Haberman Brian , Stiemerling Martin , roll , Michael Richardson Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:19:02 -0000 On Jun 8, 2012, at 7:16 AM 6/8/12, Mukul Goyal wrote: >> Without encoding the metric in the OCP, how does a node know what = metric is in use in an advertised RPL Instance. >=20 > The metrics inside the metric container inside the DIOs it receives = from its candidate parents. Only the DAG root needs to be configured = regarding merics in use. Other nodes would know the metrics in use by = looking inside the metric container of the DIOs they receive. Is the receiving node supposed to infer that the selected metric for a = RPL Instance using MRHOF is the one metric container included in the DIO = (or, in the case of ETX, there is no metric container)? - Ralph >=20 > Mukul >=20 >=20 >> How does a node choose which RPL Instance(s) to join without learning = which metrics are in use? >=20 > - Ralph >=20 >>=20 >> Phil >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=4996a14c8=mukul@uwm.edu Fri Jun 8 04:22:41 2012 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 0CAB321F854D for ; Fri, 8 Jun 2012 04:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.49 X-Spam-Level: X-Spam-Status: No, score=-6.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIZ-DOoFnArM for ; Fri, 8 Jun 2012 04:22:40 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 3278921F88AF for ; Fri, 8 Jun 2012 04:22:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EACbg0U9/AAAB/2dsb2JhbABFhVKyGwEBAQMBAQEBIEoBCwwPDgMEAQEDAg0ZAiMGKAgGE4d9AwYFC6ZAiQYNSokABIEjiSJhhG6BEgOIQIxein6EfYJ+ Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 2FD372B3EF5; Fri, 8 Jun 2012 06:22:17 -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 lvmo4QJNTCT3; Fri, 8 Jun 2012 06:22:16 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id CA1C72B3EF6; Fri, 8 Jun 2012 06:22:16 -0500 (CDT) Date: Fri, 8 Jun 2012 06:22:37 -0500 (CDT) From: Mukul Goyal To: Ralph Droms Message-ID: <592959538.629424.1339154557575.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <60FC86B5-A51E-487E-A419-889F6AE34B51@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll , Stiemerling Martin , Michael Richardson , Haberman Brian Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:22:41 -0000 >Is the receiving node supposed to infer that the selected metric for a RPL Instance using MRHOF is the one metric container included in the DIO (or, in the case of ETX, there is no metric container)? In my opinion, yes. Mukul ----- Original Message ----- From: "Ralph Droms" To: "Mukul Goyal" Cc: "Ralph Droms" , "Stiemerling Martin" , "Michael Richardson" , "roll" , "Haberman Brian" , "Philip Levis" Sent: Friday, June 8, 2012 6:18:54 AM Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec On Jun 8, 2012, at 7:16 AM 6/8/12, Mukul Goyal wrote: >> Without encoding the metric in the OCP, how does a node know what metric is in use in an advertised RPL Instance. > > The metrics inside the metric container inside the DIOs it receives from its candidate parents. Only the DAG root needs to be configured regarding merics in use. Other nodes would know the metrics in use by looking inside the metric container of the DIOs they receive. Is the receiving node supposed to infer that the selected metric for a RPL Instance using MRHOF is the one metric container included in the DIO (or, in the case of ETX, there is no metric container)? - Ralph > > Mukul > > >> How does a node choose which RPL Instance(s) to join without learning which metrics are in use? > > - Ralph > >> >> Phil >> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From rdroms.ietf@gmail.com Fri Jun 8 04:24:43 2012 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 121D821F88C7 for ; Fri, 8 Jun 2012 04:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LVSkaOOX8eAU for ; Fri, 8 Jun 2012 04:24:42 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6A62021F88C5 for ; Fri, 8 Jun 2012 04:24:42 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1059025vbb.31 for ; Fri, 08 Jun 2012 04:24:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=viUt6d3UgLWy1Bcr4G4VlRHv2751lQf03tUO6HOuVZU=; b=bs7XOyXl7NHcGlwLgBhU5U1/8nnJY8lJnT9dJXp6OONZhAWpY8DrK6cyUnPAo5DlHq 4whb6GRDX+MQtG7XsZ4ZlZp99m9kYfuD3oIyKXAIASFC9F5/CZsc3miT8MZMsaMfO+xp 61WFq++lBxqA9v+yAulhNfnHpF0WoF6OqZNXiKjH46PFMJx/poh/6SIxrGqHIcHrYyRj tJ2ZodLM5J13TfJmJbNlvb3A2VF60uhZkus3B1Cp4dmH252O9lSI4bQZhJskn8vZX646 M2s8VB85jAucHpBE9BrHNO6yf6zE509s3qRRQytgZTh13Hn5x4eHonI4AiQ4BLqma9sf 4/UA== Received: by 10.52.97.230 with SMTP id ed6mr4905812vdb.65.1339154681710; Fri, 08 Jun 2012 04:24:41 -0700 (PDT) Received: from rtp-rdroms-8912.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id i10sm9220207vdw.21.2012.06.08.04.24.39 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 04:24:40 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <592959538.629424.1339154557575.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Fri, 8 Jun 2012 07:24:38 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1E2F4795-3DE4-4231-8CCC-38953DA203F7@gmail.com> References: <592959538.629424.1339154557575.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1278) Cc: Haberman Brian , Stiemerling Martin , roll , Michael Richardson Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:24:43 -0000 On Jun 8, 2012, at 7:22 AM 6/8/12, Mukul Goyal wrote: >> Is the receiving node supposed to infer that the selected metric for = a RPL Instance using MRHOF is the one metric container included in the = DIO (or, in the case of ETX, there is no metric container)? >=20 > In my opinion, yes. Where is that behavior explicitly described in the relevant = specifications? - Ralph >=20 > Mukul=20 >=20 > ----- Original Message ----- > From: "Ralph Droms" > To: "Mukul Goyal" > Cc: "Ralph Droms" , "Stiemerling Martin" = , "Michael Richardson" , = "roll" , "Haberman Brian" , = "Philip Levis" > Sent: Friday, June 8, 2012 6:18:54 AM > Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec >=20 >=20 > On Jun 8, 2012, at 7:16 AM 6/8/12, Mukul Goyal wrote: >=20 >>> Without encoding the metric in the OCP, how does a node know what = metric is in use in an advertised RPL Instance. >>=20 >> The metrics inside the metric container inside the DIOs it receives = from its candidate parents. Only the DAG root needs to be configured = regarding merics in use. Other nodes would know the metrics in use by = looking inside the metric container of the DIOs they receive. >=20 > Is the receiving node supposed to infer that the selected metric for a = RPL Instance using MRHOF is the one metric container included in the DIO = (or, in the case of ETX, there is no metric container)? >=20 > - Ralph >=20 >>=20 >> Mukul >>=20 >>=20 >>> How does a node choose which RPL Instance(s) to join without = learning which metrics are in use? >>=20 >> - Ralph >>=20 >>>=20 >>> Phil >>>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 From prvs=4996a14c8=mukul@uwm.edu Fri Jun 8 04:27:27 2012 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 8F81921F8786 for ; Fri, 8 Jun 2012 04:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.495 X-Spam-Level: X-Spam-Status: No, score=-6.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HVStjQBwa9Dn for ; Fri, 8 Jun 2012 04:27:27 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id EA09C21F86D0 for ; Fri, 8 Jun 2012 04:27:26 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAG3h0U9/AAAB/2dsb2JhbABFhVKyGwEBBAEjVhsODAINGQJZBogZBaZOiVqJBIEjjnGBEgOIQIxej3uCfg Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 95C781FD0C8; Fri, 8 Jun 2012 06:27:07 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wymV5EgECRuu; Fri, 8 Jun 2012 06:27:07 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 7037A1FD0C7; Fri, 8 Jun 2012 06:27:07 -0500 (CDT) Date: Fri, 8 Jun 2012 06:27:07 -0500 (CDT) From: Mukul Goyal To: Ralph Droms Message-ID: <1016954968.629428.1339154827389.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <1E2F4795-3DE4-4231-8CCC-38953DA203F7@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll , Stiemerling Martin , Michael Richardson , Haberman Brian Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 11:27:27 -0000 >>> Is the receiving node supposed to infer that the selected metric for a RPL Instance using MRHOF is the one metric container included in the DIO (or, in the case of ETX, there is no metric container)? >> >> In my opinion, yes. >Where is that behavior explicitly described in the relevant specifications? It is not. It should be. Mukul From rdroms.ietf@gmail.com Fri Jun 8 05:05:41 2012 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 3BDDA21F8786 for ; Fri, 8 Jun 2012 05:05:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fuB1Ib0ikmSu for ; Fri, 8 Jun 2012 05:05:40 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id A973121F8448 for ; Fri, 8 Jun 2012 05:05:14 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1020306vcq.31 for ; Fri, 08 Jun 2012 05:05:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=/P7pUlS1TGUwZbeQ/0hPDODJBNQ8Bbq9D8MY2aECgRk=; b=0ZQxepA0FFPgknLCnpep9LwsVBouMDlPhYXjWEIw+zIos6onpngVmrq8I8yhPHYEgD cO7PAU4fuwNcrTQPc9xhFr7bqFuHjl2y55vqlPrRt3f2f+RJZruXyw7PXoiGGpOBysNi Oq1SMzACi+QA1oDUAuSQvcyHJTpW0quBr0gWqY2sFkvmPA2fP+IeRtF/xxiJqpGJ7Ocv HUCMYJbDMOK9OyTzMVD7wqX9dw1yYqVZ978ZMVASDwIuMKLo5rIVsK5q5xsrvoOWpgKd JbG3cMzuucHaV9SMg5hsdSQn9G6T8+htUF75/gNXOnknQ2t107E403wF5pVPVFfGQE+Q 23fg== Received: by 10.52.30.110 with SMTP id r14mr5190310vdh.0.1339157114168; Fri, 08 Jun 2012 05:05:14 -0700 (PDT) Received: from rtp-rdroms-8912.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id by3sm9378193vdc.17.2012.06.08.05.05.11 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 05:05:12 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <1016954968.629428.1339154827389.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Fri, 8 Jun 2012 08:05:09 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8FBA7931-52C0-4E4A-9637-AE471FF8F157@gmail.com> References: <1016954968.629428.1339154827389.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1278) Cc: Haberman Brian , Stiemerling Martin , roll , Michael Richardson Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 12:05:41 -0000 On Jun 8, 2012, at 7:27 AM 6/8/12, Mukul Goyal wrote: >>>> Is the receiving node supposed to infer that the selected metric = for a RPL Instance using MRHOF is the one metric container included in = the DIO (or, in the case of ETX, there is no metric container)? >>>=20 >>> In my opinion, yes. >=20 >> Where is that behavior explicitly described in the relevant = specifications? >=20 > It is not. It should be. OK, having *some* way for a node to determine the selected metric for = MRHOF in an advertised RPL Instance tells me how MRHOF can provide the = necessary information for the policy decision in section 18.6 of RFC = 6550. I would encourage some more discussion about metric-encoded OCPs. Seems = to me the metric is of at least as much importance (more important, in = my opinion) in choosing a RPL Instance as the way in which the DODAG is = constructed based on that metric (i.e., the computation part of the OF). = If I were trying to get a packet from a node to the LBR, I'd be much = more interested in the ETX or the latency than whether the path is = computed with hysteresis. - Ralph >=20 > Mukul >=20 From mcr@sandelman.ca Fri Jun 8 07:11:33 2012 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 ECF8A21F8935 for ; Fri, 8 Jun 2012 07:11:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nIjo8uE-67pN for ; Fri, 8 Jun 2012 07:11:33 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 7B9D621F8934 for ; Fri, 8 Jun 2012 07:11:33 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id A4F778362 for ; Fri, 8 Jun 2012 10:09:19 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id EE2189823C; Fri, 8 Jun 2012 10:11:30 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E0A0B98147 for ; Fri, 8 Jun 2012 10:11:30 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 08 Jun 2012 10:11:30 -0400 Message-ID: <5395.1339164690@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 14:11:34 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Philip" =3D=3D Philip Levis writes: Philip> I agree that this is a good question to ask. I disagree that Philip> now is an appropriate time to answer it definitively; we Philip> currently have only one OCP. We made a concrete and Philip> deliberate design decision. I'd argue we should stick with Philip> it to at least see it play out a bit more. E.g., once MRHOF Philip> is actually a proposed standard and we have significant Philip> experience using it. It's so critical in systems design to I think what you are saying is that splitting MRHOF into multiple OCPs in the future would not be so difficult a thing to do. There is a coding simplicity in what we have now, and we should be conscious of the constraints of our devices. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT9IIEoqHRg3pndX9AQK0sgQAxg8MJmTflaZLAJWr1e2OFZuTynvP0wYL I6bHEHpPOQetb+aemNLKfdAfDlMHtpRKvXY22szLWymbqKlrL9FQ+HAWo/QX0D7h nAgW8bJOiTzsdj0Oxrp0rWCkqSqzrtmfyvpH4pwKxh2NuuxLpEXv4l7/rC1OxNW0 282OXap+CiA= =yoWP -----END PGP SIGNATURE----- --=-=-=-- From rdroms.ietf@gmail.com Fri Jun 8 09:31:25 2012 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 C537B21F87F8 for ; Fri, 8 Jun 2012 09:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fwChah+crmKh for ; Fri, 8 Jun 2012 09:31:25 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id DD6B721F87EF for ; Fri, 8 Jun 2012 09:31:24 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1325383vbb.31 for ; Fri, 08 Jun 2012 09:31:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=60nxQuXPd1QIicDZkkL/RW9KmAdHK4XEyr85llghUj4=; b=WBTW6nM21uIlM4Zdx6bdy67ATTf3B+uQgIVDlkqmLDnEHkD9uD0bozpfXf8LC7/L/o m7nbn+EQcdvXI0XplkaEsOELcAOXrg0HQyTXqFrRoIabTa3Hiskw4wRB4Uxz047HjISA kyMhuO3GCFuil2no+Aq4rN7dzbF41kw5+EGK+wAl/4rKSjkFcbH3cqWoNGzYP8UOrPAR IH0yuE830o9zERHqQt6uFJiMKXKQxuY0+ZaHJDRUwFat9fAhrqDKCKDXYRS8im8YVW4X SzFxGrg+gZd1djXXq2nuYxFPGfC1H4Eh9l1/EoM5Ze0QLH+iWPvlYmb3b4vzRSbOy0Zs 2gqw== Received: by 10.220.220.83 with SMTP id hx19mr6765875vcb.53.1339173084120; Fri, 08 Jun 2012 09:31:24 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id i19sm10445744vdt.18.2012.06.08.09.31.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 09:31:22 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: <5395.1339164690@marajade.sandelman.ca> Date: Fri, 8 Jun 2012 12:31:19 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5ABEAC00-EE4E-4B10-9127-8D8727135051@gmail.com> References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> <5395.1339164690@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1278) Cc: roll Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 16:31:25 -0000 On Jun 8, 2012, at 10:11 AM 6/8/12, Michael Richardson wrote: >=20 >>>>>> "Philip" =3D=3D Philip Levis writes: > Philip> I agree that this is a good question to ask. I disagree = that > Philip> now is an appropriate time to answer it definitively; we > Philip> currently have only one OCP. We made a concrete and > Philip> deliberate design decision. I'd argue we should stick with > Philip> it to at least see it play out a bit more. E.g., once MRHOF > Philip> is actually a proposed standard and we have significant > Philip> experience using it. It's so critical in systems design to >=20 > I think what you are saying is that splitting MRHOF into multiple OCPs > in the future would not be so difficult a thing to do. Yeah, but once the code is deployed, nobody is going to make changes. > There is a coding simplicity in what we have now, and we should be > conscious of the constraints of our devices. I'll push back a little - inferring the metric from the received DIO is = certainly no simpler than learning the metric directly from the OCP... - Ralph > --=20 > Michael Richardson , Sandelman Software Works=20= > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jreddy@ti.com Fri Jun 8 10:24:11 2012 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 7DA9321F88E4 for ; Fri, 8 Jun 2012 10:24:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rkiSabymsVJ0 for ; Fri, 8 Jun 2012 10:24:10 -0700 (PDT) Received: from bear.ext.ti.com (bear.ext.ti.com [192.94.94.41]) by ietfa.amsl.com (Postfix) with ESMTP id 95F2221F88C4 for ; Fri, 8 Jun 2012 10:24:10 -0700 (PDT) Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id q58HO9VG009044 for ; Fri, 8 Jun 2012 12:24:10 -0500 Received: from DLEE74.ent.ti.com (dlee74.ent.ti.com [157.170.170.8]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id q58HO9OY019503 for ; Fri, 8 Jun 2012 12:24:09 -0500 Received: from DLEE10.ent.ti.com ([fe80::843:a4aa:bf01:3f68]) by DLEE74.ent.ti.com ([fe80::a0f1:125b:e7e3:7ed8%18]) with mapi id 14.01.0323.003; Fri, 8 Jun 2012 12:24:09 -0500 From: "Reddy, Joseph" To: "roll@ietf.org" Thread-Topic: [Roll] MRHOF ETX Thread-Index: Ac1Fmg4SPQh/8rD8Q92yAuo1fIkMvw== Date: Fri, 8 Jun 2012 17:24:09 +0000 Message-ID: <2AA5AC69E924D149A8D63EB676AF87DB2CA3E30D@DLEE10.ent.ti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.170.170.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] MRHOF ETX X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 17:24:11 -0000 Hi Om, I don't think it is accurate to say (ETX*128) should be used everywhere. Th= e draft uses the term ETX with different meanings at different places in th= e spec.=20 Specifically, consider this situation: A node computes its "path cost for a neighbor" by adding that parent's adve= rtised Rank with the link ETX to that parent node.=20 The advertised Rank of the parent is a 16-bit value that has integer and fr= actional parts. The MinHopRankIncrease parameter determines the length of t= he Integer/Fraction parts.=20 Now when the draft says to add the Rank and link ETX parameters, clearly th= is cannot be a simple addition of the Rank with either ETX or (ETX*128). In= stead, the ETX value must be converted to the same Integer/Fraction represe= ntation as the Rank ( i.e., using MinHopRankIncrease ) before being added.= =20 =09 Do you agree ? -Regards, Joseph ------------------------------ Message: 6 Date: Thu, 7 Jun 2012 18:45:11 -0500 From: Omprakash Gnawali To: Dario Tedeschi Cc: ROLL WG Subject: Re: [Roll] MRHOF ETX Message-ID: Content-Type: text/plain; charset=3DISO-8859-1 On Thu, Jun 7, 2012 at 6:34 PM, Dario Tedeschi wrote: > Hi Philip > > When MRHOF refers to ETX, is it the ETX value as defined in RFC6551 (i.e. > ETX * 128) or some ETX value defined by implementation? > > Could this be made more clear in the spec, because we are currently=20 > having a discussion in ZigBee-IP as to what this value should be? ETX * 128 as in 6551. The suggested value for parent switch threshold with ETX is given in 6551 format in -10. But I just noticed that I forgot to convert it to 6551 format for max link and max path values. They should all be ETX * 128. - om_p ------------------------------ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll End of Roll Digest, Vol 53, Issue 16 ************************************ From pal@cs.stanford.edu Fri Jun 8 10:28:21 2012 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 7CA8221F8911 for ; Fri, 8 Jun 2012 10:28: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leRsvzdj4Hos for ; Fri, 8 Jun 2012 10:28:20 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id E598B21F88F9 for ; Fri, 8 Jun 2012 10:28:20 -0700 (PDT) Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[192.168.1.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Sd2yw-0007EA-Uv; Fri, 08 Jun 2012 10:28:19 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <5ABEAC00-EE4E-4B10-9127-8D8727135051@gmail.com> Date: Fri, 8 Jun 2012 10:28:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> <5395.1339164690@marajade.sandelman.ca> <5ABEAC00-EE4E-4B10-9127-8D8727135051@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 26b8f8cb9d50f38c95a96ded60a4c5d6 Cc: roll Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 17:28:21 -0000 On Jun 8, 2012, at 9:31 AM, Ralph Droms wrote: >=20 > On Jun 8, 2012, at 10:11 AM 6/8/12, Michael Richardson wrote: >=20 >>=20 >>>>>>> "Philip" =3D=3D Philip Levis writes: >> Philip> I agree that this is a good question to ask. I disagree = that >> Philip> now is an appropriate time to answer it definitively; we >> Philip> currently have only one OCP. We made a concrete and >> Philip> deliberate design decision. I'd argue we should stick with >> Philip> it to at least see it play out a bit more. E.g., once MRHOF >> Philip> is actually a proposed standard and we have significant >> Philip> experience using it. It's so critical in systems design to >>=20 >> I think what you are saying is that splitting MRHOF into multiple = OCPs >> in the future would not be so difficult a thing to do. >=20 > Yeah, but once the code is deployed, nobody is going to make changes. >=20 >> There is a coding simplicity in what we have now, and we should be >> conscious of the constraints of our devices. >=20 > I'll push back a little - inferring the metric from the received DIO = is certainly no simpler than learning the metric directly from the = OCP... Ralph, Let's separate two issues: 1) OCPs should not have metric flexibility 2) There should be multiple MRHOFs, for different metric combinations We decided against 1) in the design phase due to conversations JP had = with some RPL users. The argument was that there are situations where = you might want to dynamically shift the operation of the network. E.g., = you have an OF that optimizes for two metrics, primary and secondary. = You have a RPL network designed for monitoring physical security and = reporting potential intrusions. In the monitoring phase, energy is the = primary metric, with latency second. In the reporting/alert phase, = latency is the primary metric and energy is the secondary metric.=20 If we decide 1), then it's not possible to do the above approach unless = you include two separate OFs. Furthermore, let's say you want to just = use energy? Or just use latency? You lose flexibility. The point is that = this is a one way street. If you allow metric flexibility, then you can = define OFs that only support one metric. If you do not allow metric = flexibility, then you cannot define OFs that are flexible with respect = to metrics. With respect to 2), I'd love to hear from the folks implementing MRHOF = whether they think this is a good idea. Are there cases where the = flexibility is useful? ETX is stated as the least common denominator = through a SHOULD. My worry right now is that we're pursuing a = not-unreasonable-but-mostly-hypothetical concern. As I said before, = asking the question is great, but we don't want to reverse years of = agreed-upon-reasoning and tradeoff decisions without careful thought. Phil Phil From pal@cs.stanford.edu Fri Jun 8 10:36:11 2012 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 1479711E808C for ; Fri, 8 Jun 2012 10:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E94AFRYiySgD for ; Fri, 8 Jun 2012 10:36:10 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id 88FAF11E8086 for ; Fri, 8 Jun 2012 10:36:10 -0700 (PDT) Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[192.168.1.106]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Sd36X-000101-Ky; Fri, 08 Jun 2012 10:36:09 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CA3E30D@DLEE10.ent.ti.com> Date: Fri, 8 Jun 2012 10:36:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <589DA05F-520D-4684-A28A-15A7D9ECDAFA@cs.stanford.edu> References: <2AA5AC69E924D149A8D63EB676AF87DB2CA3E30D@DLEE10.ent.ti.com> To: "Reddy, Joseph" X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 2c238adc2661b13b123d68c6db09dced Cc: "roll@ietf.org" Subject: Re: [Roll] MRHOF ETX X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 17:36:11 -0000 On Jun 8, 2012, at 10:24 AM, Reddy, Joseph wrote: > The advertised Rank of the parent is a 16-bit value that has integer = and fractional parts. The MinHopRankIncrease parameter determines the = length of the Integer/Fraction parts.=20 I think you're misreading MRHOF, and misinterpreting MinHopRankIncrease. = The MRHOF draft tries to be very explicit about this. MRHOF with ETX = encodes the ETX in Rank, but MinHopRankIncrease can change the = computation. If MinHopRankIncrease is greater than 128, then Rank no = longer really encodes a fixed-point version of ETX, it encodes ETX plus = a per-hop penalty. > Now when the draft says to add the Rank and link ETX parameters, = clearly this cannot be a simple addition of the Rank with either ETX or = (ETX*128). Instead, the ETX value must be converted to the same = Integer/Fraction representation as the Rank ( i.e., using = MinHopRankIncrease ) Disagree -- the draft is pretty explicit on what you do, and it's not = this. Phil From jreddy@ti.com Fri Jun 8 11:11:13 2012 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 F1BB711E80AB for ; Fri, 8 Jun 2012 11:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tUtpJ3UDX-g3 for ; Fri, 8 Jun 2012 11:11:12 -0700 (PDT) Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB9111E8089 for ; Fri, 8 Jun 2012 11:11:12 -0700 (PDT) Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id q58IB4FQ030778; Fri, 8 Jun 2012 13:11:05 -0500 Received: from DLEE74.ent.ti.com (dlee74.ent.ti.com [157.170.170.8]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id q58IB4nA013241; Fri, 8 Jun 2012 13:11:04 -0500 Received: from DLEE10.ent.ti.com ([fe80::843:a4aa:bf01:3f68]) by DLEE74.ent.ti.com ([fe80::a0f1:125b:e7e3:7ed8%18]) with mapi id 14.01.0323.003; Fri, 8 Jun 2012 13:11:04 -0500 From: "Reddy, Joseph" To: Philip Levis Thread-Topic: [Roll] MRHOF ETX Thread-Index: Ac1Fmg4SPQh/8rD8Q92yAuo1fIkMvwALQtKAAAmbfcA= Date: Fri, 8 Jun 2012 18:11:04 +0000 Message-ID: <2AA5AC69E924D149A8D63EB676AF87DB2CA3E35E@DLEE10.ent.ti.com> References: <2AA5AC69E924D149A8D63EB676AF87DB2CA3E30D@DLEE10.ent.ti.com> <589DA05F-520D-4684-A28A-15A7D9ECDAFA@cs.stanford.edu> In-Reply-To: <589DA05F-520D-4684-A28A-15A7D9ECDAFA@cs.stanford.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.170.170.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] MRHOF ETX X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 18:11:13 -0000 Phil It doesn't seem right to me that the actual metric used varies based on set= ting of the MinHopRankIncrease parameter ( since that parameter is defined = outside of MrHof draft and its setting may be based on other considerations= ). The draft clearly states ( in section 3.3 ): "... a node MUST advertis= e an approximation of its ETX in its advertised Rank value....". This sente= nce should be modified if the intention is to encode an ETX + Hopcount-pena= lty depending on MinHopRankIncrease setting.=20 As an aside, is there a specific reason to use 128 as the factor for multip= lying ETX? Since the default value of MinHopRankIncrease is 256 in the RPL = spec, using ETX*256 as the encoding would allow the default usage to be ETX= without a hopcount penalty ( which is likely to be common usage ). -Joseph -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu]=20 Sent: Friday, June 08, 2012 10:36 AM To: Reddy, Joseph Cc: roll@ietf.org Subject: Re: [Roll] MRHOF ETX On Jun 8, 2012, at 10:24 AM, Reddy, Joseph wrote: > The advertised Rank of the parent is a 16-bit value that has integer and = fractional parts. The MinHopRankIncrease parameter determines the length of= the Integer/Fraction parts.=20 I think you're misreading MRHOF, and misinterpreting MinHopRankIncrease. Th= e MRHOF draft tries to be very explicit about this. MRHOF with ETX encodes = the ETX in Rank, but MinHopRankIncrease can change the computation. If MinH= opRankIncrease is greater than 128, then Rank no longer really encodes a fi= xed-point version of ETX, it encodes ETX plus a per-hop penalty. > Now when the draft says to add the Rank and link ETX parameters, clearly = this cannot be a simple addition of the Rank with either ETX or (ETX*128). = Instead, the ETX value must be converted to the same Integer/Fraction repre= sentation as the Rank ( i.e., using MinHopRankIncrease ) Disagree -- the draft is pretty explicit on what you do, and it's not this. Phil From mcr@sandelman.ca Fri Jun 8 12:14:05 2012 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 9C5D021F876F for ; Fri, 8 Jun 2012 12:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy3kOuDRmTLf for ; Fri, 8 Jun 2012 12:14:05 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4091B21F876A for ; Fri, 8 Jun 2012 12:14:03 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 6368E863D; Fri, 8 Jun 2012 15:11:49 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C6B3A9823C; Fri, 8 Jun 2012 15:14:01 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C33DD98147; Fri, 8 Jun 2012 15:14:01 -0400 (EDT) From: Michael Richardson To: Philip Levis In-Reply-To: References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> <5395.1339164690@marajade.sandelman.ca> <5ABEAC00-EE4E-4B10-9127-8D8727135051@gmail.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 08 Jun 2012 15:14:01 -0400 Message-ID: <9320.1339182841@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 19:14:05 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Philip" =3D=3D Philip Levis writes: Philip> We decided against 1) in the design phase due to Philip> conversations JP had with some RPL users. The argument was Philip> that there are situations where you might want to Philip> dynamically shift the operation of the network. E.g., you Philip> have an OF that optimizes for two metrics, primary and Philip> secondary. You have a RPL network designed for monitoring Philip> physical security and reporting potential intrusions. In the Philip> monitoring phase, energy is the primary metric, with latency Philip> second. In the reporting/alert phase, latency is the primary Philip> metric and energy is the secondary metric.=20=20 I agree with the scenario. How would an (already deployed) node know which metric it is supposed to start optimizing for? I believe that intermediate nodes need to make the same optimization as the node which has the event ("intrusion") which it wishes to report. (Maybe I'm wrong, cause my the parent selection code in my implementation currently says, "return 1;") =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT9JO+YqHRg3pndX9AQJO/AP/QrwuuncvK22iimGEnIO4eMfQ1W5yN0tl rb2cKkXpE3nwVPBxw0Za3DWU4Av2qefvLvfB9JVn63XCgOCbVFdQmEcV6x93FHMP FA1rVh6HkVXYQSXFfcqGVgu1kPcLqRGRs+XQOu1yjs1p72aq3TZ2hH7pPLgx+xY3 jjUvu4ZpsCI= =Tj5r -----END PGP SIGNATURE----- --=-=-=-- From pthubert@cisco.com Fri Jun 8 12:18:45 2012 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 D661311E8117 for ; Fri, 8 Jun 2012 12:18:45 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1W9Rj1XRZcJe for ; Fri, 8 Jun 2012 12:18:42 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6590E11E80CF for ; Fri, 8 Jun 2012 12:18:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1912; q=dns/txt; s=iport; t=1339183119; x=1340392719; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=61HoWW1gLmIY66gjENNTRS7e71i+x00Fe/iuqxUtJpI=; b=UisRLU6cgSO6c6QDPEAlhasUFV5ZCRyOlCGBQe8lDiDa+eqJP2XDpAI2 2eMH0/ez0G+M1EaM6dy2RQdkGQy3YLhsf0ffYgz28w1MYuiKFJp79YuU9 ABpJVkJ9mH80XTNcvMantZ1oQw5H2E64XckPHfi17U+gqLe8+hio7R6zi E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAHdP0k+tJXG//2dsb2JhbABFtFeBB4IYAQEBBBIBJ0sEAgEIEQQBAQsUCQcyFAkIAgQBEggah2kLmR6fZYsmBYUbYAOWMI0DgWaCYA X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="90631777" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-1.cisco.com with ESMTP; 08 Jun 2012 19:18:38 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id q58JIcmh022922 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Jun 2012 19:18:38 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.99]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0298.004; Fri, 8 Jun 2012 14:18:37 -0500 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "roll@ietf.org" Thread-Topic: [Roll] Ralph's DISCUSS on MRHOF spec Thread-Index: AQHNRSuKU3Zy3u1cZ0ORHM+g2HZO3Zbwyq0A//+/LcA= Date: Fri, 8 Jun 2012 19:18:37 +0000 Deferred-Delivery: Fri, 8 Jun 2012 19:18:00 +0000 Message-ID: References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> <5395.1339164690@marajade.sandelman.ca> In-Reply-To: <5395.1339164690@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.81.240] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18956.001 x-tm-as-result: No--35.917300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 19:18:46 -0000 Hi Michael: My understanding is that it is simpler to just check the OCP than first mat= ch the OCP in the config option and then go figure the metric in the metric= option. Not that it is a huge overhead but I fail to understand why you claim that = the single OCP is simpler. And no, I do not see that splitting in a future when implementations are al= ready shipping will be easy;=20 a mixed deployment would have to fall back to legacy from the root down, me= aning that it will hardly ever evolve.=20 LLN Devices that we install now some of the deployments (eg industrial) are= expected last for 20+ years with minimum (no) intervention on them but may= be battery changes. Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mic= hael Richardson Sent: vendredi 8 juin 2012 16:12 To: roll@ietf.org Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec >>>>> "Philip" =3D=3D Philip Levis writes: Philip> I agree that this is a good question to ask. I disagree that Philip> now is an appropriate time to answer it definitively; we Philip> currently have only one OCP. We made a concrete and Philip> deliberate design decision. I'd argue we should stick with Philip> it to at least see it play out a bit more. E.g., once MRHOF Philip> is actually a proposed standard and we have significant Philip> experience using it. It's so critical in systems design to I think what you are saying is that splitting MRHOF into multiple OCPs in t= he future would not be so difficult a thing to do. There is a coding simplicity in what we have now, and we should be consciou= s of the constraints of our devices. -- Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From pthubert@cisco.com Fri Jun 8 13:03:54 2012 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 57CEA11E8138 for ; Fri, 8 Jun 2012 13:03:54 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHiIv7B-JdZz for ; Fri, 8 Jun 2012 13:03:53 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C9F1611E80DC for ; Fri, 8 Jun 2012 13:03:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2490; q=dns/txt; s=iport; t=1339185804; x=1340395404; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/Q6u4RnngMm9Kwe+dHFf1hcA6DTuKbZMZJYTSq8y9xA=; b=PzoAnyKXy3OgTilzDU1LMoDfhaWgtcLLJ8tH5SIrAh4LmdDtCFitJYRB YqUcQkY0NVfvqQ87NUi1aWAv5MbyYeaChVgOTt94nZqQ0byJd1OPelfC/ fAjZ48B2C3zjRGDUSwb7I9L5T5Y1LnHdaWntaPrNGpkcRDcAS/Hu8SQwR g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFpa0k+tJV2b/2dsb2JhbABFDrRJgQeCGQEBBAEBAQ8BJzQLEAIBCA4UFBAnCyUCBAENBQgah2kLmRefXgSLK4UbYAOjM4Fmgic5 X-IronPort-AV: E=Sophos;i="4.75,738,1330905600"; d="scan'208";a="90847039" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP; 08 Jun 2012 20:03:23 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q58K3Njc032456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 8 Jun 2012 20:03:23 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.99]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0298.004; Fri, 8 Jun 2012 15:03:23 -0500 From: "Pascal Thubert (pthubert)" To: Philip Levis , Ralph Droms Thread-Topic: [Roll] Ralph's DISCUSS on MRHOF spec Thread-Index: AQHNRZwXU3Zy3u1cZ0ORHM+g2HZO3Zbw1ouA Date: Fri, 8 Jun 2012 20:03:22 +0000 Deferred-Delivery: Fri, 8 Jun 2012 20:03:00 +0000 Message-ID: References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> <5395.1339164690@marajade.sandelman.ca> <5ABEAC00-EE4E-4B10-9127-8D8727135051@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.81.240] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18956.001 x-tm-as-result: No--40.164800-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: roll Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 20:03:54 -0000 Hi Phil Let's separate two issues: 1) OCPs should not have metric flexibility 2) There should be multiple MRHOFs, for different metric combinations We decided against 1) in the design phase due to conversations JP had with = some RPL users. The argument was that there are situations where you might = want to dynamically shift the operation of the network. E.g., you have an O= F that optimizes for two metrics, primary and secondary. You have a RPL net= work designed for monitoring physical security and reporting potential intr= usions. In the monitoring phase, energy is the primary metric, with latency= second. In the reporting/alert phase, latency is the primary metric and en= ergy is the secondary metric.=20 If we decide 1), then it's not possible to do the above approach unless you= include two separate OFs. Furthermore, let's say you want to just use ener= gy? Or just use latency? You lose flexibility. The point is that this is a = one way street. If you allow metric flexibility, then you can define OFs th= at only support one metric. If you do not allow metric flexibility, then yo= u cannot define OFs that are flexible with respect to metrics. [Pascal] If there is a well-defined logic in an OF that plays with coeffici= ents to ponder latency and battery, then we have a single OCP that represen= ts that logic. Overtime, the coefficients might evolve so that a battery-de= pleted devices gets less packets though. I'm perfectly fine with that. But = note that from the start the OF supports both metrics, even if at a given p= oint of time the coefficient can be 0 for one of those. With respect to 2), I'd love to hear from the folks implementing MRHOF whet= her they think this is a good idea. Are there cases where the flexibility i= s useful? ETX is stated as the least common denominator through a SHOULD. M= y worry right now is that we're pursuing a not-unreasonable-but-mostly-hypo= thetical concern. As I said before, asking the question is great, but we do= n't want to reverse years of agreed-upon-reasoning and tradeoff decisions w= ithout careful thought. [Pascal] Agreed with the mostly hypothetical. Is anyone using another metri= c than ETX? But " years of agreed-upon-reasoning and tradeoff decisions" mi= ght be slightly exaggerated... Cheers, Pascal Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From rdroms.ietf@gmail.com Fri Jun 8 13:08:40 2012 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 6A2A911E8138 for ; Fri, 8 Jun 2012 13:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AhmVHdjmwV75 for ; Fri, 8 Jun 2012 13:08:39 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0DFD611E812C for ; Fri, 8 Jun 2012 13:08:17 -0700 (PDT) Received: by vcqp1 with SMTP id p1so1415693vcq.31 for ; Fri, 08 Jun 2012 13:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=M8rgKVFMYNDGEfYS4AVumsP9GHmF23AHFkS4D4l64KI=; b=m/xHbJfU8xniDmKvllDS4ji8T3fOLwF0SxLfa4JmdeMGYUoEDvp2FHmsRQZwuBwhvX +UtaBLyQzAa7xhnXB2EyyT7//RhI5kbnIhl1LhHHkYFcHio5MUTJNWg5k8mkBHwzJWw6 L08V6HtYHPLSwKnQA8vRgOMFX4b5e/WV+wE1PGfgfDaEWaUdUqsfUp5J09Dvkw9pwXV9 BoDlPo0QwX4I825/DjMDDr4DiYa4HMgWWNk8NgGTqvdNnKwpBZkNjcUctwS17PQUa45o pjIs0Ri6jStP8yTW0Xgoflzw4ZwqHfodN0DLEZiLtMPQlooPUEm8NX0MhVZrPoZ5nU9x RFfg== Received: by 10.220.39.206 with SMTP id h14mr7310668vce.63.1339186097191; Fri, 08 Jun 2012 13:08:17 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id ek5sm11329265vdb.5.2012.06.08.13.08.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 13:08:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Fri, 8 Jun 2012 16:08:12 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <058F9835-D819-49CB-B704-2BB9D1EB8902@gmail.com> References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> <5395.1339164690@marajade.sandelman.ca> <5ABEAC00-EE4E-4B10-9127-8D8727135051@gmail.com> To: Philip Levis X-Mailer: Apple Mail (2.1278) Cc: roll Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 20:08:40 -0000 On Jun 8, 2012, at 1:28 PM 6/8/12, Philip Levis wrote: >=20 > On Jun 8, 2012, at 9:31 AM, Ralph Droms wrote: >=20 >>=20 >> On Jun 8, 2012, at 10:11 AM 6/8/12, Michael Richardson wrote: >>=20 >>>=20 >>>>>>>> "Philip" =3D=3D Philip Levis writes: >>> Philip> I agree that this is a good question to ask. I disagree = that >>> Philip> now is an appropriate time to answer it definitively; we >>> Philip> currently have only one OCP. We made a concrete and >>> Philip> deliberate design decision. I'd argue we should stick with >>> Philip> it to at least see it play out a bit more. E.g., once MRHOF >>> Philip> is actually a proposed standard and we have significant >>> Philip> experience using it. It's so critical in systems design to >>>=20 >>> I think what you are saying is that splitting MRHOF into multiple = OCPs >>> in the future would not be so difficult a thing to do. >>=20 >> Yeah, but once the code is deployed, nobody is going to make changes. >>=20 >>> There is a coding simplicity in what we have now, and we should be >>> conscious of the constraints of our devices. >>=20 >> I'll push back a little - inferring the metric from the received DIO = is certainly no simpler than learning the metric directly from the = OCP... >=20 >=20 > Ralph, >=20 > Let's separate two issues: >=20 > 1) OCPs should not have metric flexibility > 2) There should be multiple MRHOFs, for different metric combinations >=20 > We decided against 1) in the design phase due to conversations JP had = with some RPL users. The argument was that there are situations where = you might want to dynamically shift the operation of the network. E.g., = you have an OF that optimizes for two metrics, primary and secondary. = You have a RPL network designed for monitoring physical security and = reporting potential intrusions. In the monitoring phase, energy is the = primary metric, with latency second. In the reporting/alert phase, = latency is the primary metric and energy is the secondary metric.=20 >=20 > If we decide 1), then it's not possible to do the above approach = unless you include two separate OFs. Furthermore, let's say you want to = just use energy? Or just use latency? You lose flexibility. The point is = that this is a one way street. If you allow metric flexibility, then you = can define OFs that only support one metric. If you do not allow metric = flexibility, then you cannot define OFs that are flexible with respect = to metrics. I have to say this is the first I've heard, based on the specs I've = reviewed to date, of an OF that would dynamically change its behavior.=20= Why wouldn't RPL Instances - one optimized for low latency and one = optimized for low energy - be an acceptable and simpler solution? How = would the metric be changed atomically? How would nodes be notified = that the metric had changed? Metric flexibility seems like a hypothetical that needs more thought and = additional mechanism in RPL to become real. In any event, I'll clarify = that I wasn't thinking that every the OCP for every OF encode the metric = for that OF. It seemed, in the case of MRHOF, that a separate OCP for = each metric might solve the problem of indicating the selected metric to = a receiving node. > With respect to 2), I'd love to hear from the folks implementing MRHOF = whether they think this is a good idea. Are there cases where the = flexibility is useful? ETX is stated as the least common denominator = through a SHOULD. My worry right now is that we're pursuing a = not-unreasonable-but-mostly-hypothetical concern. As I said before, = asking the question is great, but we don't want to reverse years of = agreed-upon-reasoning and tradeoff decisions without careful thought. We may not be talking about the same issue, as I don't quite understand = your question about flexibility. Can you say more about it? Do we agree that the selected metric for a RPL Instance using MRHOF = needs to be indicated to the receiving node for the node to make a = policy decision about whether to join the RPL Instance? - Ralph =20 > Phil >=20 >=20 >=20 > Phil >=20 From rdroms.ietf@gmail.com Fri Jun 8 13:10:04 2012 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 3478E21F84E1 for ; Fri, 8 Jun 2012 13:10:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lESd0l0Zw4yC for ; Fri, 8 Jun 2012 13:10:03 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6CA4F21F84DE for ; Fri, 8 Jun 2012 13:10:03 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1488229vbb.31 for ; Fri, 08 Jun 2012 13:10:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=2c2QgLY/XYLePjSCbwlQZLTxaZ0zBtIcrRZodBBnv0Y=; b=uzdZvAad08mMpOUJqqtOXAV/UGQ+Py03uuYX0CGmGi54wOh4Twny6XH/3WkRo8aMHm xWqZkQFAcedDYsYWAHXr+5CExza4gmnSQFz9ncF8nUoq1X380de7vwWHPn/fE0Rhf29b FA1iYF7DH2bDZi5Bj78e8NdqzJfEzgBHgdet4V1XQdsq5V8W3tK0Sckan3bubtG/zMxw +vtgcdEo79glHBGPK+XU+u+Xz9075ru2WMBRBz/Y5iLP8Dpx5wIYjrSfGjQkq//8dXP9 h2lXjfGTFzyPXW1meqzRtTHadWIetzE9Cnft10llEFy/tNNgIMXQ2anQLzqQjGRzT1qx YABQ== Received: by 10.52.36.116 with SMTP id p20mr6542934vdj.129.1339186202681; Fri, 08 Jun 2012 13:10:02 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id g10sm11339864vdk.2.2012.06.08.13.10.00 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 08 Jun 2012 13:10:01 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Fri, 8 Jun 2012 16:09:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <3EC8A988-B942-49AD-8A07-F12EC13A6DC0@gmail.com> References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> <5395.1339164690@marajade.sandelman.ca> <5ABEAC00-EE4E-4B10-9127-8D8727135051@gmail.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1278) Cc: roll Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 20:10:04 -0000 On Jun 8, 2012, at 4:03 PM 6/8/12, Pascal Thubert (pthubert) wrote: > Hi Phil >=20 > Let's separate two issues: >=20 > 1) OCPs should not have metric flexibility > 2) There should be multiple MRHOFs, for different metric combinations >=20 > We decided against 1) in the design phase due to conversations JP had = with some RPL users. The argument was that there are situations where = you might want to dynamically shift the operation of the network. E.g., = you have an OF that optimizes for two metrics, primary and secondary. = You have a RPL network designed for monitoring physical security and = reporting potential intrusions. In the monitoring phase, energy is the = primary metric, with latency second. In the reporting/alert phase, = latency is the primary metric and energy is the secondary metric.=20 >=20 > If we decide 1), then it's not possible to do the above approach = unless you include two separate OFs. Furthermore, let's say you want to = just use energy? Or just use latency? You lose flexibility. The point is = that this is a one way street. If you allow metric flexibility, then you = can define OFs that only support one metric. If you do not allow metric = flexibility, then you cannot define OFs that are flexible with respect = to metrics. >=20 > [Pascal] If there is a well-defined logic in an OF that plays with = coefficients to ponder latency and battery, then we have a single OCP = that represents that logic. Overtime, the coefficients might evolve so = that a battery-depleted devices gets less packets though. I'm perfectly = fine with that. But note that from the start the OF supports both = metrics, even if at a given point of time the coefficient can be 0 for = one of those. Agreed - not every OF has to encode its single metric in its OCP. But = for some OFs, like MRHOF, it might make sense. > With respect to 2), I'd love to hear from the folks implementing MRHOF = whether they think this is a good idea. Are there cases where the = flexibility is useful? ETX is stated as the least common denominator = through a SHOULD. My worry right now is that we're pursuing a = not-unreasonable-but-mostly-hypothetical concern. As I said before, = asking the question is great, but we don't want to reverse years of = agreed-upon-reasoning and tradeoff decisions without careful thought. >=20 > [Pascal] Agreed with the mostly hypothetical. Is anyone using another = metric than ETX? But " years of agreed-upon-reasoning and tradeoff = decisions" might be slightly exaggerated... I'm still confused about what is hypothetical. MRHOF is defined for 5 = possible metrics (or maybe 3). Is it the case that only ETX is really = going to be used? - Ralph >=20 > Cheers, >=20 > Pascal >=20 >=20 >=20 > Phil >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Fri Jun 8 15:35:32 2012 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 C6D3A11E8154 for ; Fri, 8 Jun 2012 15:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DCuxqaOlEpOX for ; Fri, 8 Jun 2012 15:35:32 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id 49B1E11E8091 for ; Fri, 8 Jun 2012 15:35:32 -0700 (PDT) Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[192.168.1.108]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Sd7mE-00068P-C9; Fri, 08 Jun 2012 15:35:30 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Fri, 8 Jun 2012 15:35:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 5d20a7956aeeabba2813f93fa960b57d Cc: Haberman Brian , roll , Stiemerling Martin , Michael Richardson Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 22:35:32 -0000 On Jun 7, 2012, at 2:49 PM, Pascal Thubert (pthubert) wrote: >=20 > [Pascal] I agree with Ralph here. I fail to be convinced that there = will an explosion of OCPs if we fail to factorize the metrics. But I see = how the device implementation can be simplified if the OCP says it all. = Also, we do not want to force a device that implements MRHOF to have to = implement all metrics in the I-D. Conversely, say we extend MrHof to = other metrics with further work, wouldn't it become OCP 2 anyway? I = wouldn't mind blocking OCP 1..9 for current and future MrHof metric = variations. Well, here was your argument for it: Begin forwarded message: > From: "Pascal Thubert (pthubert)" > Subject: RE: rank and metric in DIOs > Date: November 6, 2009 12:52:54 AM PST > To: "Jonathan Hui" , "Richard Kelsey" = > Cc: >=20 > Hi Jonathan: >=20 > I do not think we need to enforce anything. The gear box protects the > future. I think we must leave the core spec abstract on that. And = since > the burden is on the OCP anyway, what's the point? >=20 > OTOH, we can design an OCP / metric where the metric has the = properties > that is proposed here. In that case, the OCP should be simpler. OCP = zero > is a bit like that if you look at it :) Maybe our disagreement is only > what is in the base spec (the generic thing) and what goes in a = specific > instantiation (the OCP). >=20 > I can wholeheartedly accept Richard's way of start simple and solid, = and > then build over it if that's how more people can catch up with our = work > for both understanding and implementation. As a next step for an = OCP>0, > it is certainly a good thing to do. I'd support that, even more gladly > if we base it on ETX.=20 >=20 > Personally I think that this proposal yields limitations that will = soon > appear inacceptable for a number of use cases where you have more > metrics, not necessarily incremental, fast varying, and logic to wrap > that up. So we MUST NOT make it generic. Some of those metrics you = need > to propagate, but you do not want to change the rank and restart > trickle. >=20 > I listed the properties of the rank several times already. Its = stability > (long time constant is only one of those properties).=20 >=20 > A list (probably incomplete) of the differences: >=20 > - its type: it is a scalar > - its function: it is a relative coordinate, not a cost or a distance = to > root. > - its granularity: it is coarse grained to enable siblings > - its range with a short infinite > - its properties: rank is strictly monotonic, and increments from = parent > rank + OCP stuff, not like the metrics themselves increment or > propagate. How would you play with throughput or jitter? > - universal and very abstract: we can always default to OCP0. I have > uses cases where I could actually do that successfully, like cars in a > parking lot. >=20 > I think that the OCP job to turn its knowledge of the requirements, = the > environment and the ranks of parents into a rank cannot be = generalized. > Leaving that operation out of RPL base spec is actually making it > simpler. >=20 > I'd be glad to add some words in RPL base spec on those rank = properties > though... Phil From pal@cs.stanford.edu Fri Jun 8 15:45:50 2012 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 5F81321F86B4 for ; Fri, 8 Jun 2012 15:45:50 -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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Om02d+6+eSmY for ; Fri, 8 Jun 2012 15:45:49 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1EB21F86B0 for ; Fri, 8 Jun 2012 15:45:48 -0700 (PDT) Received: from 23-24-194-1-static.hfc.comcastbusiness.net ([23.24.194.1] helo=[192.168.1.111]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1Sd7wB-0002UM-ME; Fri, 08 Jun 2012 15:45:47 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Fri, 8 Jun 2012 15:42:51 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <506EFF09-1EAD-40F4-8E86-AB3F4725159B@cs.stanford.edu> References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> <5395.1339164690@marajade.sandelman.ca> <5ABEAC00-EE4E-4B10-9127-8D8727135051@gmail.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 3acef658708772c1d00935e7d4d752c5 Cc: roll Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jun 2012 22:45:50 -0000 Response inline. On Jun 8, 2012, at 1:03 PM, Pascal Thubert (pthubert) wrote: >=20 > With respect to 2), I'd love to hear from the folks implementing MRHOF = whether they think this is a good idea. Are there cases where the = flexibility is useful? ETX is stated as the least common denominator = through a SHOULD. My worry right now is that we're pursuing a = not-unreasonable-but-mostly-hypothetical concern. As I said before, = asking the question is great, but we don't want to reverse years of = agreed-upon-reasoning and tradeoff decisions without careful thought. >=20 > [Pascal] Agreed with the mostly hypothetical. Is anyone using another = metric than ETX? But " years of agreed-upon-reasoning and tradeoff = decisions" might be slightly exaggerated... >=20 > Cheers, >=20 > Pascal What I meant here is that the rest of the protocol has been designed = assuming this is the case. There are other things we might have done = were there a strong binding between the two. For example, if an OCP = defines the metric container and there isn't flexibility, there would be = little need for a general metric container object: an OF could define = it.=20 I'll repeat what I said before: we should ask this question, but should = not answer it definitively now. Making a significant change right now = based on concerns -- which haven't been voiced by any implementers -- = seems like a dangerous road to tread. I mean, come on, let's evaluate = the design and evolve it from practice, not from the sofa. Phil From jpv@cisco.com Sat Jun 9 01:21:42 2012 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 4C77421F89E6 for ; Sat, 9 Jun 2012 01:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.419 X-Spam-Level: X-Spam-Status: No, score=-110.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EeSZhJ23YqBE for ; Sat, 9 Jun 2012 01:21:41 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9821521F89E2 for ; Sat, 9 Jun 2012 01:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=2349; q=dns/txt; s=iport; t=1339230101; x=1340439701; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=mle4EgDfd0uVsPudXFaBXY27+AOfwr7AhrNNBDIMj+0=; b=FcuF+Xxv821nLw2vyHVQbUlzJcvfYfVEqlEDSfzp/HMwb9x3fmXa83/2 MFSj4jAVMAELS0O7zQeEO5VHuBxXWS/FhAbCZI0xuKcAUxmRbe8claIzW q9gQOb85tnXRdstmxrpPf0vPWkWjFuoVf8W6OJguzvFr0URN/vivgBdUt 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EACoG00+rRDoH/2dsb2JhbABFtFmBB4IZAQEEAQEBDwFbCxALBAEJOCcwBhMih2gBC5hxn1UEkDBgA5UehVOIQoFmgmI X-IronPort-AV: E=Sophos;i="4.75,741,1330905600"; d="scan'208,217";a="45717909" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 09 Jun 2012 08:21:41 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q598LewN017951; Sat, 9 Jun 2012 08:21:41 GMT Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 9 Jun 2012 16:21:39 +0800 Received: from [10.60.114.229] ([10.60.114.229]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 9 Jun 2012 16:21:39 +0800 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_67BAA7F7-B4B9-44BF-8710-BA95FE0F06A2" From: JP Vasseur In-Reply-To: <058F9835-D819-49CB-B704-2BB9D1EB8902@gmail.com> Date: Sat, 9 Jun 2012 10:21:37 +0200 Message-Id: <3240AE5F-61EA-4634-B1B5-ABDB4E0E9CB8@cisco.com> References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> <5395.1339164690@marajade.sandelman.ca> <5ABEAC00-EE4E-4B10-9127-8D8727135051@gmail.com> <058F9835-D819-49CB-B704-2BB9D1EB8902@gmail.com> To: Ralph Droms X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 09 Jun 2012 08:21:39.0695 (UTC) FILETIME=[E4E477F0:01CD4618] Cc: roll Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec 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, 09 Jun 2012 08:21:42 -0000 --Apple-Mail=_67BAA7F7-B4B9-44BF-8710-BA95FE0F06A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii [snip] >>=20 >>=20 >=20 > We may not be talking about the same issue, as I don't quite = understand your question about flexibility. Can you say more about it? >=20 > Do we agree that the selected metric for a RPL Instance using MRHOF = needs to be indicated to the receiving node for the node to make a = policy decision about whether to join the RPL Instance? >=20 JP> Absolutely ! Thanks. JP. > - Ralph >=20 >=20 >> Phil >>=20 >>=20 >>=20 >> Phil >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_67BAA7F7-B4B9-44BF-8710-BA95FE0F06A2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii



We may not be talking = about the same issue, as I don't quite understand your question about = flexibility.  Can you say more about it?

Do we agree that = the selected metric for a RPL Instance using MRHOF needs to be indicated = to the receiving node for the node to make a policy decision about = whether to join the RPL = Instance?


JP> = Absolutely = !

Thanks.

JP.

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


Phil



Phil


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

= --Apple-Mail=_67BAA7F7-B4B9-44BF-8710-BA95FE0F06A2-- From mcr@sandelman.ca Sun Jun 10 16:49:18 2012 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 9AE2221F84FE for ; Sun, 10 Jun 2012 16:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.646 X-Spam-Level: X-Spam-Status: No, score=0.646 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2ikROS8TSDu for ; Sun, 10 Jun 2012 16:49:18 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 114F321F84FD for ; Sun, 10 Jun 2012 16:49:17 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id E1FAF836F for ; Sun, 10 Jun 2012 19:46:58 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 66D109823C; Sun, 10 Jun 2012 19:49:16 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 55BD898239 for ; Sun, 10 Jun 2012 19:49:16 -0400 (EDT) From: Michael Richardson To: "roll@ietf.org" In-Reply-To: References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <4FFC4E5C-03CA-43D3-9220-DABDD52102FB@cs.stanford.edu> <5395.1339164690@marajade.sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 10 Jun 2012 19:49:16 -0400 Message-ID: <14770.1339372156@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec 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, 10 Jun 2012 23:49:18 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Pascal" =3D=3D Pascal Thubert <(pthubert)" > wri= tes: Pascal> My understanding is that it is simpler to just check the OCP Pascal> than first match the OCP in the config option and then go Pascal> figure the metric in the metric option.=20 I don't understand. Pascal> Not that it is a huge overhead but I fail to understand why Pascal> you claim that the single OCP is simpler.=20 I don't claim it, I'm trying to understand what you are saying. Pascal> And no, I do not see that splitting in a future when Pascal> implementations are already shipping will be easy;=20=20 okay. Pascal> a mixed deployment would have to fall back to legacy from Pascal> the root down, meaning that it will hardly ever evolve.=20=20 Pascal> LLN Devices that we install now some of the deployments (eg Pascal> industrial) are expected last for 20+ years with minimum Pascal> (no) intervention on them but maybe battery changes.=20 I don't expect any deployed device to change. They won't change for a new OF or OCP, etc.=20 What would happen is that new deployments might use it. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT9UyfIqHRg3pndX9AQL/UwP/VnY+mIWj27QYxlFsNt08+wdiRha7Eatv TaZ8ops1p/VsWFSMwlEp98XUXS2nlZPbdnyVi0QSD5cIhEk8+d1HS/GEnxCysbfF 78R79Q8m2ceIbIcPUsckRZIqFaar+O7byS9/+r6t9vjER1v9GA5/xNt7n1s587h9 cjNofsNeyTM= =QhDr -----END PGP SIGNATURE----- --=-=-=-- From adrian@olddog.co.uk Mon Jun 11 05:18:30 2012 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 1363C21F853B for ; Mon, 11 Jun 2012 05:18:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.555 X-Spam-Level: X-Spam-Status: No, score=-0.555 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SiyvN1VBKHkM for ; Mon, 11 Jun 2012 05:18:29 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id D339221F84FF for ; Mon, 11 Jun 2012 05:18:20 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q5BCIH9E016031; Mon, 11 Jun 2012 13:18:17 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q5BCIFqF015958 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 11 Jun 2012 13:18:15 +0100 From: "Adrian Farrel" To: "'Don Sturek'" Date: Mon, 11 Jun 2012 13:18:14 +0100 Message-ID: <024401cd47cc$47254de0$d56fe9a0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac1HzEPERDiq2jmTSrCQI3TZNS1kxQ== Content-Language: en-gb Cc: roll@ietf.org Subject: [Roll] IANA registry for OFs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 12:18:30 -0000 Hi, If I understood this part of the thread correctly, you are suggesting revising the current registry (http://www.iana.org/assignments/rpl/rpl.xml#ocp) that is set up as a single range 0-65535 with "IETF review" allocation policy. According to RFC 5226 that means "New values are assigned only through RFCs that have been shepherded through the IESG as AD-Sponsored or IETF WG Documents" It seems to me that this is adequate for immediate needs, but you might be asking to relax this and partition the range for future use. You could consider a range of first come first served code points, or a range (possibly just one). Making any change to the registry would require a standards track RFC, and I would suggest that, if this is what you want to achieve, you should start such a document and equip it with some description of the reasoning/use-cases that motivate you. It need not be a long document. Cheers, Adrian > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Don > Sturek > Sent: 04 June 2012 14:21 > To: Pascal Thubert (pthubert); Ralph Droms; Michael Richardson > Cc: roll@ietf.org > Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related > questions > > Hi Pascal, > > Having a range of reserved well known OF's from IANA makes sense. This > is the minimum requirement to make MrHOF work. > > If we do intend to support flexibility in deployment (eg industry groups > which may define their own OF's) then we would want a way to define on > demand OF's. > > Don > > > > On 6/3/12 11:38 PM, "Pascal Thubert (pthubert)" wrote: > > >Hi: > > > >I agree with Ralph that there is a choice to be made whether this OF is > >one OF or a generic OF that is instantiated by metric (a toolbox). > > > >If it is a specific OF, it is fair to require from IANA a specific OF > >number (1 in the IANA section) but then we can expect that all > >implementations of this OF will behave the same. > > > >Here, the behavior will vary quite dramatically with some implementation > >decisions (see the unresolved issue in the attached mail) and metric > >choices (Ralph's point here). > > > >As it goes, we could figure that MrHof is not one but many OFs. If > >that's so then the OF number for the local variation should be assigned > >consistently for a deployment as opposed to globally significant. There > >could in fact be multiple MrHof in a same deployment. > > > >My point is somewhat analogous to the UDP ports. Should we have a range > >for IANA reserved well known OFs, and then a range that would be assigned > >on demand? > > > >Cheers, > > > >Pascal > > > >-----Original Message----- > >From: Ralph Droms [mailto:rdroms.ietf@gmail.com] > >Sent: vendredi 1 juin 2012 21:47 > >To: Michael Richardson > >Cc: roll@ietf.org; Pascal Thubert (pthubert) > >Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related > >questions > > > > > >On May 25, 2012, at 12:31 PM 5/25/12, Pascal Thubert (pthubert) wrote: > > > >> Hi Michael: > >> > >> I think RPL does not want to take party there. The OF is a piece of > >>logic to tie metrics and policies together. > >> As such, there could be multiple metrics as long as there is good logic > >>to tie them in. for instance one would look at optimizing metric A > >>within contraints as expressed by metric B and the OF model will allow > >>that. > >> > >> OTOH, it a flows requires a certain optimization (say per one metric) > >>and another requires something different, then certainly you want two > >>instances. > >> > >> So ... it depends! > >> > >> Pascal > >> > >> > >> -----Original Message----- > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf > >> Of Michael Richardson > >> Sent: vendredi 25 mai 2012 16:54 > >> To: roll@ietf.org > >> Subject: [Roll] knowing which multiple metrics matter: MRHOF related > >> questions > >> > >> > >> Ralph asked some questions a few days ago. > >> His originally DISCUSS is at: > >> > >> http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of/ > >> ballot/ > >> > >> This was my reply. I am particularly interested in replies from > >> Pascal, Anders and Mukul about my assertion about how we would never > >>pick RPL instances by metrics; that they would in fact be seperate RPL > >>Instance numbers and DODAG values, and that these things would > >>provisioned by the network installer. > >> > >> ==== > >> > >> I'm going to reply to your comments in a different order than you asked > >>them, because I think question #3 is most important, and the rest fall > >>out of it. > >> > >>>>>>> "Ralph" == Ralph Droms writes: > >> Ralph> 3. Based on (1) and (2), would configuration and selection > >> Ralph> issues be ameliorated if the five candidate selected metrics > >> Ralph> were each asssigned a separate objective function? Use of a > >> Ralph> separate OF code point for each of the five possible selected > >> Ralph> metrics would allow multiple RPL instances. > >> > >> I think that it's important to understand that ROLL has a whole palette > >>of things that need to be provisioned by the "network operator". > >> > >> In contrast to the situation of ISPs and customers, where the ISP is > >> the network operator, ROLL networks are more like highly orchestrated > >> Enterprises: "all your host belong to us" > >> > >> so, when we write something like: > >> "The metric chosen by the network operator to use for path > >> selection." > >> in section 2, we really mean: > >> "The metric chosen by the network operator and provisioned into > >> the node when the firmware was flashed to use for path selection." > > > >OK, so I get that the model is that MRHOF is a toolbox, where the > >specific tools are chosen when the device is flashed. In that case, I > >think some additional review might be needed to ensure that the MRHOF > >spec is internally consistent with that point of view. > > > >As one example, I think the "selected metric" should be called out > >explicitly somewhere in section 5 and included in the list of configured > >parameters in section 6.1. > > > >As another example, I read this text from section 3: > > > > Rank is undefined for these node/link metrics: node state and > > attributes, throughput, and link color. If the rank is undefined, > > the node must join one of the neighbors as a RPL Leaf node according > > to [RFC6550]. > > > >to mean that if the selected metric is one of the metrics for which rank > >is undefined, the node joins as a lead node. But, how can that happen if > >the selected metric is chosen by the network operator? > > > >> Ralph> 1. Why is one objective function defined for several potential > >> Ralph> metrics? The details of MRHOF seem to preclude the > >> Ralph> establishment of several RPL instances in an LLN, each of which > >> Ralph> uses MRHOF with a different selected metric. > >> > >> If one had many different RPL Instances, then we would have different > >> RPL Instance numbers in the RPL header. There can be many different > >> DODAG ("destinations") created within that instance. The instances > >>share a common set of (provisioned) parameters. > > > >How does a node know which RPL Instance number maps to which selected > >metric? > > > >One way would be to specify that a node advertise ONLY the selected > >metric for the RPL Instance in a DIO. > > > >> (To put it into DHCP terms: if we have multiple DHCP servers on a link, > >> then one would expect them to all offer IP addresses in the same subnet. > >> If one wanted to have addresses in different subnets, and let the host > >> pick between them, then, one would need different layer-2s: different > >> VLANs or ESSIDs, or... ) > >> > >> If you feel that RPL is rather schizo about provisioning vs > >>configuration, then I agree. It's not always clear to me why some > >>things are advertised while others are provisioned. > >> > >> In BGPv4, we calculate metrics by adding AS entries in the path. > >> (It's always additive), and we add at least one AS entry to the path. > >> One can AS-stuff and add more, but proper operation of BGP does not > >>depend upon the exact algorithm used. > >> > >> Finally, my impression is that how the various metrics are used > >>(singly, or in some combination) to calculate Rank Increase is a > >>question of further research, experimentation, and trade secret. > > > >Well, OK, but for the purposes of the MRHOF spec, it seems pretty clear > >to me there is one selected metric that is used across all nodes as a > >strictly additive path cost computation. > > > >> So long as the Rank increases, and a node does not flap between > >>parents, the exact details do not matter. Each node can do it's parent > >>selection based upon the available metrics on it's own. It advertises > >>the metrics it has. > >> > >> I hope the authors will correct me if I'm completely off here. > > > >I read the spec to require a single selected metric across the entire RPL > >Instance. > > > >- Ralph > > > >> > >> > >> > >> > >> > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > > > >_______________________________________________ > >Roll mailing list > >Roll@ietf.org > >https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Mon Jun 11 09:20:23 2012 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 02B2421F8643 for ; Mon, 11 Jun 2012 09:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.718 X-Spam-Level: X-Spam-Status: No, score=-0.718 tagged_above=-999 required=5 tests=[AWL=1.236, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FvE-07Fd0hJN for ; Mon, 11 Jun 2012 09:20:22 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 11DFB21F863B for ; Mon, 11 Jun 2012 09:20:18 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 33F3E81ED; Mon, 11 Jun 2012 12:17:57 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 5335598239; Mon, 11 Jun 2012 12:20:16 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4F77798182; Mon, 11 Jun 2012 12:20:16 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <024401cd47cc$47254de0$d56fe9a0$@olddog.co.uk> References: <024401cd47cc$47254de0$d56fe9a0$@olddog.co.uk> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 11 Jun 2012 12:20:16 -0400 Message-ID: <20818.1339431616@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] IANA registry for OFs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Jun 2012 16:20:23 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Adrian" =3D=3D Adrian Farrel writes: Adrian> If I understood this part of the thread correctly, you are sugg= esting revising Adrian> the current registry (http://www.iana.org/assignments/rpl/rpl.x= ml#ocp) that is Adrian> set up as a single range 0-65535 with "IETF review" allocation = policy. Adrian> According to RFC 5226 that means "New values are assigned only = through RFCs that Adrian> have been shepherded through the IESG as AD-Sponsored or IETF W= G Documents" Adrian> It seems to me that this is adequate for immediate needs, but y= ou might be Adrian> asking to relax this and partition the range for future use. Yo= u could consider Adrian> a range of first come first served code points, or a range (pos= sibly just one). I think that it is fine to leave this as it is until we actually have an industry association create a new OF.=20=20=20=20 It is a shame that we didn't reserve some numbers for private use. If you think we should reserve some for private use (1K is enough), and set aside 8K or so for First Come First Served or Expert Review, I will write that document. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT9YawIqHRg3pndX9AQIt9AQAtzjP0JzOmeDA4KpED06AEGsvVqTDjnBp 6QegbgQO4NtaNrUkcVhEsA70wGXEa3600EM7N9MEwZCuEu68v0+dHoZeVjD2cUPR t4eq5N0UchwiZsp0V8Qo/XNsgGQtdD1CJvHRytKNanp4U9K6tptffs6DX3JXdEbV /dyAjUYfAGI= =Nyex -----END PGP SIGNATURE----- --=-=-=-- From brian@innovationslab.net Thu Jun 7 16:22:28 2012 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 7A69E11E80EE for ; Thu, 7 Jun 2012 16:22:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PaZUnRtFC1Zn for ; Thu, 7 Jun 2012 16:22:27 -0700 (PDT) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id D061E11E8088 for ; Thu, 7 Jun 2012 16:22:14 -0700 (PDT) Received: from clairseach.fuaim.com (clairseach.fuaim.com [206.197.161.141]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id ACEC3880C7; Thu, 7 Jun 2012 16:22:14 -0700 (PDT) Received: from Littlejohn.local (c-68-33-164-105.hsd1.dc.comcast.net [68.33.164.105]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id B185614003A; Thu, 7 Jun 2012 16:22:13 -0700 (PDT) Message-ID: <4FD137A4.3080801@innovationslab.net> Date: Thu, 07 Jun 2012 19:22:12 -0400 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Omprakash Gnawali References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 11 Jun 2012 10:55:05 -0700 Cc: Stiemerling Martin , Michael Richardson , roll Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Jun 2012 23:22:28 -0000 On 6/7/12 6:12 PM, Omprakash Gnawali wrote: > On Thu, Jun 7, 2012 at 4:49 PM, Pascal Thubert (pthubert) > wrote: >> >> On Jun 6, 2012, at 10:43 AM 6/6/12, Philip Levis wrote: >> >>> Responses inline. >>> >>> On Jun 4, 2012, at 9:31 AM, Ralph Droms wrote: >>> >>>>> >>>> >>>> My question here is why a single objective function "MRHOF" is >>>> defined to use several different metrics. My understanding is >>>> that any specific RPL instance will use one metric as its >>>> "selected metric" for MRHOF. Another way to organize the >>>> objective functions would be to define a different OF number >>>> for each metric, binding the OF number to the selected metric. >>> >>> This was a design decision made early in RPL. There were two >>> options: OFs are metric-specific, or OFs can be general with >>> respect to metrics. The design team concluded the second approach >>> was better, as the former would lead to a possibly huge number of >>> OFs that would be hard to manage. >> >> Now that a real OF has actually been designed and specified, >> perhaps this would be a good time to reconfirm that design >> decision. >> >> Given that MRHOF is a pretty general objective function, and works >> over 5 (or perhaps 3) metrics, 16 bits would seem to provide plenty >> of code points for metric-specific OFs. >> >> A bigger issue, I think, is expressing the semantics or behavior of >> an OF in its OCP. I read section 18.6 of RFC 6550 to indicate that >> a node will use information including the OF (as indicated by the >> OCP) to compare against the node's policy for joining a DODAG. As >> an aside, is there a reason why a node would choose to join a >> specific DODAG within a RPL Instance and on what basis would it >> make that choice? Anyway, wouldn't the selected metric used by >> MRHOF in a particular RPL Instance be a useful parameter for the >> policy rules? For example, I can imagine a node preferring to join >> a RPL Instance providing minimal latency over one providing best >> ETX. If the OCP is metric-specific, that selected metric will be >> immediately available for the policy rules. >> >> >> [Pascal] I agree with Ralph here. I fail to be convinced that there >> will an explosion of OCPs if we fail to factorize the metrics. But >> I see how the device implementation can be simplified if the OCP >> says it all. Also, we do not want to force a device that implements >> MRHOF to have to implement all metrics in the I-D. Conversely, say >> we extend MrHof to other metrics with further work, wouldn't it >> become OCP 2 anyway? I wouldn't mind blocking OCP 1..9 for current >> and future MrHof metric variations. > > Just one clarification - MRHOF does not require the devices to > support all the metrics listed in the I-D. All it says is it must > implement at least one metric. Excuse the pedantic question, but won't there be an issue if half the devices in an RPL instance implement one metric and the other half implement a different metric? This would seem to force users to select all their devices based on which metric they want to use. Regards, Brian From trakadasp@yahoo.gr Tue Jun 12 00:36:57 2012 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 05FB521F85C2 for ; Tue, 12 Jun 2012 00:36:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.88 X-Spam-Level: *** X-Spam-Status: No, score=3.88 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FRT_ROLEX=3.878, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHioPFwWfi-A for ; Tue, 12 Jun 2012 00:36:55 -0700 (PDT) Received: from nm6-vm1.bullet.mail.ird.yahoo.com (nm6-vm1.bullet.mail.ird.yahoo.com [77.238.189.220]) by ietfa.amsl.com (Postfix) with SMTP id 4BB7821F85B6 for ; Tue, 12 Jun 2012 00:36:55 -0700 (PDT) Received: from [77.238.189.56] by nm6.bullet.mail.ird.yahoo.com with NNFMP; 12 Jun 2012 07:36:51 -0000 Received: from [212.82.108.132] by tm9.bullet.mail.ird.yahoo.com with NNFMP; 12 Jun 2012 07:36:51 -0000 Received: from [127.0.0.1] by omp1037.mail.ird.yahoo.com with NNFMP; 12 Jun 2012 07:36:51 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 677675.22075.bm@omp1037.mail.ird.yahoo.com Received: (qmail 87529 invoked by uid 60001); 12 Jun 2012 07:36:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.gr; s=s1024; t=1339486611; bh=xIcBP0MxEYiqAypyeUY5r/2OO/kExrPY5wTbX8eUv90=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=QiiMlguNq6hswlrP/tJsn/douzhZyP+1tsUjH1iKae4mzQofZMRe3Sl5DHs0IRLaW/nirRYVOHKbRF9Vb8tr5p5rHlvpKO//viRE0I+c7O3xMBx0vCANs0gR8JFDMj5zSrMABtT0JUlp0PpsZEbwZkTSCI+UF5v6+ONWNWv0VpI= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.gr; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=M3VwWH9iJfpro2X9cQMPvHfNVql6ivd8KU23Iw75eiqiZNCJyLMHo/0wisNnimvFyJJlHCYa/ncy5LVY2jwGzSFmDWjt2RGoQzQSnjnfCVbqYLoaWoEEN2Ur6T4nYteOc9Jy5a4OW55m1LneMKb9Mo5LCIdZDNO4SkszDVYc9Dw=; X-YMail-OSG: pXq_XxUVM1k7k_89hzJEMD36vevNJ18u4waPfRTwtTo46UC 42LqoZWmb2iQk2iZ2rntN4fQA92jr..e6Z.qxpSSxxbzyqamFGqaF9FWNX75 lwQNBGJ9Y_1hCKQyKeP7gV9mtsANdqVDdIX1boAZOk836gYntGok5Leh7UaP d3qea.mzaUQps4eeludGDr4ZnB0p4XK4wfjYI6bR9o1nmqvQQ8E.D7bBUjxZ QOqhtnWgwY9RQCSCN6qVPKgO2fN9euULbAgBdAqYNVtezOQSsddu6Xa_flxm O4Zibi963Fqqpz.7OLNON5wuQRNcxEhZT1VcVK50SHjsP0bhzwOE.tHaNMGr JR1H_gjYlBG1qs.QcN06i9hXi2H5KcYKZVowsjF41MJt8xNiV_7bbqwgkS4i eIXmt4hrvdGX8Nx5RnMJvmCIKsUN3imxkAfjaondoO3kYMo3dTCLnJ6X4MTt 1MhO2kSUHewE9rreUiNHmfIfs_ic7W47Tueq.vAXACT5aLoHB2LtJ5sV1JA. cs5F5ZH6CiKvHxLYzVk_2ZYjgOS4EJAYGKwRwFjPpkHg1pugn5776zICKPBd oU.f0d57k23Zr0O6l5XlORWqXeeqjApsAu7lIZjRyhjZ.9kpxtB42mmOcKNu 2Vg8ziEvQPL8nUkedE5.HOMJ01sZfhWfaBUx9kfjbldjE2QznKptQXhyvmE6 znH0- Received: from [83.235.46.66] by web29604.mail.ird.yahoo.com via HTTP; Tue, 12 Jun 2012 08:36:51 BST X-Mailer: YahooMailWebService/0.8.118.349524 References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <4FD137A4.3080801@innovationslab.net> Message-ID: <1339486611.86434.YahooMailNeo@web29604.mail.ird.yahoo.com> Date: Tue, 12 Jun 2012 08:36:51 +0100 (BST) From: Panos Trakadas To: roll In-Reply-To: <4FD137A4.3080801@innovationslab.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1578982885-326859671-1339486611=:86434" Subject: [Roll] Enhanced RPL functionality on J-Sim platform X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Panos Trakadas List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 07:36:57 -0000 ---1578982885-326859671-1339486611=:86434 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all,=0AFollowing the exchange of emails during the last days regarding= MRHOF and in general the on-going discussion on metrics composition and mu= ltiple instances support, we would like to inform you that we uploaded a po= werful simulation platform of RPL, enhanced with several metrics (and about= 30 OFs), composition approaches and support of multiple instances at the g= oogle code repository (http://code.google.com/p/rpl-jsim-platform/downloads= /list).=0AThis work has started within FP7 project VITRO, as there was no o= pen source code for running simulations of RPL.=0AThe source code is, in ge= neral, in line with RPL specs (we tried to reflect some changes, as develop= ment started on version 13 of RPL RFC).=0A=0AFor convenience, we provide an= installation guide for j-sim and rpl source code as well as detailed expla= nation for several examples included in the source code (ROLL_examples fold= er in the downloaded zip file).=0APlease notice that this simulation platfo= rm introduces a trust-aware routing metric, called Packets Forwarding Indic= ation (PFI) and supports the composition of multiple metrics (ETX, HC, RSSI= , RE) in accordance to the draft-zahariadis-roll-metrics-composition docume= nt.=0APlease do not hesitate to contact us for further information or clari= fications.=0AWe also proceed with implementing enhanced functionality on re= al motes. Please see relevant videos on youtube: =0A=0Ahttp://www.youtube.c= om/watch?v=3DjscSdMbDRA0&feature=3Dplcp=0Ahttp://www.youtube.com/watch?v=3D= VzO_DyXz8vw&feature=3Dplcp=0Ahttp://www.youtube.com/watch?v=3D14ldt3-VVuw&f= eature=3Dplcp=0Aor visit VITRO project website (http://www.vitro-fp7.eu/).= =0A=0ABest Regards,=0APanos Trakadas. ---1578982885-326859671-1339486611=:86434 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear all,<= /span>
Following the exchange of emails during the last day= s regarding MRHOF and in general the on-going discussion on metrics composi= tion and multiple instances support, we would like to inform you that we up= loaded a powerful simulation platform of RPL, enhanced with several metrics= (and about 30 OFs), composition approaches and support of multiple instanc= es at the google code repository (http://code.google.com/p/rpl-jsim-platfor= m/downloads/list).
This work has started within FP7 = project VITRO, as there was no open source code for running simulations of = RPL.
The source code is, in general, in line with RP= L specs (we tried to reflect some changes, as development started on version 13 of RPL RFC).
For convenience, we provide an installati= on guide for j-sim and rpl source code as well as detailed explanation for = several examples included in the source code (ROLL_examples folder in the d= ownloaded zip file).
Please notice that this simulat= ion platform introduces a trust-aware routing metric, called Packets Forwar= ding Indication (PFI) and supports the composition of multiple metrics (ETX= , HC, RSSI, RE) in accordance to the draft-zahariadis-roll-metrics-composit= ion document.
Please do not hesitate to contact us f= or further information or clarifications.
We also pr= oceed with implementing enhanced functionality on real motes. Please see re= levant videos on youtube:
http://www.youtube.com/watch?v=3DjscSdMbDRA0&a= mp;feature=3Dplcp
http://www.youtube.com/watch?v=3DV= zO_DyXz8vw&feature=3Dplcp
http://www.youtube.com= /watch?v=3D14ldt3-VVuw&feature=3Dplcp
or visit V= ITRO project website (http://www.vitro-fp7.eu/).
Best Regards,
Panos Trakadas.

---1578982885-326859671-1339486611=:86434-- From d.sturek@att.net Tue Jun 12 06:48:03 2012 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 C2ED721F8562 for ; Tue, 12 Jun 2012 06:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.607 X-Spam-Level: X-Spam-Status: No, score=-1.607 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgjTtAwoHcpx for ; Tue, 12 Jun 2012 06:48:03 -0700 (PDT) Received: from nm4.bullet.mail.ac4.yahoo.com (nm4.bullet.mail.ac4.yahoo.com [98.139.52.201]) by ietfa.amsl.com (Postfix) with SMTP id 0B77921F8554 for ; Tue, 12 Jun 2012 06:48:02 -0700 (PDT) Received: from [98.139.52.195] by nm4.bullet.mail.ac4.yahoo.com with NNFMP; 12 Jun 2012 13:48:02 -0000 Received: from [68.142.200.227] by tm8.bullet.mail.ac4.yahoo.com with NNFMP; 12 Jun 2012 13:48:02 -0000 Received: from [66.94.237.119] by t8.bullet.mud.yahoo.com with NNFMP; 12 Jun 2012 13:48:02 -0000 Received: from [127.0.0.1] by omp1024.access.mail.mud.yahoo.com with NNFMP; 12 Jun 2012 13:48:02 -0000 X-Yahoo-Newman-Id: 393667.4161.bm@omp1024.access.mail.mud.yahoo.com Received: (qmail 47014 invoked from network); 12 Jun 2012 13:48:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1339508882; bh=g2SmUFq68iu7+te0rzGznC735kdkuF+dEad1tPyqyXA=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=fGUPIFHbg4aIGcl0+3nevDHaMnu3XMROILaCTBHE0ccfnN8jgTCVDRVdyyrCf1S2XhDcbRsMgwYSEVA2yJcaAFPsl3uTB+0YCyIGd2a1a/9PVbh2BkAV8uf1gK5KOQXRWU2hF7nOnaqWQZrE0TjegHNuWhWFua8PQ6Sfk1CZZss= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 5uJ8SicVM1nVTW3FMh1yDQWX6GI6CASjExbMolB3ywqy_oM 2IFcXKCNgfAVUHy2S624jmboA2IUhBhyJOyy14QL.gPNahpIDWnzKci1DBwI XMcAAaL0UOLjUmsHdLeLw4aOirvTTvMGXgLR.Kl1Wvwd42MZohjakpxIhgXc 1uFyvOYnvQzYosoLjp65izyzkvz5hG.bNlabggiXqaXArzL9m6E4tXYatyN1 KieFWrXYfzz1.DF_PLHe.72VwdpByF..RZSb7LrCDGIVByQ8X.F22hzcBnzo lN7lsVK2sk6snOQu45a5wznwU6KI1fw_.pMN4LxCHeIHyZYFYiP5cYDnK_k. RrDyYIk3XQw.VcdrN_gd7rJIvz8mtZljWW6yf5j4vmCVpQIhg87SpsxwI4Iy 3Gz8io4olQnUK_w17mkNAeQ3Obue_w9w0ddY- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [172.16.1.120] (d.sturek@209.226.25.155 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 12 Jun 2012 06:48:01 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Mon, 11 Jun 2012 13:27:03 -0700 From: Don Sturek To: Brian Haberman , Omprakash Gnawali Message-ID: Thread-Topic: [Roll] Ralph's DISCUSS on MRHOF spec In-Reply-To: <4FD137A4.3080801@innovationslab.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: roll , Stiemerling Martin , Michael Richardson Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 13:48:03 -0000 Hi Brian, >From our experience implementing RPL and MrHOF, all devices in a RPL instance MUST implement the same OF. I think this is why there is so much discussion on the reflector on how to convey the OF to the prospective joining devices. Don On 6/7/12 4:22 PM, "Brian Haberman" wrote: >On 6/7/12 6:12 PM, Omprakash Gnawali wrote: >> On Thu, Jun 7, 2012 at 4:49 PM, Pascal Thubert (pthubert) >> wrote: >>> >>> On Jun 6, 2012, at 10:43 AM 6/6/12, Philip Levis wrote: >>> >>>> Responses inline. >>>> >>>> On Jun 4, 2012, at 9:31 AM, Ralph Droms wrote: >>>> >>>>>> >>>>> >>>>> My question here is why a single objective function "MRHOF" is >>>>> defined to use several different metrics. My understanding is >>>>> that any specific RPL instance will use one metric as its >>>>> "selected metric" for MRHOF. Another way to organize the >>>>> objective functions would be to define a different OF number >>>>> for each metric, binding the OF number to the selected metric. >>>> >>>> This was a design decision made early in RPL. There were two >>>> options: OFs are metric-specific, or OFs can be general with >>>> respect to metrics. The design team concluded the second approach >>>> was better, as the former would lead to a possibly huge number of >>>> OFs that would be hard to manage. >>> >>> Now that a real OF has actually been designed and specified, >>> perhaps this would be a good time to reconfirm that design >>> decision. >>> >>> Given that MRHOF is a pretty general objective function, and works >>> over 5 (or perhaps 3) metrics, 16 bits would seem to provide plenty >>> of code points for metric-specific OFs. >>> >>> A bigger issue, I think, is expressing the semantics or behavior of >>> an OF in its OCP. I read section 18.6 of RFC 6550 to indicate that >>> a node will use information including the OF (as indicated by the >>> OCP) to compare against the node's policy for joining a DODAG. As >>> an aside, is there a reason why a node would choose to join a >>> specific DODAG within a RPL Instance and on what basis would it >>> make that choice? Anyway, wouldn't the selected metric used by >>> MRHOF in a particular RPL Instance be a useful parameter for the >>> policy rules? For example, I can imagine a node preferring to join >>> a RPL Instance providing minimal latency over one providing best >>> ETX. If the OCP is metric-specific, that selected metric will be >>> immediately available for the policy rules. >>> >>> >>> [Pascal] I agree with Ralph here. I fail to be convinced that there >>> will an explosion of OCPs if we fail to factorize the metrics. But >>> I see how the device implementation can be simplified if the OCP >>> says it all. Also, we do not want to force a device that implements >>> MRHOF to have to implement all metrics in the I-D. Conversely, say >>> we extend MrHof to other metrics with further work, wouldn't it >>> become OCP 2 anyway? I wouldn't mind blocking OCP 1..9 for current >>> and future MrHof metric variations. >> >> Just one clarification - MRHOF does not require the devices to >> support all the metrics listed in the I-D. All it says is it must >> implement at least one metric. > >Excuse the pedantic question, but won't there be an issue if half the >devices in an RPL instance implement one metric and the other half >implement a different metric? This would seem to force users to select >all their devices based on which metric they want to use. > >Regards, >Brian > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Tue Jun 12 12:28:14 2012 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 6479F21F867F; Tue, 12 Jun 2012 12:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.18 X-Spam-Level: X-Spam-Status: No, score=0.18 tagged_above=-999 required=5 tests=[AWL=-0.280, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TexIFz8fMUwz; Tue, 12 Jun 2012 12:28:13 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id D287E21F867E; Tue, 12 Jun 2012 12:28:13 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id A0AAB8297; Tue, 12 Jun 2012 15:25:49 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id EF97298239; Tue, 12 Jun 2012 15:28:10 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EB1ED98147; Tue, 12 Jun 2012 15:28:10 -0400 (EDT) From: Michael Richardson To: 6lowpan@ietf.org, roll@ietf.org X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 12 Jun 2012 15:28:10 -0400 Message-ID: <18113.1339529290@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] draft-bormann-ghc X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 19:28:14 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I would like to propose that draft-bormann-6lowpan-ghc-04 be adopted as a WG item. I think that 6lowpan should adopt it, but I'm willing to discuss alternatives. Some analysis in 2011 showed that even a modest application of GHC to ROLL RPL control messages resulted in sufficient compression to make ROLL RPL packets regularly fit into a single 802.15.4 payload. =2D-=20 Michael Richardson , Sandelman Software Works=20 speaking for myself --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT9eYSoqHRg3pndX9AQICkQQAj5s3pZS7LmSCSYa28hZpZGBQ7QvHLEkO olnZXcV2DFVr6goaeuIPrley0eTx28qOkBbzsyXYlIbNQIJSERytp9ELEbVbpy5c D2l05VlApXbvLSF4j1kMoZqI59/0faq/DbOOjfv7vKpyqTsz7Fo72dHu9qDOOD2g /axUlSHnPNU= =yN5e -----END PGP SIGNATURE----- --=-=-=-- From zach@sensinode.com Tue Jun 12 12:36:39 2012 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 47FDF21F86EE; Tue, 12 Jun 2012 12:36:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akm8QLENi6md; Tue, 12 Jun 2012 12:36:38 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by ietfa.amsl.com (Postfix) with ESMTP id 4231921F86E2; Tue, 12 Jun 2012 12:36:37 -0700 (PDT) Received: from [172.20.10.4] (85-156-197-8.elisa-mobile.fi [85.156.197.8]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.8/8.13.4) with ESMTP id q5CJaYpm027590; Tue, 12 Jun 2012 22:36:34 +0300 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Zach Shelby In-Reply-To: <18113.1339529290@marajade.sandelman.ca> Date: Tue, 12 Jun 2012 22:36:33 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4A21D218-A6AA-496A-9F86-2307748EE80A@sensinode.com> References: <18113.1339529290@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1084) Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] draft-bormann-ghc X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 19:36:39 -0000 +1 - I also would find this useful! And at least as a starting point = this is a solid I-D. On Jun 12, 2012, at 10:28 PM, Michael Richardson wrote: >=20 > I would like to propose that draft-bormann-6lowpan-ghc-04 be adopted = as > a WG item. I think that 6lowpan should adopt it, but I'm willing to > discuss alternatives. >=20 > Some analysis in 2011 showed that even a modest application of GHC > to ROLL RPL control messages resulted in sufficient compression to > make ROLL RPL packets regularly fit into a single 802.15.4 payload. >=20 > --=20 > Michael Richardson , Sandelman Software Works=20= > speaking for myself >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan --=20 Zach Shelby, Chief Nerd, Sensinode Ltd. http://www.sensinode.com http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 From mcr@sandelman.ca Tue Jun 12 12:39:11 2012 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 93D7321F870B; Tue, 12 Jun 2012 12:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.971 X-Spam-Level: X-Spam-Status: No, score=-0.971 tagged_above=-999 required=5 tests=[AWL=0.983, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tE4crChTvZme; Tue, 12 Jun 2012 12:39:11 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id F0A6221F86E2; Tue, 12 Jun 2012 12:39:07 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 2025C8297; Tue, 12 Jun 2012 15:36:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id EA10398239; Tue, 12 Jun 2012 15:39:06 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E13E798147; Tue, 12 Jun 2012 15:39:06 -0400 (EDT) From: Michael Richardson To: 6lowpan@ietf.org, roll@ietf.org, 6man@ietf.org X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 12 Jun 2012 15:39:06 -0400 Message-ID: <21763.1339529946@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] LLN roadmap documents: more missing pieces X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 19:39:11 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable In a private (IM) chat between Carsten Bormann and I, we realized that there was prescious little consensus about what building blocks will be used where.=20=20 For instance, I have assumed that a ROLL RPL network would not need=20 the ND parts of 6lowpan-ND, only the DAD parts (if DAD was important). That ND was unnecessary in for RPL nodes as the DAOs and DIOs served the same purpose. This surprised some others. What Carsten said was that some kind of roadmap was necessary. In another hallway conversation at Paris, I came to understand that for layer-2=3D=3DZigbee, that on Zigbee Controllers would ever need to run RPL, and that the regular nodes (such as light switches, forgive me, I do not recall their Zigbee name), would only communicate with a controller. This in contrast to what I know the home automation/P2P people are doing. Finally, I wanted to bring your attention to=20 draft-kelsey-intarea-mesh-link-establishment-03.txt which I'm told 6man is supposed to consider.=20=20 On some networks you can not send the DAOs or NDs out until you do this. I want to ask if it belongs in ROLL or 6lowpan. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT9ea2oqHRg3pndX9AQJhDQQAziwu6dv+0MxpNBIwP1s40eO+TBgswHfW szgLOLaTkk7zyWzkvxXj83eDAyDs37K5K2Ar7HtHI7grfB1j9DpJpFKzvxH7WcPA aHaDSg7z15JOdsnb90AQg4URIgP/2MwRI9lw+w21HhR8IkZouhv3xcQqz0L8OoLe 85KBrp9mjPQ= =4OPi -----END PGP SIGNATURE----- --=-=-=-- From d.sturek@att.net Tue Jun 12 12:52:56 2012 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 8634621F86FE for ; Tue, 12 Jun 2012 12:52:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSI9sDbj7huB for ; Tue, 12 Jun 2012 12:52:56 -0700 (PDT) Received: from nm40-vm2.bullet.mail.bf1.yahoo.com (nm40-vm2.bullet.mail.bf1.yahoo.com [72.30.239.210]) by ietfa.amsl.com (Postfix) with SMTP id 7FC0F21F86A0 for ; Tue, 12 Jun 2012 12:52:54 -0700 (PDT) Received: from [98.139.215.140] by nm40.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jun 2012 19:51:45 -0000 Received: from [209.191.108.96] by tm11.bullet.mail.bf1.yahoo.com with NNFMP; 12 Jun 2012 19:51:45 -0000 Received: from [66.94.237.105] by t3.bullet.mud.yahoo.com with NNFMP; 12 Jun 2012 19:51:45 -0000 Received: from [127.0.0.1] by omp1010.access.mail.mud.yahoo.com with NNFMP; 12 Jun 2012 19:51:45 -0000 X-Yahoo-Newman-Id: 78777.34822.bm@omp1010.access.mail.mud.yahoo.com Received: (qmail 70351 invoked from network); 12 Jun 2012 19:51:44 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1339530704; bh=W2A+ELjiRSrNwHJTmYn/hRigAX0bOIhN1zW7hzTliX4=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=niojt1uMEfyPohQcwNMvG2uI2rdaeOiixLm2xrpGW3auqjiZEFu7DTj+XIuxHpjVBOdhS239fEEyiDDIgEeMGJpb0O8vJBAkSur+vT7e8SSBhPQU6ECcXtOY0DTvEhCtkjeC2xRlKatmkAwISXAblXBjfwk8SwRGGaB6SN/TQa0= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 2989_TEVM1klfog0uI5gz9yx1rWUeptLAdGIvQ..fBmfoXd .gcYTqrg_iipYrNRJYgf0AmrvZmeEzl3o4vk24XUawhhkXYbjO9DMMOxCK37 3HFTJN.3UxYmEzfQSWhYm95M1Mqp0S1r_AKILV9UinosF_sY2nvO2I4CFtMH i3rl7qbrBGVnv_CkeP_e.9y_f3KZt4WZRg7nYLVHElPl5JEiRySLf9Gjollf XGnsfEtaVb3p4tw6ylvEGmu5INcyHAwnnMGZpNEeN4OB_IpUPh7KJaaCd.qR _0p8UZUU3.HsOyQ9te8wBv_MGrLPhj3SSEWXRg4brmQKwf5aVftmsdSYXwsH KRnKt2lnnVsHLqWkhQaIF2b7MbLqJKJoMJaZLmuaaSAccDKHw5wiQvaGTvF1 PC_mvU_XvoOHREDVOzGslXXLQB.GOXIVZJrs- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [172.16.1.120] (d.sturek@209.226.25.155 with login) by smtp108.sbc.mail.ne1.yahoo.com with SMTP; 12 Jun 2012 12:51:44 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Tue, 12 Jun 2012 12:51:39 -0700 From: Don Sturek To: Michael Richardson , <6lowpan@ietf.org>, , <6man@ietf.org> Message-ID: Thread-Topic: [6lowpan] LLN roadmap documents: more missing pieces In-Reply-To: <21763.1339529946@marajade.sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Roll] [6lowpan] LLN roadmap documents: more missing pieces X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 19:52:56 -0000 Hi Michael, Don Sturek, chair for the ZigBee Core Stack working group (our group is standarding "ZigBee IP" which is a configured collection of IETF drafts supporting the Smart Energy Profile 2.0 over IEEE802.15.4) It is our group who are looking to standardize MLE (in your note below). That protocol provides the ability to share link quality information among one hop neighbors plus other information (eg, long addresses of neighbors) to allow for an intelligent neighbor selection for mesh routing (including ROLL RPL). Also, in your list below, we support 6LoWPAN ND (not just DAD), MLE, ROLL RPL (non-storing) among other IETF protocols for our solution. We discussed MLE within ZigBee IP and I was not clear on whether ROLL would be the right WG. For sure, I don't think 6LoWPAN is the right place since this protocol can work over mesh networks that are not necessarily employing 6LoWPAN. I think the options we discussed were ROLL and an Internet Area submission. Don On 6/12/12 12:39 PM, "Michael Richardson" wrote: > >In a private (IM) chat between Carsten Bormann and I, we realized that >there >was prescious little consensus about what building blocks will be used >where. > >For instance, I have assumed that a ROLL RPL network would not need >the ND parts of 6lowpan-ND, only the DAD parts (if DAD was important). > >That ND was unnecessary in for RPL nodes as the DAOs and DIOs served the >same purpose. This surprised some others. What Carsten said was that >some kind of roadmap was necessary. > >In another hallway conversation at Paris, I came to understand that for >layer-2==Zigbee, that on Zigbee Controllers would ever need to run RPL, >and that the regular nodes (such as light switches, forgive me, I do not >recall their Zigbee name), would only communicate with a controller. > >This in contrast to what I know the home automation/P2P people are >doing. > >Finally, I wanted to bring your attention to > draft-kelsey-intarea-mesh-link-establishment-03.txt > >which I'm told 6man is supposed to consider. >On some networks you can not send the DAOs or NDs out until you do this. > >I want to ask if it belongs in ROLL or 6lowpan. > >-- >Michael Richardson , Sandelman Software Works >IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > >_______________________________________________ >6lowpan mailing list >6lowpan@ietf.org >https://www.ietf.org/mailman/listinfo/6lowpan From ulrich@herberg.name Tue Jun 12 13:56:15 2012 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 4502D11E80C5 for ; Tue, 12 Jun 2012 13:56:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.738 X-Spam-Level: X-Spam-Status: No, score=-0.738 tagged_above=-999 required=5 tests=[AWL=-2.239, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ROLEX=3.878, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z12RB+dzlgij for ; Tue, 12 Jun 2012 13:56:14 -0700 (PDT) Received: from mail-gh0-f172.google.com (mail-gh0-f172.google.com [209.85.160.172]) by ietfa.amsl.com (Postfix) with ESMTP id EA79611E80CC for ; Tue, 12 Jun 2012 13:56:13 -0700 (PDT) Received: by ghbg16 with SMTP id g16so4462851ghb.31 for ; Tue, 12 Jun 2012 13:56:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RF61eaLfgJBDGCtj3du71OskejtZdhts9E2sqmXs0s4=; b=b+SFuJBfFWWlkLpSjS7zi8D0c4qCBnZgxs1w/65etGf67VEPTHAUAuNtHHgPnIUEYV JdnE0eIHLnaUOzPbYjuTNItLRxVVV+8ox+RvplPCifg5dRmuL2H3jXr/RUdhVEU+cWrM jcscUnWJhE4lJ0HkVWywc5oFkSDKBk0f3PkoA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=RF61eaLfgJBDGCtj3du71OskejtZdhts9E2sqmXs0s4=; b=kpGzaZlZApYMGRDlvpd7NPbntnXqTKFR1q2gQRr02RAW9cYTqdBxwnmXNWGvQtsEpU W1+lIvXX0L/rBrfKXljpy7z2iiQm4a/VK+IEGWfM4aY+55+9EVz1bvLdSiojCdzNdK7O kfPya22DqmZdaH3GE24lwTcd4eD3/crWHlQK5Ovo6Tf0neRgXkzCibnxaRDFWQrqq4jX l2CHf9un38rN/iNpXt/mDh26z0sfGWN4IZccxB2OTuIzizzg1DeY3BwGdgqr/qiRr932 TKJrI/oL7rmdduanuiyITXnXEmR7+dmKndTo5M88HBuN6VT7rZIz4ZdJfJoogXswVgWw RYjw== MIME-Version: 1.0 Received: by 10.236.193.6 with SMTP id j6mr14257160yhn.104.1339534573472; Tue, 12 Jun 2012 13:56:13 -0700 (PDT) Received: by 10.146.248.21 with HTTP; Tue, 12 Jun 2012 13:56:13 -0700 (PDT) In-Reply-To: <1339486611.86434.YahooMailNeo@web29604.mail.ird.yahoo.com> References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <4FD137A4.3080801@innovationslab.net> <1339486611.86434.YahooMailNeo@web29604.mail.ird.yahoo.com> Date: Tue, 12 Jun 2012 13:56:13 -0700 Message-ID: From: Ulrich Herberg To: Panos Trakadas Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlnUBhmxXCf1aMXxX8ES18AJDtfzkBIHIiaaF03ZdWFiYcAjTsdTvcLk5X17GVcBcvVwsy+ Cc: roll Subject: Re: [Roll] Enhanced RPL functionality on J-Sim platform X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jun 2012 20:56:15 -0000 Hi, it's always good to have open-source implementations. Thank you! On a quick glance, it seems that you define one objective function code per OF+metric (i.e., for a single objective function multiple variations per metric). Have I understood your code correctly in that regards? Best Ulrich On Tue, Jun 12, 2012 at 12:36 AM, Panos Trakadas wrote: > Dear all, > Following the exchange of emails during the last days regarding MRHOF and in > general the on-going discussion on metrics composition and multiple > instances support, we would like to inform you that we uploaded a powerful > simulation platform of RPL, enhanced with several metrics (and about 30 > OFs), composition approaches and support of multiple instances at the google > code repository (http://code.google.com/p/rpl-jsim-platform/downloads/list). > This work has started within FP7 project VITRO, as there was no open source > code for running simulations of RPL. > The source code is, in general, in line with RPL specs (we tried to reflect > some changes, as development started on version 13 of RPL RFC). > For convenience, we provide an installation guide for j-sim and rpl source > code as well as detailed explanation for several examples included in the > source code (ROLL_examples folder in the downloaded zip file). > Please notice that this simulation platform introduces a trust-aware routing > metric, called Packets Forwarding Indication (PFI) and supports the > composition of multiple metrics (ETX, HC, RSSI, RE) in accordance to the > draft-zahariadis-roll-metrics-composition document. > Please do not hesitate to contact us for further information or > clarifications. > We also proceed with implementing enhanced functionality on real motes. > Please see relevant videos on youtube: > http://www.youtube.com/watch?v=jscSdMbDRA0&feature=plcp > http://www.youtube.com/watch?v=VzO_DyXz8vw&feature=plcp > http://www.youtube.com/watch?v=14ldt3-VVuw&feature=plcp > or visit VITRO project website (http://www.vitro-fp7.eu/). > Best Regards, > Panos Trakadas. > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From trakadasp@yahoo.gr Tue Jun 12 22:20:05 2012 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 C17A021F8737 for ; Tue, 12 Jun 2012 22:20:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.03 X-Spam-Level: *** X-Spam-Status: No, score=3.03 tagged_above=-999 required=5 tests=[AWL=0.850, BAYES_00=-2.599, FRT_ROLEX=3.878, HTML_MESSAGE=0.001, J_CHICKENPOX_26=0.6, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LpYsq0rfWc68 for ; Tue, 12 Jun 2012 22:20:04 -0700 (PDT) Received: from nm17.bullet.mail.ird.yahoo.com (nm17.bullet.mail.ird.yahoo.com [77.238.189.70]) by ietfa.amsl.com (Postfix) with SMTP id 3A36C21F8736 for ; Tue, 12 Jun 2012 22:19:56 -0700 (PDT) Received: from [77.238.189.57] by nm17.bullet.mail.ird.yahoo.com with NNFMP; 13 Jun 2012 05:19:52 -0000 Received: from [212.82.108.126] by tm10.bullet.mail.ird.yahoo.com with NNFMP; 13 Jun 2012 05:19:52 -0000 Received: from [127.0.0.1] by omp1035.mail.ird.yahoo.com with NNFMP; 13 Jun 2012 05:19:52 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 879068.61277.bm@omp1035.mail.ird.yahoo.com Received: (qmail 75354 invoked by uid 60001); 13 Jun 2012 05:19:52 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.gr; s=s1024; t=1339564792; bh=UcX6yMXutY5I3ccErDZZfIMI52uOxVbTQFvtOV+stys=; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=PbADTS7kdL97HOS7PxOOYX8bkE9K7xVBeCaP+euqbeA83YZlmlUITeFyJ5a2qyzNktbEjUxonJSL3RT9Cu5Yaqi1ArEF4H8isOnoadUZTc/meLDgOeM+6f6QaPVP9IrGz4PTO8YqRLfB89156j86cd3iwULB0yJOaptZJoYmdyg= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.gr; h=X-YMail-OSG:Received:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type; b=A7RcPTs15fv7f0zY9YPuECn1xHHJvleESGeH0xlZjiSYzT0HZ9pcjNnQGe0NnBvfCHIGZmWT41ymxwyGQH9z2bOgmVNXFhfuv67rFd0W4pnp73cTYZdPo2FOkhcnXAVCDyfKbbWenJzebN90Dzk6tuuT5/GZq/uCrqCUTeBeC5A=; X-YMail-OSG: Yyjr1g8VM1kqfWbU6UaNq_eaUawWmB7w5S5ra7uuJXKMfhv lC7pdJbzuMSzaJfO252lk3tKpzU9vyWEJq7TL1j416LqMq31LzgAkuiUuO6h 9JJwR_0ChIG_aaxM816q1mBmskDHx3LW8l1wjimXK3Il9swstIpnXLQxJTTr pj5NBIbVz22Mp4mcjhJLzYo1BOMHms9rwSOVpwvYs9D3gSMYV7YFPRNGw2eG DwWQ915jYc7KEJmmjiQQh0DBHt5TQhRsvEelotjgltcMQRgaII9IjNBIDPDg 1mkzBfMHQ8QRi1I0UoDCLkXfuO4tLrW3BRORnBxlM7Ag5ASTqlPvg9QmEIrY LrS8k7XLjo7aR.Abg66NKQBFG0TmhpOSmsgzlj4nCS7mve0sm52C.30.E5ta XRhVfHfR53qSlb_cAckq8yxM8JrDDN6f6no.VPyr6x9DbUwTu85oHsCBWFgX SWwqIzqzmrIW9wtKGNGvCANsiDF4ZAYYTNScUNtyMnGXWvvciXZ.Hj3ooLiT oWoiR4z_pbqw1doIBo_KJ7lzIkjGNu9cgyjZCDfm4ZO7_yiVHamNPvhSyi09 d6Mztboboe3WkrspRTZUe8N8y1SSBzlSwn3EvlE93RlIdnv4HK.dXpulwY73 hUCXORwmc_hMcYAAHiEyWydhNbTRiyAjNsfv8aHiYkQYQraL.A7OUOLEPOmA GZriTQ9RVAnsPmIqBHpwkw_flQsaPhFecsp4zQPzM Received: from [83.235.46.66] by web29604.mail.ird.yahoo.com via HTTP; Wed, 13 Jun 2012 06:19:52 BST X-Mailer: YahooMailWebService/0.8.118.349524 References: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> <8EFE80AF-3E7C-494E-8237-C63E6ECDAE7E@gmail.com> <53E28E3B-4C73-4BD3-BCFE-2C669FC3FA1D@cs.stanford.edu> <4FD137A4.3080801@innovationslab.net> <1339486611.86434.YahooMailNeo@web29604.mail.ird.yahoo.com> Message-ID: <1339564792.75249.YahooMailNeo@web29604.mail.ird.yahoo.com> Date: Wed, 13 Jun 2012 06:19:52 +0100 (BST) From: Panos Trakadas To: Ulrich Herberg In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-1578982885-1445094385-1339564792=:75249" Cc: roll Subject: [Roll] =?iso-8859-7?q?=D3=F7=E5=F4=3A__Enhanced_RPL_functionality?= =?iso-8859-7?q?_on_J-Sim_platform?= X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Panos Trakadas 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 Jun 2012 05:20:05 -0000 ---1578982885-1445094385-1339564792=:75249 Content-Type: text/plain; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable Hi Ulrich,=0AYes. Our implementation defines 29 different ways to construct= DODAGs, according to the application- or user-specific requirements. =0A= =0AThis is achieved through the selected Objective Code Point (OCPs), defin= ed in RFC6550 as "an identifier that indicates=0Awhich Objective Function t= he DODAG uses". As an example, using OCP =3D 0, the DODAG will be built on = Hop-Count metric, while using OCP =3D 1, the DODAG is based on ETX. As a mo= re complex example, OCP =3D 15 defines an OF where HC is the dominant metri= c (highest precedence) and remaining energy is the second (tie-breaking) me= tric. Almost any combination of the supported metrics set (HC, ETX, RSSI, R= E, PFI) defines an OCP and a respective OF.=0A=0AThe OCPs are mentioned in = the tcl examples and defined in the jsim-1.3\src\drcl\inet\protocol\rpl\RPL= _ObjFunctions.java.In that sense, each OCP defines a different OF that maxi= mizes (or minimizes) the Rank value (depending on whether the metrics are m= aximizable or minimizable). =0ABR,=0APanos.=0A=0A=0A=0A____________________= ____________=0A =C1=F0=EF: Ulrich Herberg =0A=D0=F1=EF= =F2: Panos Trakadas =0A=CA=EF=E9=ED.: roll =0A=D3=F4=DC=EB=E8=E7=EA=E5: 11:56 =EC.=EC. =D4=F1=DF=F4=E7, 12 =C9=EF= =F5=ED=DF=EF=F5 2012=0A=C8=E5=EC=E1: Re: [Roll] Enhanced RPL functionality = on J-Sim platform=0A =0AHi,=0A=0Ait's always good to have open-source imple= mentations. Thank you!=0A=0AOn a quick glance, it seems that you define one= objective function=0Acode per OF+metric (i.e., for a single objective func= tion multiple=0Avariations per metric). Have I understood your code correct= ly in that=0Aregards?=0A=0ABest=0AUlrich=0A=0AOn Tue, Jun 12, 2012 at 12:36= AM, Panos Trakadas wrote:=0A> Dear all,=0A> Following= the exchange of emails during the last days regarding MRHOF and in=0A> gen= eral the on-going discussion on metrics composition and multiple=0A> instan= ces support, we would like to inform you that we uploaded a powerful=0A> si= mulation platform of RPL, enhanced with several metrics (and about 30=0A> O= Fs), composition approaches and support of multiple instances at the google= =0A> code repository (http://code.google.com/p/rpl-jsim-platform/downloads/= list).=0A> This work has started within FP7 project VITRO, as there was no = open source=0A> code for running simulations of RPL.=0A> The source code is= , in general, in line with RPL specs (we tried to reflect=0A> some changes,= as development started on version 13 of RPL RFC).=0A> For convenience, we = provide an installation guide for j-sim and rpl source=0A> code as well as = detailed explanation for several examples included in the=0A> source code (= ROLL_examples folder in the downloaded zip file).=0A> Please notice that th= is simulation platform introduces a trust-aware routing=0A> metric, called = Packets Forwarding Indication (PFI) and supports the=0A> composition of mul= tiple metrics (ETX, HC, RSSI, RE) in accordance to the=0A> draft-zahariadis= -roll-metrics-composition document.=0A> Please do not hesitate to contact u= s for further information or=0A> clarifications.=0A> We also proceed with i= mplementing enhanced functionality on real motes.=0A> Please see relevant v= ideos on youtube:=0A> http://www.youtube.com/watch?v=3DjscSdMbDRA0&feature= =3Dplcp=0A> http://www.youtube.com/watch?v=3DVzO_DyXz8vw&feature=3Dplcp=0A>= http://www.youtube.com/watch?v=3D14ldt3-VVuw&feature=3Dplcp=0A> or visit V= ITRO project website (http://www.vitro-fp7.eu/).=0A> Best Regards,=0A> Pano= s Trakadas.=0A>=0A>=0A> _______________________________________________=0A>= Roll mailing list=0A> Roll@ietf.org=0A> https://www.ietf.org/mailman/listi= nfo/roll=0A> ---1578982885-1445094385-1339564792=:75249 Content-Type: text/html; charset=iso-8859-7 Content-Transfer-Encoding: quoted-printable
Hi Ulrich,=
Yes. Our implementation defines 29 different ways t= o construct DODAGs, according to the application- or user-specific requirem= ents.
This is achieved through the selected Obj= ective Code Point (OCPs), defined in RFC6550 as "an identifier that indicat= es
which Objective Function the DODAG uses". As an example,= using OCP =3D 0, the DODAG will be built on Hop-Count metric, while using = OCP =3D 1, the DODAG is based on ETX. As a more complex example, OCP =3D 15= defines an OF where HC is the dominant metric (highest precedence) and rem= aining energy is the second (tie-breaking) metric. Almost any combination o= f the supported metrics set (HC, ETX, RSSI, RE, PFI) defines an OCP and a r= espective OF.
The OCPs are mentioned in the tcl examples and defined in the jsim-1.3\src\drcl\inet\protocol\rpl\RPL_ObjFun= ctions.java.
=0AIn that sense, each OCP defines a differe= nt OF that maximizes (or minimizes) the Rank value (depending on whether th= e metrics are maximizable or minimizable).
BR,
Panos.

=C1=F0= =EF: Ulrich Herberg <ulrich@herberg.name>
=D0=F1=EF=F2: Panos Trakadas <traka= dasp@yahoo.gr>
=CA=EF=E9=ED.:<= /span> roll <roll@ietf.org>
=D3=F4=DC=EB=E8=E7=EA=E5: 11:56 =EC.=EC. =D4=F1=DF=F4=E7, = 12 =C9=EF=F5=ED=DF=EF=F5 2012
=C8= =E5=EC=E1: Re: [Roll] Enhanced RPL functionality on J-Sim platfo= rm

Hi,

it's always good to have open-source impleme= ntations. Thank you!

On a quick glance, it seems that you define one= objective function
code per OF+metric (i.e., for a single objective fun= ction multiple
variations per metric). Have I understood your code corre= ctly in that
regards?

Best
Ulrich

On Tue, Jun 12, 2012 = at 12:36 AM, Panos Trakadas <trakadasp@yahoo.gr> wrote:
> = Dear all,
> Following the exchange of emails during the last days reg= arding MRHOF and in
> general the on-going discussion on metrics comp= osition and multiple
> instances support, we would like to inform you= that we uploaded a powerful
> simulation platform of RPL, enhanced w= ith several metrics (and about 30
> OFs), composition approaches and = support of multiple instances at the google
> code repository (http://code.google.com/p/rpl-jsim-platform/downloads/list).=
> This work has started within FP7 project VITRO, as there was no op= en source
> code for running simulations of RPL.
> The source c= ode is, in general, in line with RPL specs (we tried to reflect
> som= e changes, as development started on version 13 of RPL RFC).
> For co= nvenience, we provide an installation guide for j-sim and rpl source
>= ; code as well as detailed explanation for several examples included in the=
> source code (ROLL_examples folder in the downloaded zip file).
= > Please notice that this simulation platform introduces a trust-aware r= outing
> metric, called Packets Forwarding Indication (PFI) and suppo= rts the
> composition of multiple metrics (ETX, HC, RSSI, RE) in acco= rdance to the
> draft-zahariadis-roll-metrics-composition document.
> Please do not hesitate to contact us for further informa= tion or
> clarifications.
> We also proceed with implementing e= nhanced functionality on real motes.
> Please see relevant videos on = youtube:
> http://www.youtube.com/watch?v=3DjscSdM= bDRA0&feature=3Dplcp
> http://www.youtube.= com/watch?v=3DVzO_DyXz8vw&feature=3Dplcp
> http://www.youtube.com/watch?v=3D14ldt3-VVuw&feature=3Dplcp
>= ; or visit VITRO project website (http://www.vitro-fp7.eu/).
> Best Regards,
> = Panos Trakadas.
>
>
> ___________________________________= ____________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll=
>


---1578982885-1445094385-1339564792=:75249-- From abdussalambaryun@gmail.com Wed Jun 13 05:46:47 2012 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 464ED21F8637; Wed, 13 Jun 2012 05:46:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EY8CQ2qIrPQK; Wed, 13 Jun 2012 05:46:46 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC6321F863B; Wed, 13 Jun 2012 05:46:46 -0700 (PDT) Received: by vcqp1 with SMTP id p1so326331vcq.31 for ; Wed, 13 Jun 2012 05:46:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ZFvmnonl8Dvz2PO/uRSUMJW+4kS2xLlmFRuh1Uwctno=; b=ogBPMgkvgNHtg/N4cLb+C0GjedPqERVIQMnsrEvGLFuWf4OecZgk0YLtgm0RGzxUVA 6EHalwYxsF4nIfXC2tpTV972g7aZVi1K8XnWPaVgDnMVoHYjKa701CTMo6LHNrESksIQ hSHXSMQ1/jezT5abWs1xMdcLPqFJcG6OOPfr+YQlF/WrVSmxoQ7+6YYZfJfaFzgULzJO bmRA/GmWIyb2qJxRWSGIlEG9+AGMNWmE6Az80oYLq4mcwKAknXoww1qMmdf4AQ7nSvJD l1Wnow/eCdAEPyg58EcMqJJ0Je/vlWxakaOtvVRFzyYOQxumyEna6q9GAGj4Vr34zhS8 VdYg== MIME-Version: 1.0 Received: by 10.52.94.36 with SMTP id cz4mr14303133vdb.10.1339591606090; Wed, 13 Jun 2012 05:46:46 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Wed, 13 Jun 2012 05:46:46 -0700 (PDT) In-Reply-To: <18113.1339529290@marajade.sandelman.ca> References: <18113.1339529290@marajade.sandelman.ca> Date: Wed, 13 Jun 2012 13:46:46 +0100 Message-ID: From: Abdussalam Baryun To: Michael Richardson Content-Type: multipart/alternative; boundary=20cf307f3166d33ae904c259f9a3 Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] draft-bormann-ghc 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 Jun 2012 12:46:47 -0000 --20cf307f3166d33ae904c259f9a3 Content-Type: text/plain; charset=ISO-8859-1 +1 AB On Tue, Jun 12, 2012 at 8:28 PM, Michael Richardson wrote: > > I would like to propose that draft-bormann-6lowpan-ghc-04 be adopted as > a WG item. I think that 6lowpan should adopt it, but I'm willing to > discuss alternatives. > > Some analysis in 2011 showed that even a modest application of GHC > to ROLL RPL control messages resulted in sufficient compression to > make ROLL RPL packets regularly fit into a single 802.15.4 payload. > > -- > Michael Richardson , Sandelman Software Works > speaking for myself > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > --20cf307f3166d33ae904c259f9a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1
=A0
AB

On Tue, Jun 12, 2012 at 8:28 PM, Michael Richard= son <mcr+ietf@sandelman.ca> wrote:

I would like to propose that draf= t-bormann-6lowpan-ghc-04 be adopted as
a WG item. =A0I think that 6lowpa= n should adopt it, but I'm willing to
discuss alternatives.

Some analysis in 2011 showed that even a modes= t application of GHC
to ROLL RPL control messages resulted in sufficient= compression to
make ROLL RPL packets regularly fit into a single 802.15= .4 payload.

--
Michael Richardson= <mcr+IETF@sandelman.ca&g= t;, Sandelman Software Works
speaking for myself

 _______________________________________________
6lowpan mailing list
= 6lowpan@ietf.org
https://www.ie= tf.org/mailman/listinfo/6lowpan


--20cf307f3166d33ae904c259f9a3-- From daniel.gavelle@nxp.com Wed Jun 13 06:17:09 2012 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 D94E221F8518; Wed, 13 Jun 2012 06:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvBHg9T7JH8s; Wed, 13 Jun 2012 06:17:08 -0700 (PDT) Received: from be1ssnxpe2.nxp.com (be1ssnxpe2.nxp.com [57.67.164.70]) by ietfa.amsl.com (Postfix) with ESMTP id 5F65521F860F; Wed, 13 Jun 2012 06:17:07 -0700 (PDT) Received: from EU1RDCRDC1VW025.exi.nxp.com ([134.27.176.170]) by be1ssnxpe2.nxp.com (8.14.4/8.14.4) with ESMTP id q5DDH5hx000737 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 13 Jun 2012 15:17:05 +0200 Received: from eu1rdcrdc1wx032.exi.nxp.com ([134.27.179.186]) by EU1RDCRDC1VW025.exi.nxp.com ([134.27.176.170]) with mapi; Wed, 13 Jun 2012 15:17:05 +0200 From: Daniel Gavelle To: Michael Richardson Date: Wed, 13 Jun 2012 15:17:04 +0200 Thread-Topic: [Roll] [6lowpan] draft-bormann-ghc Thread-Index: Ac1JYpq6BuGyOPawTQuWZi/fesx2DQABCiIg Message-ID: <927C66C0775CCA43B88EB1E3006614B316E5DD87@eu1rdcrdc1wx032.exi.nxp.com> References: <18113.1339529290@marajade.sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_927C66C0775CCA43B88EB1E3006614B316E5DD87eu1rdcrdc1wx032_" MIME-Version: 1.0 Cc: "roll@ietf.org" , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [Roll] [6lowpan] draft-bormann-ghc 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 Jun 2012 13:17:10 -0000 --_000_927C66C0775CCA43B88EB1E3006614B316E5DD87eu1rdcrdc1wx032_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 __________________________________________________ Daniel Gavelle, Software Team Leader Low Power RF Solutions (formerly Jennic Ltd.) NXP Semiconductors Furnival Street, Sheffield, S1 4QT, UK Tel: +44 114 281 2655 Fax: +44 114 281 2951 Comp Reg No: 3191371 - Registered In England http://www.nxp.com http://www.jennic.com __________________________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Abd= ussalam Baryun Sent: 13 June 2012 13:47 To: Michael Richardson Cc: roll@ietf.org; 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] draft-bormann-ghc +1 AB On Tue, Jun 12, 2012 at 8:28 PM, Michael Richardson > wrote: I would like to propose that draft-bormann-6lowpan-ghc-04 be adopted as a WG item. I think that 6lowpan should adopt it, but I'm willing to discuss alternatives. Some analysis in 2011 showed that even a modest application of GHC to ROLL RPL control messages resulted in sufficient compression to make ROLL RPL packets regularly fit into a single 802.15.4 payload. -- Michael Richardson >,= Sandelman Software Works speaking for myself _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --_000_927C66C0775CCA43B88EB1E3006614B316E5DD87eu1rdcrdc1wx032_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1

 

 

_________________________= _________________________

 

Daniel Gavelle, Software Team Leader

Low Power RF Solutions (formerly Jennic Ltd.)

NXP Semiconductors Furnival Street, =

Sheffield,

S1 4Q= T, UK

Tel: +44 114 281 2655

Fax: +44 114 281 2951

Comp Reg No: 3191371 - Registered In England

http://www.nxp.com http://www.jennic.com

__________________________________________________

 

 

From: ro= ll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Abdu= ssalam Baryun
Sent: 13 June 2012 13:47
To: Michael Rich= ardson
Cc: roll@ietf.org; 6lowpan@ietf.org
Subject: Re:= [Roll] [6lowpan] draft-bormann-ghc

 

= --_000_927C66C0775CCA43B88EB1E3006614B316E5DD87eu1rdcrdc1wx032_-- From abdussalambaryun@gmail.com Wed Jun 13 06:18:37 2012 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 2122821F863B; Wed, 13 Jun 2012 06:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTZ74X55YNwX; Wed, 13 Jun 2012 06:18:36 -0700 (PDT) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 0968921F8610; Wed, 13 Jun 2012 06:18:35 -0700 (PDT) Received: by vcqp1 with SMTP id p1so345989vcq.31 for ; Wed, 13 Jun 2012 06:18:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=J6m1Ds8JEbRcuJ8d879X3N5LU9WaBYrmLnOadsrUndU=; b=vLNFQEMvdC5UpD/BIdbHlmyTY6dwU7SUoj8vXYWR6RYyEuk5ivOYuqAWyiTdLfFB8y 1p0cQBxRhoXuF5D+rYUrOZFYWuFBwkFuYgSoD0bWBhYLeq0tYB4XnvdlIwPWUurO1h0s GT3FsTjzHRWRVJARJ8PumFZ0c+KHoxfky/HdMKE5ET0Hs/Q1zSvf39Te6yfTrc3v/0i8 H4qpbCHaNu5oTPY0zO40Nrxo4fp/t2fiLY4wCPyIsGEtPteGeaHpIs9kbOxobq2jwwMs DxPciQOIv5JU2fJy6kpOW0tXlXLghgXsK3ezH908/eYC2FaRH8IB0N6JB9OX2YS0DKwj oSkg== MIME-Version: 1.0 Received: by 10.52.33.37 with SMTP id o5mr14118018vdi.86.1339593515469; Wed, 13 Jun 2012 06:18:35 -0700 (PDT) Received: by 10.220.98.77 with HTTP; Wed, 13 Jun 2012 06:18:35 -0700 (PDT) In-Reply-To: <21763.1339529946@marajade.sandelman.ca> References: <21763.1339529946@marajade.sandelman.ca> Date: Wed, 13 Jun 2012 14:18:35 +0100 Message-ID: From: Abdussalam Baryun To: Michael Richardson , Don Sturek Content-Type: multipart/alternative; boundary=20cf307ac163a20b2604c25a6b5f Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] LLN roadmap documents: more missing pieces 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 Jun 2012 13:18:37 -0000 --20cf307ac163a20b2604c25a6b5f Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, Don, and all, >What Carsten said was that some kind of roadmap was necessary. I agree with Mr.Carsten, >I want to ask if it belongs in ROLL or 6lowpan. IMHO, it belongs to 6lowpan WG first, and it MAY be for ROLL as well, overall, I think the WG AD can give us the best feedback and suggestion. >For sure, I don't think 6LoWPAN is the right >place since this protocol can work over mesh networks >that are not necessarily employing 6LoWPAN. if the protocol can work else than 6LoWPAN, then IMHO we should let each group face its use-case problems, not to give a protocol that works in many conditions to only one WG or two. Each WG SHOULD look at its purpose case for any particular protocol (as needed to be used is such area). >the ZigBee Core Stack working group I am looking for the group, but not found, this group is not an IETF group yet ! I don't see the IETF has a cooperation with Zigbee standards. If I am mistaken please inform me, IMO we should not depend on the Zigbee-WG, until it becomes IETF WG, Therefore, the work you pointed to, should be considered by both 6LoWPAN and ROLL. Regards Abdussalam Baryun, University of Glaorgan, UK. =============================================== On Tue, Jun 12, 2012 at 8:39 PM, Michael Richardson wrote: > > In a private (IM) chat between Carsten Bormann and I, we realized that > there > was prescious little consensus about what building blocks will be used > where. > > For instance, I have assumed that a ROLL RPL network would not need > the ND parts of 6lowpan-ND, only the DAD parts (if DAD was important). > > That ND was unnecessary in for RPL nodes as the DAOs and DIOs served the > same purpose. This surprised some others. What Carsten said was that > some kind of roadmap was necessary. > > In another hallway conversation at Paris, I came to understand that for > layer-2==Zigbee, that on Zigbee Controllers would ever need to run RPL, > and that the regular nodes (such as light switches, forgive me, I do not > recall their Zigbee name), would only communicate with a controller. > > This in contrast to what I know the home automation/P2P people are > doing. > > Finally, I wanted to bring your attention to > draft-kelsey-intarea-mesh-link-establishment-03.txt > > which I'm told 6man is supposed to consider. > On some networks you can not send the DAOs or NDs out until you do this. > > I want to ask if it belongs in ROLL or 6lowpan. > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > > --20cf307ac163a20b2604c25a6b5f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Michael,=A0Don, and all,
=A0
>What Carsten said was that some kind of roadmap was necessary.
=
I agree with Mr.Carsten,
=A0
>I want to ask if it belongs in ROLL or 6lowpan.
IMHO, it belongs to=A06lowpan WG first, and it=A0MAY be for ROLL as well,<= /font>
overall, I think the WG AD can give us the best= feedback and suggestion.
=A0
>For sure, I don't think 6LoWPAN is the right<= /div>
>place since this protocol can work over mesh networks
>that are not necessarily employing 6LoWPAN.
=A0
if the protocol can work else than 6LoWPAN, then
IMHO we should let each group face its use-case problems,
not to give a protocol that works in many condi= tions to
only one WG or two. Each WG SHOULD look at its = purpose case
for any particular protocol (as needed to be us= ed is such area).
=A0
>the ZigBee Core Stack working group<= /div>
=A0
I am looking for the group, but not found,
this group is not an IETF group yet=A0!<= /div>
=A0
I don't see the IETF has a cooperation=A0with Zigbee standards. If I a= m mistaken
please inform me, IMO we should not depend o= n the Zigbee-WG, until it becomes IETF WG,
=A0
Therefore,=A0the work you pointed to, should be= considered by both 6LoWPAN and ROLL.
= =A0
= Regards
= =A0
= Abdussalam Baryun,
Unive= rsity of Glaorgan, UK.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D
=A0
On Tue, Jun 12, 2012 at 8:39 PM, Michael Richard= son <mcr+ietf@sandelman.ca> wrote:

In a private (IM) chat between Ca= rsten Bormann and I, we realized that there
was prescious little consens= us about what building blocks will be used
where.

For instance, I have assumed that a ROLL RPL network would no= t need
the ND parts of 6lowpan-ND, only the DAD parts (if DAD was import= ant).

That ND was unnecessary in for RPL nodes as the DAOs and DIOs = served the
same purpose. =A0This surprised some others. =A0What Carsten said was that<= br>some kind of roadmap was necessary.

In another hallway conversati= on at Paris, I came to understand that for
layer-2=3D=3DZigbee, that on = Zigbee Controllers would ever need to run RPL,
and that the regular nodes (such as light switches, forgive me, I do notrecall their Zigbee name), would only communicate with a controller.
This in contrast to what I know the home automation/P2P people are
doing.

Finally, I wanted to bring your attention to
=A0draft-kels= ey-intarea-mesh-link-establishment-03.txt

which I'm told 6man is= supposed to consider.
On some networks you can not send the DAOs or NDs= out until you do this.

I want to ask if it belongs in ROLL or 6lowpan.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Softwa= re Works
IETF ROLL WG co-chair. =A0 =A0http://datatracker.ietf.org/wg/roll/charter/<= /a>


______________________________________________= _
6lowpan mailing list
6lowpan@ietf.or= g
https://www.ietf.org/mailman/listinfo/6lowpan


--20cf307ac163a20b2604c25a6b5f-- From m.pouillot@watteco.com Wed Jun 13 08:32:12 2012 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 D078B21F866C; Wed, 13 Jun 2012 08:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuZGaVMf3vEs; Wed, 13 Jun 2012 08:32:11 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 4A49B21F8657; Wed, 13 Jun 2012 08:32:09 -0700 (PDT) Received: from mail141-va3-R.bigfish.com (10.7.14.254) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.23; Wed, 13 Jun 2012 15:31:04 +0000 Received: from mail141-va3 (localhost [127.0.0.1]) by mail141-va3-R.bigfish.com (Postfix) with ESMTP id 35BC82C05B2; Wed, 13 Jun 2012 15:29:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.37; KIP:(null); UIP:(null); IPV:NLI; H:DB3PRD0510HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI9371Ic89bhc85dh1418Izz1202hzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah) Received: from mail141-va3 (localhost.localdomain [127.0.0.1]) by mail141-va3 (MessageSwitch) id 1339601376121709_6754; Wed, 13 Jun 2012 15:29:36 +0000 (UTC) Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.249]) by mail141-va3.bigfish.com (Postfix) with ESMTP id 172A18004B; Wed, 13 Jun 2012 15:29:36 +0000 (UTC) Received: from DB3PRD0510HT004.eurprd05.prod.outlook.com (157.56.252.37) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 13 Jun 2012 15:29:35 +0000 Received: from DB3PRD0510MB393.eurprd05.prod.outlook.com ([169.254.9.56]) by DB3PRD0510HT004.eurprd05.prod.outlook.com ([10.255.46.39]) with mapi id 14.16.0164.004; Wed, 13 Jun 2012 15:30:34 +0000 From: M Pouillot To: Daniel Gavelle , Michael Richardson Thread-Topic: [6lowpan] [Roll] draft-bormann-ghc Thread-Index: AQHNSWbkOM3FYsvI3EyqzrbkpWsaFpb4YAAg Date: Wed, 13 Jun 2012 15:30:33 +0000 Message-ID: <1D0972C5226A7649BBB5E3734FCD593DA20702@DB3PRD0510MB393.eurprd05.prod.outlook.com> References: <18113.1339529290@marajade.sandelman.ca> <927C66C0775CCA43B88EB1E3006614B316E5DD87@eu1rdcrdc1wx032.exi.nxp.com> In-Reply-To: <927C66C0775CCA43B88EB1E3006614B316E5DD87@eu1rdcrdc1wx032.exi.nxp.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.48.34] Content-Type: multipart/alternative; boundary="_000_1D0972C5226A7649BBB5E3734FCD593DA20702DB3PRD0510MB393eu_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "roll@ietf.org" , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [Roll] [6lowpan] draft-bormann-ghc 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 Jun 2012 15:32:12 -0000 --_000_1D0972C5226A7649BBB5E3734FCD593DA20702DB3PRD0510MB393eu_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 De : 6lowpan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] De la part = de Daniel Gavelle Envoy=E9 : mercredi 13 juin 2012 15:17 =C0 : Michael Richardson Cc : roll@ietf.org; 6lowpan@ietf.org Objet : Re: [6lowpan] [Roll] draft-bormann-ghc +1 __________________________________________________ Daniel Gavelle, Software Team Leader Low Power RF Solutions (formerly Jennic Ltd.) NXP Semiconductors Furnival Street, Sheffield, S1 4QT, UK Tel: +44 114 281 2655 Fax: +44 114 281 2951 Comp Reg No: 3191371 - Registered In England http://www.nxp.com http://www.jennic.com __________________________________________________ From: roll-bounces@ietf.org [mailto:roll-boun= ces@ietf.org] On Behalf Of Abdussala= m Baryun Sent: 13 June 2012 13:47 To: Michael Richardson Cc: roll@ietf.org; 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] draft-bormann-ghc +1 AB On Tue, Jun 12, 2012 at 8:28 PM, Michael Richardson > wrote: I would like to propose that draft-bormann-6lowpan-ghc-04 be adopted as a WG item. I think that 6lowpan should adopt it, but I'm willing to discuss alternatives. Some analysis in 2011 showed that even a modest application of GHC to ROLL RPL control messages resulted in sufficient compression to make ROLL RPL packets regularly fit into a single 802.15.4 payload. -- Michael Richardson >,= Sandelman Software Works speaking for myself _______________________________________________ 6lowpan mailing list 6lowpan@ietf.org https://www.ietf.org/mailman/listinfo/6lowpan --_000_1D0972C5226A7649BBB5E3734FCD593DA20702DB3PRD0510MB393eu_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1<= /p>

 <= /p>

De : 6low= pan-bounces@ietf.org [mailto:6lowpan-bounces@ietf.org] De la part de Daniel Gavelle
Envoy=E9 : mercredi 13 juin 2012 15:17
=C0 : Michael Richardson
Cc : roll@ietf.org; 6lowpan@ietf.org
Objet : Re: [6lowpan] [Roll] draft-bormann-ghc

 

+1

 = ;

 

__________________________________________________

 

Daniel Gavelle, Software Team Leader

Low Power RF Solutions (formerly Jennic Ltd.)

NXP Semiconductors Furnival Street,

Sheffield,

S1 4QT, UK

Tel: +44 114 281 2655

Fax: +44 114 281 2951

Comp Reg No: 3191371 - Registered In England

http://www.nxp.com http://www.jennic.com

__________________________________________________

 = ;

 = ;

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Abdussalam Baryun Sent: 13 June 2012 13:47
To: Michael Richardson
Cc: roll@ietf.org; 6lowpan@ietf.org
Subject: Re: [Roll] [6lowpan] draft-bormann-ghc

 

+1

 

= AB

On Tue, Jun 12, 2012 at 8:28 PM= , Michael Richardson <mcr+ietf@sandelman.ca> wrote:

=
I would like to propose that draft-bormann-6lowpan-ghc-04 be adopted as
a WG item.  I think that 6lowpan should adopt it, but I'm willing to discuss alternatives.

Some analysis in 2011 showed that even a modest application of GHC
to ROLL RPL control messages resulted in sufficient compression to
make ROLL RPL packets regularly fit into a single 802.15.4 payload.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
speaking for myself


_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www.ietf.org/mailman/listinfo/6lowpan

 

--_000_1D0972C5226A7649BBB5E3734FCD593DA20702DB3PRD0510MB393eu_-- From pthubert_cisco@yahoo.fr Wed Jun 13 16:58:47 2012 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 26FE711E80DB for ; Wed, 13 Jun 2012 16:58:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Snq75YBgPsXz for ; Wed, 13 Jun 2012 16:58:46 -0700 (PDT) Received: from nm27-vm4.bullet.mail.ne1.yahoo.com (nm27-vm4.bullet.mail.ne1.yahoo.com [98.138.91.187]) by ietfa.amsl.com (Postfix) with SMTP id 6632511E80D5 for ; Wed, 13 Jun 2012 16:58:46 -0700 (PDT) Received: from [98.138.90.49] by nm27.bullet.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 23:58:43 -0000 Received: from [98.138.87.7] by tm2.bullet.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 23:58:43 -0000 Received: from [127.0.0.1] by omp1007.mail.ne1.yahoo.com with NNFMP; 13 Jun 2012 23:58:43 -0000 X-Yahoo-Newman-Id: 252033.21485.bm@omp1007.mail.ne1.yahoo.com Received: (qmail 15086 invoked from network); 13 Jun 2012 23:58:42 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.fr; h=DKIM-Signature:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=Nr6GMsDHjyrzOmjN42gTc9NFCh2GH0rS8Ih8AKByliMj/djgOHq7cvS17bBvb7d+40HBe18wW9JW4Vz2FdsER525U+DWXYK8LjgQi76VKyZOgSqljIibAlOVPwJ4qDO90Q33dB/dRmCSMfML4d+/xvK7CjTme+noUHTE7ZdFusk= ; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.fr; s=s1024; t=1339631922; bh=A1cjCqME9h9ifiYY1t/7znC3LO1wk7WYq10N/oAA13I=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:References:In-Reply-To:Mime-Version:Content-Transfer-Encoding:Content-Type:Message-Id:Cc:X-Mailer:From:Subject:Date:To; b=IlUvBS9QHazbGTR3o1W8enilkGGThPliF2+NIZA9bsnXnrJ/BJn41Y5Jd3VwxhWiaZf0aEKM9dG6P+RBk0IGWIxIDxlU6aIlYrHBgMipRLpWMomV8Y8X9WUlPWoQ2wLDugoup5ZgDAEby2bRyQ3wLgWQzGjq/B40lCYeyifIPMo= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Rbr7BocVM1kereo3K.RK.Xso2GN3LAMENb5pSZI02oIwa9a bptLvUVvQ0Q61bjZjbH7Qcz730p.GzcI20TtIQRnGNwiX01dN0L7KSy34z1z FVOCn7w3jjC4yrd9LLaeYBBmjCzEHhFF7HilXW2BONlQZqNoqB8megMjvvzc HllA3PEd.ojXWrL0Y8blgJc8UTGaWnxHaSlJAiVnoGEbIxNaqBmKuC6ni5dK tKcRYa3GxT1KssRe2VOYabmP.Jis3xl8fEJwDktlmNV5tljI3CddEJnTxbXW v6mqLROZWaGSD09.lJqOx8SOX8olpGeFeLJyYEmqrLd9nz6_LGUryK4myxgG mHx9KGF26ir7RimNx0CTnY_ltMNDbabA9t7HUICpTCTBUejUc9zp0DWZ7GuP CYbKlfwssGkeuRVPj8EXsO5mp6vPC7_1vr_juoumSdA3iINrQNQ-- X-Yahoo-SMTP: 4yMEliGswBAasvpyZFHmebLo1Uyca4YzEGiW Received: from [10.211.10.141] (pthubert_cisco@63.231.216.50 with xymcookie) by smtp108-mob.biz.mail.gq1.yahoo.com with SMTP; 13 Jun 2012 16:58:41 -0700 PDT References: <18113.1339529290@marajade.sandelman.ca> In-Reply-To: <18113.1339529290@marajade.sandelman.ca> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Message-Id: X-Mailer: iPhone Mail (9B208) From: Pascal Thubert Date: Wed, 13 Jun 2012 16:55:00 -0700 To: Michael Richardson Cc: "roll@ietf.org" , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [Roll] draft-bormann-ghc 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 Jun 2012 23:58:47 -0000 +1 Pascal Le 12 juin 2012 =C3=A0 12:28, Michael Richardson a =C3= =A9crit : >=20 > I would like to propose that draft-bormann-6lowpan-ghc-04 be adopted as > a WG item. I think that 6lowpan should adopt it, but I'm willing to > discuss alternatives. >=20 > Some analysis in 2011 showed that even a modest application of GHC > to ROLL RPL control messages resulted in sufficient compression to > make ROLL RPL packets regularly fit into a single 802.15.4 payload. >=20 > --=20 > Michael Richardson , Sandelman Software Works=20 > speaking for myself >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Laurent.Toutain@telecom-bretagne.eu Thu Jun 14 00:31:35 2012 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 D440F21F8421; Thu, 14 Jun 2012 00:31:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.742 X-Spam-Level: X-Spam-Status: No, score=-1.742 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_FR=0.35, HTML_FONT_FACE_BAD=0.884, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W36gL6BeqM25; Thu, 14 Jun 2012 00:31:35 -0700 (PDT) Received: from coliposte.enst-bretagne.fr (coliposte.enst-bretagne.fr [192.108.115.12]) by ietfa.amsl.com (Postfix) with ESMTP id 9338621F8643; Thu, 14 Jun 2012 00:31:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id q5E7VVmY025726; Thu, 14 Jun 2012 09:31:31 +0200 Received: from courrier.enst-bretagne.fr (vss-mail-02.priv.enst-bretagne.fr [10.29.90.4]) by coliposte.enst-bretagne.fr (8.13.7/8.13.7/2009.11.10) with ESMTP id q5E7VRM3025712; Thu, 14 Jun 2012 09:31:30 +0200 Received: from mail-wg0-f44.google.com (passerelle-interne.enst-bretagne.fr [192.108.117.210]) (user=toutain mech=PLAIN bits=0) by courrier.enst-bretagne.fr (8.13.8/8.13.8/2010.02.22) with ESMTP id q5E7VOk6020037; Thu, 14 Jun 2012 09:31:24 +0200 Received: by wgbdr13 with SMTP id dr13so979126wgb.13 for ; Thu, 14 Jun 2012 00:31:24 -0700 (PDT) Received: by 10.216.209.95 with SMTP id r73mr432961weo.157.1339659084411; Thu, 14 Jun 2012 00:31:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.156.81 with HTTP; Thu, 14 Jun 2012 00:31:03 -0700 (PDT) In-Reply-To: References: <18113.1339529290@marajade.sandelman.ca> From: Laurent Toutain Date: Thu, 14 Jun 2012 09:31:03 +0200 Message-ID: To: Pascal Thubert Content-Type: multipart/alternative; boundary=0016e6db2371d8b24904c269af3e X-Virus-Scanned: amavisd-new at enst-bretagne.fr Cc: "roll@ietf.org" , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [Roll] draft-bormann-ghc 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 Jun 2012 07:31:36 -0000 --0016e6db2371d8b24904c269af3e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1, but I thought the 6LP working group was closed ! Laurent On Thu, Jun 14, 2012 at 1:55 AM, Pascal Thubert wr= ote: > +1 > > Pascal > > Le 12 juin 2012 =E0 12:28, Michael Richardson a > =E9crit : > > > > > I would like to propose that draft-bormann-6lowpan-ghc-04 be adopted as > > a WG item. I think that 6lowpan should adopt it, but I'm willing to > > discuss alternatives. > > > > Some analysis in 2011 showed that even a modest application of GHC > > to ROLL RPL control messages resulted in sufficient compression to > > make ROLL RPL packets regularly fit into a single 802.15.4 payload. > > > > -- > > Michael Richardson , Sandelman Software Works > > speaking for myself > > > > _______________________________________________ > > 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 Laurent Toutain +--- VoIP (recommended) ---+----------- T=E9l=E9com Bretagne -----------+ | Tel: +33 2 22 06 8156 | Tel: + 33 2 99 12 7026 | Visit : | Fax: +33 2 22 06 8445 | Fax: +33 2 99 12 7030 | http://class.touta.in | Laurent@Touta.in | Laurent.Toutain@Telecom-Bretagne.eu | +--------------------------+----------------------------------------+ --0016e6db2371d8b24904c269af3e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1, but I thought the 6LP working group was closed !

Lau= rent

On Thu, Jun 14, 2012 at 1:55 AM, Pas= cal Thubert <pthubert_cisco@yahoo.fr> wrote:
+1

Pascal

Le 12 juin 2012 =E0 12:28, Michael Richardson <mcr+ietf@sandelman.ca> a =E9crit :

>
> I would like to propose that draft-bormann-6lowpan-ghc-04 be adopted a= s
> a WG item. =A0I think that 6lowpan should adopt it, but I'm willin= g to
> discuss alternatives.
>
> Some analysis in 2011 showed that even a modest application of GHC
> to ROLL RPL control messages resulted in sufficient compression to
> make ROLL RPL packets regularly fit into a single 802.15.4 payload. >
> --
> Michael Richardson <mcr+= IETF@sandelman.ca>, Sandelman Software Works
> speaking for myself
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll



--
Laurent Tout= ain
+--- VoIP (recommend= ed) ---+----------- T=E9l=E9com Bretagne -----------+
| Tel: +33 2 22 06= 8156 =A0 =A0| Tel: + 33 2 99 12 7026 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | Vis= it :
| Fax: +33 2 22 06 8445 =A0 =A0| Fax: +33 2 99 12 7030 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0| =A0htt= p://class.touta.in
| Laurent@Touta.in =A0 =A0 =A0 =A0 | Laurent.Tout= ain@Telecom-Bretagne.eu =A0 =A0|
+--------------------------+----------------------------------------+
--0016e6db2371d8b24904c269af3e-- From c.chauvenet@watteco.com Thu Jun 14 02:54:42 2012 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 40BB721F865F; Thu, 14 Jun 2012 02:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4oPGleqS4WGF; Thu, 14 Jun 2012 02:54:41 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 2ED6B21F8663; Thu, 14 Jun 2012 02:54:40 -0700 (PDT) Received: from mail79-ch1-R.bigfish.com (10.43.68.248) by CH1EHSOBE005.bigfish.com (10.43.70.55) with Microsoft SMTP Server id 14.1.225.23; Thu, 14 Jun 2012 09:53:33 +0000 Received: from mail79-ch1 (localhost [127.0.0.1]) by mail79-ch1-R.bigfish.com (Postfix) with ESMTP id DF206340381; Thu, 14 Jun 2012 09:53:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zzc89bh1432I1418Izz1202hzz1033IL8275dhz2dh2a8h668h839hd25he5bhf0ah) Received: from mail79-ch1 (localhost.localdomain [127.0.0.1]) by mail79-ch1 (MessageSwitch) id 133966761195116_19736; Thu, 14 Jun 2012 09:53:31 +0000 (UTC) Received: from CH1EHSMHS002.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.235]) by mail79-ch1.bigfish.com (Postfix) with ESMTP id 1518548004B; Thu, 14 Jun 2012 09:53:31 +0000 (UTC) Received: from DBXPRD0510HT001.eurprd05.prod.outlook.com (157.56.252.165) by CH1EHSMHS002.bigfish.com (10.43.70.2) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 14 Jun 2012 09:53:31 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.190]) by DBXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.67.164]) with mapi id 14.16.0164.004; Thu, 14 Jun 2012 09:54:26 +0000 From: C Chauvenet To: Michael Richardson Thread-Topic: [6lowpan] draft-bormann-ghc Thread-Index: AQHNSNGKk5/9ArAtu0iqaj4aC4qUwJb5lbKA Date: Thu, 14 Jun 2012 09:54:26 +0000 Message-ID: <3BCA1630-9983-4068-BEC8-3F8D979AD1CD@watteco.com> References: <18113.1339529290@marajade.sandelman.ca> In-Reply-To: <18113.1339529290@marajade.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.4.10] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2D4FBC1A33AC444CA5D84A7F1EEF67EA@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "" , "<6lowpan@ietf.org>" <6lowpan@ietf.org> Subject: Re: [Roll] [6lowpan] draft-bormann-ghc 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 Jun 2012 09:54:42 -0000 +1 to adopt this doc as a WG item. Saving bytes is the key.=20 Go for it ! Le 12 juin 2012 =E0 21:28, Michael Richardson a =E9crit : >=20 > I would like to propose that draft-bormann-6lowpan-ghc-04 be adopted as > a WG item. I think that 6lowpan should adopt it, but I'm willing to > discuss alternatives. >=20 > Some analysis in 2011 showed that even a modest application of GHC > to ROLL RPL control messages resulted in sufficient compression to > make ROLL RPL packets regularly fit into a single 802.15.4 payload. >=20 > --=20 > Michael Richardson , Sandelman Software Works=20 > speaking for myself >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Thu Jun 14 03:19:24 2012 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 E674D21F86C2; Thu, 14 Jun 2012 03:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.149 X-Spam-Level: X-Spam-Status: No, score=-107.149 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwYLlgj7zRn9; Thu, 14 Jun 2012 03:19:24 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA6721F86C1; Thu, 14 Jun 2012 03:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q5EAJFsu026400; Thu, 14 Jun 2012 12:19:15 +0200 (CEST) Received: from [192.168.217.105] (p54899DA7.dip.t-dialin.net [84.137.157.167]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id C30F0FA1; Thu, 14 Jun 2012 12:19:14 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Thu, 14 Jun 2012 12:19:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <87AC724B-DC1F-41C2-9F1F-4357FA7B45A3@tzi.org> References: <18113.1339529290@marajade.sandelman.ca> To: Laurent Toutain X-Mailer: Apple Mail (2.1278) Cc: roll WG , 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] draft-bormann-ghc 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 Jun 2012 10:19:25 -0000 On Jun 14, 2012, at 09:31, Laurent Toutain wrote: > but I thought the 6LP working group was closed ...>>>>>... Changing to WG chair mode for a moment: The 6LoWPAN WG is alive and well and is in the process of closing its = remaining two work items (6LoWPAN-ND, 6LoWPAN for BTLE). However, you are right in that the 6LoWPAN WG no longer takes new work = on. The chairs, with the ADs and the chairs of other WGs, will ensure that = interesting work finds an appropriate home. Indicating whether you are interested in GHC is therefore important = input. Another comment: Beyond the +1s, it would be useful to know, whether you (I'm addressing = the WG here) would be interested in -- reviewing versions of the draft as they progress -- implementing the draft and relaying feedback. ...<<<<<... I'm back to personal contributor mode now. (Luckily, we won't have this hat-changing going on any more when we find = the new home.) I'm just in the process of receiving some more packet captures. I would like to take this opportunity to remind people that the more = packet captures we have to look at, the better we will be able to = optimize this scheme before nailing it down. A collection of packets I looked at is in http://svn.tools.ietf.org/svn/wg/6lowpan/packets (and, of course, there is the discussion of these in the draft itself). Gr=FC=DFe, Carsten From abdussalambaryun@gmail.com Thu Jun 14 04:40:32 2012 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 3F2A021F86A8 for ; Thu, 14 Jun 2012 04:40:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUYS5OiXPik4 for ; Thu, 14 Jun 2012 04:40:31 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A717521F868A for ; Thu, 14 Jun 2012 04:40:31 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1130910vbb.31 for ; Thu, 14 Jun 2012 04:40:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=is2qBNCUZoA13NW9jJEbxzbsZAelZjux10//n/ecDdc=; b=v88eCuvlZQvCLwYm6IsMy2/T4idp6ITkzpmf4XT0DhI1eukvxjDXO7GykUglioQbX+ GH+BNDK3kTJ4695docQg4vqTk13Rh7W19iDvkoNG30w/4gvEFl4Q7hV7kCYwVcJY6pl7 Ft+z43Kgihmm0HIBROTt8GygOcFAauL03xaV12RG9zcL7vK4pnBPhtn97zTefuaEDbjp rNcOgqyxpXzVPNusVqPeR3pXsSsAnapGEhlVIyKaTg43l3E3hWDvhCfTcEkF/J3L8Gcd 5zpvBMHZtooZUAp7MBlTfvOLtaCPwvshprRVCHvXC2ynfIOiKO6tMxwMpWgniQsv2Hu9 l2Cw== MIME-Version: 1.0 Received: by 10.52.24.179 with SMTP id v19mr707806vdf.127.1339674031074; Thu, 14 Jun 2012 04:40:31 -0700 (PDT) Received: by 10.220.211.72 with HTTP; Thu, 14 Jun 2012 04:40:31 -0700 (PDT) In-Reply-To: References: Date: Thu, 14 Jun 2012 12:40:31 +0100 Message-ID: From: Abdussalam Baryun To: JP Vasseur Content-Type: multipart/alternative; boundary=bcaec5015e7bbcaf5504c26d2ac1 Cc: roll Subject: Re: [Roll] draft-ietf-roll-terminology-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 11:40:32 -0000 --bcaec5015e7bbcaf5504c26d2ac1 Content-Type: text/plain; charset=ISO-8859-1 Hi Vasseur, could we activate it and forward it for WGLC, AB On Sun, Jun 3, 2012 at 10:50 AM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Vasseur, > > I want to ask about the draft of ROLL terminology, when will it be > re-activated? because expired, and if it is completed should we make > it go forward, or is it better to wait for other drafts to come in, > not sure, please advise, thanking you, > > Abdussalam Baryun, > University of Glamorgan, UK > --bcaec5015e7bbcaf5504c26d2ac1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Vasseur,
=A0
could we activate it and forward i= t for WGLC,
=A0
AB

On Sun, Jun 3, 2012 at 10:50 AM, Abdussalam Baryun &l= t;abdussala= mbaryun@gmail.com> wrote:
Hi Vasseur,

I want to ask about the draft of ROLL terminology, when will it be
re-activated? because expired, and if it is completed should we make
it go forward, or is it better to wait for other drafts to come in,
not sure, please advise, thanking you,

Abdussalam Baryun,
University of Glamorgan, UK

--bcaec5015e7bbcaf5504c26d2ac1-- From mcr@sandelman.ca Thu Jun 14 06:43:17 2012 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 278FD21F86AF; Thu, 14 Jun 2012 06:43:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.135 X-Spam-Level: X-Spam-Status: No, score=-1.135 tagged_above=-999 required=5 tests=[AWL=0.819, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnweJEDq55DT; Thu, 14 Jun 2012 06:43:16 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9459921F86AD; Thu, 14 Jun 2012 06:43:15 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 72A7282DC; Thu, 14 Jun 2012 09:40:48 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id D6C5098C2E; Thu, 14 Jun 2012 09:43:13 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D250898C2D; Thu, 14 Jun 2012 09:43:13 -0400 (EDT) From: Michael Richardson To: Laurent Toutain In-Reply-To: References: <18113.1339529290@marajade.sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 14 Jun 2012 09:43:13 -0400 Message-ID: <593.1339681393@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: "roll@ietf.org" , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [Roll] [6lowpan] draft-bormann-ghc 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 Jun 2012 13:43:17 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Laurent" =3D=3D Laurent Toutain writes: Laurent> +1, but I thought the 6LP working group was closed ! >> adopted as a WG item. I think that 6lowpan should adopt it, >> but I'm willing to discuss alternatives. Thus my statement including: "discuss alternatives" this includes going to 6man or roll or independant submission. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT9nqcYqHRg3pndX9AQIF4wP+JNTEvBhp1iKaH1Ays5FKCcHZOMFOcp1X oVTrqb5ix6pc9/0RuZWA4tAWy7rJjjwwOOsAmaEMd01sWC9YuT2zfl+O/JmFnybe Dn7qrqJnF6eNSwqp7y8P5YLyDGVRKIOZjnNYnXl9aGx++zWzQ6UyqzUbZ/8d2L5Q 4AxArNaCxpg= =6o0a -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Jun 14 13:13:23 2012 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 7786B21F858D; Thu, 14 Jun 2012 13:13:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.252 X-Spam-Level: X-Spam-Status: No, score=-1.252 tagged_above=-999 required=5 tests=[AWL=0.702, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHLK51Iqas4d; Thu, 14 Jun 2012 13:13:22 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 90B4B21F8567; Thu, 14 Jun 2012 13:13:22 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id EB8448297; Thu, 14 Jun 2012 16:10:53 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 1EC8F98C2E; Thu, 14 Jun 2012 16:13:20 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 19BC598C2D; Thu, 14 Jun 2012 16:13:20 -0400 (EDT) From: Michael Richardson To: 6lowpan@ietf.org, roll@ietf.org, richard.kelsey@ember.com, ipv6@ietf.org X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 14 Jun 2012 16:13:20 -0400 Message-ID: <6808.1339704800@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2012 20:13:23 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable In draft-kelsey-intarea-mesh-link-establishment-03.txt it says that=20 MLE messages are sent using UDP. I want to suggest that MLE messages should be sent at least as IPv6 ICMP messages.=20=20 Further, I think that it could use the RPL type 155, and RPL would allocate a new "code" codepoint. There would be some preference to have the general structure of MLE match that of RPL, but I think that this isn't particularly a strong requirement. Allocating a new ICMP type code for MLE alone might be seen as excessive, but I can not speak for the folks in 6man. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT9pF34qHRg3pndX9AQJPIAP+N8iVtsvMdZ5Puona18HH5pm1bFSiDpV8 PtcYZ4/boPM1EoS+bluWA13oEoHyGY+jQJ/Za5Ta/Yh31L82VF0QMoozPAhOwwSH 9Ow6Kuf/CL+JQbUXRprSl9CYgbe2fa0OHlvb8pcMZd/ETzeUgwLtREjhEZZRangy NynhubUyQN8= =qj/y -----END PGP SIGNATURE----- --=-=-=-- From d.sturek@att.net Fri Jun 15 02:25:49 2012 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 C7A4021F85CD for ; Fri, 15 Jun 2012 02:25:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.53 X-Spam-Level: X-Spam-Status: No, score=-1.53 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gHwpIoNgZHT for ; Fri, 15 Jun 2012 02:25:49 -0700 (PDT) Received: from nm18.access.bullet.mail.sp2.yahoo.com (nm18.access.bullet.mail.sp2.yahoo.com [98.139.44.145]) by ietfa.amsl.com (Postfix) with SMTP id 6DEF321F85CC for ; Fri, 15 Jun 2012 02:25:49 -0700 (PDT) Received: from [98.139.44.105] by nm18.access.bullet.mail.sp2.yahoo.com with NNFMP; 15 Jun 2012 09:25:49 -0000 Received: from [98.139.44.91] by tm10.access.bullet.mail.sp2.yahoo.com with NNFMP; 15 Jun 2012 09:25:49 -0000 Received: from [127.0.0.1] by omp1028.access.mail.sp2.yahoo.com with NNFMP; 15 Jun 2012 09:25:49 -0000 X-Yahoo-Newman-Id: 32696.20400.bm@omp1028.access.mail.sp2.yahoo.com Received: (qmail 83612 invoked from network); 15 Jun 2012 09:25:48 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1339752348; bh=N2HYMj3YUpjfA+ecBMkLAgQGOaAXBqI86DSSaK7wnvI=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=jN+BYYU1pE2I/c0/Xd8l+BnsiTwp/gGFOsub6RNAmb2YA94qb5DebhAKR61YoDFFhn+HYVFs1z7ErOerkOR4Js2xrXANoI2z1EXRZ1xAC7Byr4x/unW19BX5qGEcp/JORDmRSmPDXrGJvosqfpNP3LwxZ6A8/0fkiMycZQQ4ujc= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: _tsrMlMVM1lC3BKXcycyN8Pqz7q7tjoipyFRsv.Vg8F8n2R 86zKH3VoHLIBwcxlAVkGqHLLfvqJHmrrr5cNWpJ1ECHKPmsG9Opf_Xj2gw4b U6Y7tFQ8DRfNsiXUNHNq5zpaWWDfCnoALLfnGsdoBET3c4z5jIiIRKRyp5FE FYwIVeiE7yXI4RAZ9ATQttZ5_9iaeZ8IXeby9WHOcIWWJayIycoFgU6QPLzL O5IsNx2l9SVWl4GMBwVFN0faNc5gYY692ioEUc.74OzMG1MytdMWnR_D4xFb mLqS5c_Znuu6LqhsqA2S6FfMXHE27_Qdu8vwFjdN8mdaX5yw7C56i6qbDK.q UHZNsOTY5YnvOD5ARAzN_qgKL6CxmIIG8_lt6NSOfYcaIwqCorHJw43nBgx8 JgXR2Gzxf80_hJiQSVOMxMq7AwAkbdPETGdy9 X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.205.138.57] (d.sturek@209.226.201.250 with login) by smtp111.sbc.mail.ne1.yahoo.com with SMTP; 15 Jun 2012 02:25:48 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Thu, 14 Jun 2012 16:43:36 -0700 From: Don Sturek To: Michael Richardson , <6lowpan@ietf.org>, , , Message-ID: Thread-Topic: [Roll] draft-kelsey-intarea-mesh-link-establishment-03.txt In-Reply-To: <6808.1339704800@marajade.sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [Roll] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 09:25:50 -0000 All sounds fantastic but we don't have time for all these changes so will opt to use MLE as written using UDP ( at least for our application....) Don On 6/14/12 1:13 PM, "Michael Richardson" wrote: > >In draft-kelsey-intarea-mesh-link-establishment-03.txt it says that > MLE messages are sent using UDP. > >I want to suggest that MLE messages should be sent at least as IPv6 >ICMP messages. > >Further, I think that it could use the RPL type 155, and RPL would >allocate a new "code" codepoint. > >There would be some preference to have the general structure of MLE >match that of RPL, but I think that this isn't particularly a strong >requirement. Allocating a new ICMP type code for MLE alone might be >seen as excessive, but I can not speak for the folks in 6man. > >-- >Michael Richardson , Sandelman Software Works >IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From ietf@thomasclausen.org Fri Jun 15 03:32:16 2012 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 07C4C21F85B6; Fri, 15 Jun 2012 03:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcy4d7nMMngf; Fri, 15 Jun 2012 03:32:15 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD6321F85A1; Fri, 15 Jun 2012 03:32:15 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id EE407557F4B; Fri, 15 Jun 2012 03:32:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 692A31C0864; Fri, 15 Jun 2012 03:32:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.129.61.101] (37-8-178-84.coucou-networks.fr [37.8.178.84]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id AFBB51C07CC; Fri, 15 Jun 2012 03:32:13 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <2E20BD63-02D7-4275-A3C1-2E070D9BB90E@thomasclausen.org> X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Fri, 15 Jun 2012 12:32:17 +0200 To: Don Sturek Cc: "" , "<6lowpan@ietf.org>" <6lowpan@ietf.org>, "" Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 10:32:16 -0000 Not sure how fantastic (or not) it is - it is not immediately clear to me ho= w tied MLE should be to RPL - if it truly aims at being for _MESH_ link esta= blishment, then it would appear to be a much larger scope, and should not be= tied narrowly to a special-purpose protocol's type-space (& conventions etc= ., that do not apply universally). I guess I'm expressing some sort of support for Don's position... --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees On 15 Jun 2012, at 01:43, Don Sturek wrote: > All sounds fantastic but we don't have time for all these changes so will > opt to use MLE as written using UDP ( at least for our application....) >=20 > Don >=20 >=20 >=20 > On 6/14/12 1:13 PM, "Michael Richardson" wrote: >=20 >>=20 >> In draft-kelsey-intarea-mesh-link-establishment-03.txt it says that >> MLE messages are sent using UDP. >>=20 >> I want to suggest that MLE messages should be sent at least as IPv6 >> ICMP messages. =20 >>=20 >> Further, I think that it could use the RPL type 155, and RPL would >> allocate a new "code" codepoint. >>=20 >> There would be some preference to have the general structure of MLE >> match that of RPL, but I think that this isn't particularly a strong >> requirement. Allocating a new ICMP type code for MLE alone might be >> seen as excessive, but I can not speak for the folks in 6man. >>=20 >> --=20 >> Michael Richardson , Sandelman Software Works >> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 >=20 > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan From cabo@tzi.org Fri Jun 15 03:43:55 2012 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 65B5921F85C5; Fri, 15 Jun 2012 03:43:55 -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_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qPYTZ9iFwAI; Fri, 15 Jun 2012 03:43:54 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 72EFA21F85C0; Fri, 15 Jun 2012 03:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q5FAhcsM014957; Fri, 15 Jun 2012 12:43:38 +0200 (CEST) Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CA0625A8; Fri, 15 Jun 2012 12:43:38 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Fri, 15 Jun 2012 12:43:38 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2D207A78-AD9A-47B6-AD51-9108CEA7D502@tzi.org> References: To: Don Sturek X-Mailer: Apple Mail (2.1278) Cc: roll@ietf.org, 6lowpan@ietf.org, ipv6@ietf.org Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 10:43:55 -0000 > we don't have time for all these changes It's likely that the next question that will come up is: Should this be published as an informational RFC called "ZigBee's MLE = protocol" because the protocol is no longer really meant to be modified = in the process or should it be pursued as a standards track document? (Don't get me wrong, I'm all for stability of protocols when there is = running code. Stability against gratuitous change and Brownian motion, that is. =20 But not when there are good technical reasons to have the change. We should be having the discussion on whether that's the case, I think. And how the encapsulation of MLE works in the first place, something I = don't understand yet.) Gr=FC=DFe, Carsten From mcr@sandelman.ca Fri Jun 15 06:12:18 2012 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 55AE621F845F; Fri, 15 Jun 2012 06:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.339 X-Spam-Level: X-Spam-Status: No, score=-1.339 tagged_above=-999 required=5 tests=[AWL=0.615, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mxxLy26f+Toy; Fri, 15 Jun 2012 06:12:17 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4E621F86CB; Fri, 15 Jun 2012 06:12:15 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 5C8C78549; Fri, 15 Jun 2012 09:09:45 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 94F7C98C2E; Fri, 15 Jun 2012 09:12:13 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8E46198C2D; Fri, 15 Jun 2012 09:12:13 -0400 (EDT) From: Michael Richardson To: Thomas Heide Clausen In-Reply-To: <2E20BD63-02D7-4275-A3C1-2E070D9BB90E@thomasclausen.org> References: <2E20BD63-02D7-4275-A3C1-2E070D9BB90E@thomasclausen.org> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 15 Jun 2012 09:12:13 -0400 Message-ID: <16656.1339765933@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: "" , "" , "<6lowpan@ietf.org>" <6lowpan@ietf.org> Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 13:12:19 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Thomas" =3D=3D Thomas Heide Clausen writes: Thomas> Not sure how fantastic (or not) it is - it is not Thomas> immediately clear to me how tied MLE should be to RPL - if Thomas> it truly aims at being for _MESH_ link establishment, then Thomas> it would appear to be a much larger scope, and should not be Thomas> tied narrowly to a special-purpose protocol's type-space (& Thomas> conventions etc., that do not apply universally).=20 Thomas, you will note that: 1) I suggested it go under IPv6 ICMP first, and if there was such push back about allocating a new type, that RPL could allocate a type/code. 2) ZigBee alliance (the proposal), *IS* using RPL. I see running it over UDP very architecturally strange. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT9s0rYqHRg3pndX9AQKLCgP/eg+mGX3tdePewosTFvFyyNiBj+hZ7ULk KTiyNFhTpjTKwZIV5y3eVOv/SmFCqSgFDckZtBrLW7m3DylwxnTAXTkXkmmmuIeO 9zYbK+FUC+BomKS25Tm6uIkSAl84GLn2KT3x/hKIBvmLxZx9rBkP5Y35QiMQHQKJ mzp8qMaC+aw= =Y5fM -----END PGP SIGNATURE----- --=-=-=-- From ietf@thomasclausen.org Fri Jun 15 06:15:36 2012 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 20AA021F86D9; Fri, 15 Jun 2012 06:15:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TVQ5SjMiDjpx; Fri, 15 Jun 2012 06:15:35 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id ABDFC21F86CE; Fri, 15 Jun 2012 06:15:35 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 4C718557FB1; Fri, 15 Jun 2012 06:15:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id AA9F41BCC2A8; Fri, 15 Jun 2012 06:15:34 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [192.168.147.115] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 27DBB1BCC2A5; Fri, 15 Jun 2012 06:15:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Thomas Heide Clausen In-Reply-To: <16656.1339765933@marajade.sandelman.ca> Date: Fri, 15 Jun 2012 15:15:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6FE0075D-CB42-4FE1-A5D2-20330917542C@thomasclausen.org> References: <2E20BD63-02D7-4275-A3C1-2E070D9BB90E@thomasclausen.org> <16656.1339765933@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1257) Cc: "" , "" , "<6lowpan@ietf.org>" <6lowpan@ietf.org> Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 13:15:36 -0000 On Jun 15, 2012, at 15:12 , Michael Richardson wrote: >=20 >>>>>> "Thomas" =3D=3D Thomas Heide Clausen = writes: > Thomas> Not sure how fantastic (or not) it is - it is not > Thomas> immediately clear to me how tied MLE should be to RPL - if > Thomas> it truly aims at being for _MESH_ link establishment, then > Thomas> it would appear to be a much larger scope, and should not = be > Thomas> tied narrowly to a special-purpose protocol's type-space (& > Thomas> conventions etc., that do not apply universally).=20 >=20 > Thomas, you will note that: > 1) I suggested it go under IPv6 ICMP first, and if there was such = push > back about allocating a new type, that RPL could allocate a = type/code. > 2) ZigBee alliance (the proposal), *IS* using RPL. >=20 In that case, the draft must be very narrowly scoped and written such = that it's clear that it's applicable _only_ to that context = (special-purpose deployments of a special-purpose protocol), and = specifically to not pretend to do general mesh link establishment. > I see running it over UDP very architecturally strange. I don't. Thomas > --=20 > Michael Richardson , Sandelman Software Works=20= > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >=20 From d.sturek@att.net Fri Jun 15 06:57:48 2012 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 0C7E521F8769 for ; Fri, 15 Jun 2012 06:57:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yB7X0vPsGBM for ; Fri, 15 Jun 2012 06:57:47 -0700 (PDT) Received: from nm26-vm0.bullet.mail.sp2.yahoo.com (nm26-vm0.bullet.mail.sp2.yahoo.com [98.139.91.230]) by ietfa.amsl.com (Postfix) with SMTP id 7428021F86D9 for ; Fri, 15 Jun 2012 06:57:47 -0700 (PDT) Received: from [98.139.91.69] by nm26.bullet.mail.sp2.yahoo.com with NNFMP; 15 Jun 2012 13:57:47 -0000 Received: from [68.142.200.226] by tm9.bullet.mail.sp2.yahoo.com with NNFMP; 15 Jun 2012 13:57:47 -0000 Received: from [66.94.237.105] by t7.bullet.mud.yahoo.com with NNFMP; 15 Jun 2012 13:57:47 -0000 Received: from [127.0.0.1] by omp1010.access.mail.mud.yahoo.com with NNFMP; 15 Jun 2012 13:57:47 -0000 X-Yahoo-Newman-Id: 216595.489.bm@omp1010.access.mail.mud.yahoo.com Received: (qmail 16548 invoked from network); 15 Jun 2012 13:57:47 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1339768667; bh=wYKSezaP4Owb5+5j2ofTKxL2UEB4+zSNMIZ5r65CuhE=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=fRrpdSNPPv9K2/VQiqD1kb+G2WbDRJd6NYKgWuYdhox2sFrXgk9EkGvpgagnYBWWLSAGPKA/ZFAx0Hgkc9WQ/JI2MmzdQ4LyPMt7WJTckueR57ZQhhGi7/ce/SHffMPW5Zvi/3h0KpbL87D1b0vb0johN0WrmmtnU5Hfmm73T8E= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: RxQRipwVM1kxRBn.4uTZe_0F5knr8G.DTwTa4woPQIlWhov wbIw_IPP4E7YSZw3a54oDFfoRBMkqpMTrNSImas3_zewP7_6dTlpm8RgqiX1 fFbfkxU6oHcDCi4MFLWLhOjvGHHNvTocmvFK5KJ2BT9kkiCmEOx4nR2UNBBB NXF05x97fjACXWGpyzFfjqVxvyuNhyJOndj0pwuqI9BHuxNsBA0Eb5rePBCn sg_hQmQrn10grtugdKXXfhtPcss7SNh73nAIpH6kbxBBtn1ZrnTGgan.CNwT cgY.LEWCImO3yU29jnx71Gdi6EJOpMeOa7y3YJUdlKbqfpTcUiQyjVYpkx8g fooJp7F5VZ_nuqW6Oc0oxTOOQmCyW1xW_2mxHlDYvX8Iow18PSTCMXAggnjA Oqqf68EexKSet2zPuaFwDL9cGM7iKduLcpQr0yPKgRbcYYry.nSR2L957GbH b00AV4fyISN1Exg29RWc5M2Wfh3juRR_nfdvSi0v7aXeceuWvPDelfbMjKNE - X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.242.10.56] (d.sturek@208.54.15.109 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 15 Jun 2012 06:57:46 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Fri, 15 Jun 2012 06:57:38 -0700 From: Don Sturek To: Thomas Heide Clausen , Michael Richardson Message-ID: Thread-Topic: [6lowpan] [Roll] draft-kelsey-intarea-mesh-link-establishment-03.txt In-Reply-To: <6FE0075D-CB42-4FE1-A5D2-20330917542C@thomasclausen.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "" , "<6lowpan@ietf.org>" <6lowpan@ietf.org>, "" Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 13:57:48 -0000 Hi Thomas (and Michael), I don't agree that MLE targets only RPL. The draft was written carefully to avoid having a narrow focus around RPL. That said, the deployment we are using this draft for uses 6LoWPAN, 6LoWPAN ND, ROLL RPL (non-storing) and I think many others will find the information exchanged between neighbors using MLE as useful. Don On 6/15/12 6:15 AM, "Thomas Heide Clausen" wrote: > >On Jun 15, 2012, at 15:12 , Michael Richardson wrote: > >> >>>>>>> "Thomas" == Thomas Heide Clausen writes: >> Thomas> Not sure how fantastic (or not) it is - it is not >> Thomas> immediately clear to me how tied MLE should be to RPL - if >> Thomas> it truly aims at being for _MESH_ link establishment, then >> Thomas> it would appear to be a much larger scope, and should not be >> Thomas> tied narrowly to a special-purpose protocol's type-space (& >> Thomas> conventions etc., that do not apply universally). >> >> Thomas, you will note that: >> 1) I suggested it go under IPv6 ICMP first, and if there was such push >> back about allocating a new type, that RPL could allocate a >>type/code. >> 2) ZigBee alliance (the proposal), *IS* using RPL. >> > >In that case, the draft must be very narrowly scoped and written such >that it's clear that it's applicable _only_ to that context >(special-purpose deployments of a special-purpose protocol), and >specifically to not pretend to do general mesh link establishment. > >> I see running it over UDP very architecturally strange. > >I don't. > >Thomas > >> -- >> Michael Richardson , Sandelman Software Works >> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >> > From d.sturek@att.net Fri Jun 15 07:00:17 2012 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 6CA8F21F8789 for ; Fri, 15 Jun 2012 07:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.5 X-Spam-Level: X-Spam-Status: No, score=-2.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnOh-nBPFYJ9 for ; Fri, 15 Jun 2012 07:00:17 -0700 (PDT) Received: from nm35-vm6.bullet.mail.ne1.yahoo.com (nm35-vm6.bullet.mail.ne1.yahoo.com [98.138.229.102]) by ietfa.amsl.com (Postfix) with SMTP id 485CC21F878B for ; Fri, 15 Jun 2012 07:00:16 -0700 (PDT) Received: from [98.138.226.177] by nm35.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jun 2012 14:00:13 -0000 Received: from [209.191.108.97] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jun 2012 14:00:13 -0000 Received: from [66.94.237.101] by t4.bullet.mud.yahoo.com with NNFMP; 15 Jun 2012 14:00:13 -0000 Received: from [127.0.0.1] by omp1006.access.mail.mud.yahoo.com with NNFMP; 15 Jun 2012 14:00:13 -0000 X-Yahoo-Newman-Id: 69530.17866.bm@omp1006.access.mail.mud.yahoo.com Received: (qmail 58417 invoked from network); 15 Jun 2012 14:00:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1339768813; bh=AFDdcLshwegeGdJ3PyFMNWUiQr8maS3RpLbyUe1Hxfs=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=bqWBUdoA/7r1/6mRwwox21jJbe5ohQAL6vEgb/tYex4pz9jRpUgGu5S8GekLP6VuklHq4chDtzVGK0lobz0j4b5r0SOEYX1CnpfS4Dc3BTrBxzU1H4i+Hzk/y8MSud46lrDLY3vdHlL/4FnJYzHyDCJK2REbT8dkZSCrH+wz+S8= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: qqtsPxcVM1lDeQVimWV_0ENh76.4ITpbVxHCpltrAXNSMhj 3MVm9bUfKPcy0aEt2J_XFOR72TFTucbeb1Gj6gOdLKzhlx6RVV8LsEzKhzm3 RuU60xFOOCRTRHlZvp9mzSZ1vRcvCKe7lwgeCFwvCVyJFQBewr.P7ZufnWdh WX.abpd2u85S9PJJnp8sH4mE8kLurj2P4Y0MZm_C5TEbkOTXnPsbGUNQFqLh 5TBGK0zhl41kfGGEu9MO6CeHu96ZBd0P87QP.vIWXGclZUY1wa3GvAUezJg4 KDE3jlOSmu_5tG6.ld7FSOJbs1xYWklSTGWS8ELVIlLSP76zn5hO0D72jO3N rW8lSuMTWk0U3mORlA4K3LLH0IYGcRZ5kEGsgw9GGnJQlRuCBv0n54DI7mK0 z8uUWo4FLcXqdbvh7A_0Kt61mhQYAXPEbITSNJF6gv6O4bPW6Ug63KiiA4Ob NPP2g7cPNNJm3Ke4XaXJ0FAiwIp0EHzDGMc.nSWWzEc074qjkLnoX35rWiQg - X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.242.10.56] (d.sturek@208.54.15.109 with login) by smtp101.sbc.mail.mud.yahoo.com with SMTP; 15 Jun 2012 07:00:11 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Fri, 15 Jun 2012 06:59:50 -0700 From: Don Sturek To: Michael Richardson , Thomas Heide Clausen Message-ID: Thread-Topic: [6lowpan] [Roll] draft-kelsey-intarea-mesh-link-establishment-03.txt In-Reply-To: <16656.1339765933@marajade.sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "" , "<6lowpan@ietf.org>" <6lowpan@ietf.org>, "" Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 14:00:17 -0000 Hi Michael, We believe UDP makes the most sense as a transport for MLE. ICMP will take entirely too long and will end up being a maintenance issue if there are additional information exchanges needed using MLE. While the ZigBee Alliance is using ROLL RPL and 6LoWPAN, the information exchanged in MLE is not tied specifically to those protocols (however, those implementing will find the exchange useful......) Don On 6/15/12 6:12 AM, "Michael Richardson" wrote: > >>>>>> "Thomas" == Thomas Heide Clausen writes: > Thomas> Not sure how fantastic (or not) it is - it is not > Thomas> immediately clear to me how tied MLE should be to RPL - if > Thomas> it truly aims at being for _MESH_ link establishment, then > Thomas> it would appear to be a much larger scope, and should not be > Thomas> tied narrowly to a special-purpose protocol's type-space (& > Thomas> conventions etc., that do not apply universally). > >Thomas, you will note that: > 1) I suggested it go under IPv6 ICMP first, and if there was such push > back about allocating a new type, that RPL could allocate a >type/code. > 2) ZigBee alliance (the proposal), *IS* using RPL. > >I see running it over UDP very architecturally strange. > >-- >Michael Richardson , Sandelman Software Works >IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > From d.sturek@att.net Fri Jun 15 07:13:28 2012 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 00F0921F8760 for ; Fri, 15 Jun 2012 07:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFpadJX8zEhZ for ; Fri, 15 Jun 2012 07:13:27 -0700 (PDT) Received: from nm1-vm2.bullet.mail.ne1.yahoo.com (nm1-vm2.bullet.mail.ne1.yahoo.com [98.138.91.17]) by ietfa.amsl.com (Postfix) with SMTP id 31C9E21F8754 for ; Fri, 15 Jun 2012 07:13:27 -0700 (PDT) Received: from [98.138.226.180] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jun 2012 14:13:22 -0000 Received: from [68.142.200.225] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jun 2012 14:13:22 -0000 Received: from [66.94.237.106] by t6.bullet.mud.yahoo.com with NNFMP; 15 Jun 2012 14:13:22 -0000 Received: from [127.0.0.1] by omp1011.access.mail.mud.yahoo.com with NNFMP; 15 Jun 2012 14:13:22 -0000 X-Yahoo-Newman-Id: 347361.62817.bm@omp1011.access.mail.mud.yahoo.com Received: (qmail 63045 invoked from network); 15 Jun 2012 14:13:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1339769601; bh=Prw8VTExGAVZY+YNdUhj2FQ0DGRK8DpKkJJ+t8VNJhY=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=aBjQSZOiws4P2VF5JQDTJvJ0Mj8Vqv85HfR6C6X7bjzCCD1amcNYu2XqlgnW+rdk0XTWaXahzf1i4L850m29nnzCZdM9/TslKWfB9nnpyeNMhq5YTecOqzVYF7Dt2a2Db4RKzowQ2FJlFCXuYv3v3W6ojub8GhrOCoFG2MMwzhU= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 3WQPiMsVM1mtRLPKVTOOfr1T5EPzQ6mKriM41tRvBneF92V hMdO6oZ6v1e1P2F1crFJSBMZPBIuXBXyKkUavTlReBOYzzv83ks9myZHFzFa 6CLnIIJYUS2zZDUoOCShRvtSvUaB3hGv3c5hrKWu.9LWREk.DRU.cYKZKlmx sDozDDLA5v6WdikKP5ljdspy6Ic67uefMgL6xglWbHZgbnkYVm1MqCLIjPHM K_GXWMkV0kuCfEmQ6X9_hIoOcxwxXjTmq3R.QeYTXxiLraIAbYfSdelz9lQb IxMCbxv0nvN_BAJ2pw5SwI1otHMcYfFBgd2dN8gIzIVF2lI9tHrzN2bCkbb8 oWJ8wy61ScsLkAdYXaajWApforZXaTiZcTpMifggyuIxoZhsBYBk1skVet_n pIHndvntsxrvvqXU4yordeSsrAkVocq4Xmg-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.242.10.56] (d.sturek@208.54.15.109 with login) by smtp101.sbc.mail.ne1.yahoo.com with SMTP; 15 Jun 2012 07:13:13 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Fri, 15 Jun 2012 07:12:58 -0700 From: Don Sturek To: Carsten Bormann Message-ID: Thread-Topic: [6lowpan] [Roll] draft-kelsey-intarea-mesh-link-establishment-03.txt In-Reply-To: <2D207A78-AD9A-47B6-AD51-9108CEA7D502@tzi.org> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Cc: roll@ietf.org, 6lowpan@ietf.org, ipv6@ietf.org Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 14:13:28 -0000 Hi Carsten, I answered a similar note privately from Michael. Let me share part of that here for everyone: ...... (part of note to Michael deleted....)....... We are just sharing our experience of now 2 years of monthly interops using 6LoWPAN, ROLL RPL, PANA and now MLE. Many of us participated in 6LoWPAN ND and ROLL RPL in IETF (including the author of the MLE draft). We are simply offering up that body of experience to point out the remaining gaps in deploying these protocols. We are pretty close to having a sizable number of semiconductor manufacturers go through commercial certification on these RFCs and drafts. We do have a specification but it simply calls out the RFCs and drafts then provides a baseline configuration used in our commercial deployment. We think many other commercial groups will need to do the same to make interoperability a reality using these protocols. I do believe our specification will be made publicly available once our initial certification is complete (maybe 6 months from now?). The interesting part is product developers should have access to IP enabled IEEE 802.15.4 written in such a way to provide multi-vendor interoperability. One thing though: We realized we needed MLE rather late in our interop process so we don't have a lot of time to close on MLE (commercially). Certainly your ideas to use either ROLL RPL messages or ICMP messages for MLE would not work for us schedule wise. We would have to continue using MLE as written (using UDP) if it goes in another direction within IETF. That said, if we can find a way to *extend* the protocol using input from the ROLL WG (or others) in a way that allows us to continue through certification using MLE (maybe with even some small changes) that would be a win for everyone. ........ (end of note.....)........ Don On 6/15/12 3:43 AM, "Carsten Bormann" wrote: >> we don't have time for all these changes > >It's likely that the next question that will come up is: > >Should this be published as an informational RFC called "ZigBee's MLE >protocol" because the protocol is no longer really meant to be modified >in the process or should it be pursued as a standards track document? > >(Don't get me wrong, I'm all for stability of protocols when there is >running code. >Stability against gratuitous change and Brownian motion, that is. >But not when there are good technical reasons to have the change. >We should be having the discussion on whether that's the case, I think. >And how the encapsulation of MLE works in the first place, something I >don't understand yet.) > >Gr=FC=DFe, Carsten > From d.sturek@att.net Fri Jun 15 07:27:19 2012 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 5D37721F875E for ; Fri, 15 Jun 2012 07:27:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AdNdfJm5W-YR for ; Fri, 15 Jun 2012 07:27:18 -0700 (PDT) Received: from nm33-vm7.bullet.mail.bf1.yahoo.com (nm33-vm7.bullet.mail.bf1.yahoo.com [72.30.239.207]) by ietfa.amsl.com (Postfix) with SMTP id A313B21F8764 for ; Fri, 15 Jun 2012 07:27:18 -0700 (PDT) Received: from [98.139.212.146] by nm33.bullet.mail.bf1.yahoo.com with NNFMP; 15 Jun 2012 14:27:17 -0000 Received: from [68.142.200.226] by tm3.bullet.mail.bf1.yahoo.com with NNFMP; 15 Jun 2012 14:27:17 -0000 Received: from [66.94.237.118] by t7.bullet.mud.yahoo.com with NNFMP; 15 Jun 2012 14:27:17 -0000 Received: from [127.0.0.1] by omp1023.access.mail.mud.yahoo.com with NNFMP; 15 Jun 2012 14:27:17 -0000 X-Yahoo-Newman-Id: 641078.42745.bm@omp1023.access.mail.mud.yahoo.com Received: (qmail 41982 invoked from network); 15 Jun 2012 14:27:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1339770437; bh=B3MkwchSpRexCffgMr0QGIQ9B4f3EDxbXD12jApPkT4=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=IU7Tk38htPR/QSrlTMwB4NMGuPW/YLyPoIOEl8uiPWlc+H/BfWILo2xlpaEX4PGjHWf+5n4PEojvTbuEn1OxX3XlLR3DENiFXSV0SyqNdwhpV1vvycap2frvwTQnASUCjw8BU/YUZr1orX5l2VPdQZ/s9bLcy+j03bNjjK+EId8= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: HntDCzIVM1lnXKz4VWlUDBSGugYmHw_mtZtYwfWkN15O9WW iDcDVM64.FYNAM0Bnu54QssHvQ2lty180ytgKww421sNbFQAYfPd8sEQ.LH7 HkXfNEKb0ucgd0chtGc5K_Y3cN5sLSew7ToZczP2IcQ5nt_BBsr9YNr6vvWq dxkSz6.tWXmJdYsSEWC9.uW3p6c151zlSr9Seflm4ceZvRhxOrc4gFkk72rU Is3IGlQTIHP7rxSGX9iDJ1EgwFwg8l.aU_xohZtm2I3OpClPxRMdzILUyYUZ Z4W6oL_8LAJQoOQ8v46BM2NJihymd6XtMI6AITf_1_ZLyV2EhKxtX5eqToYA fe1gpMxeJneRWyO0PBTph9O6pOe9BFuf.4Ahs0arSAksu9e_T0zh_E3q.2Ed PpU7M8TOG9zrUtZgovii7YieLvFZFoN_B3ksXtAIxe6EyEumopWo- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.242.10.248] (d.sturek@208.54.15.47 with login) by smtp111.sbc.mail.mud.yahoo.com with SMTP; 15 Jun 2012 07:27:16 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Fri, 15 Jun 2012 07:19:53 -0700 From: Don Sturek To: Thomas Heide Clausen Message-ID: Thread-Topic: [6lowpan] [Roll] draft-kelsey-intarea-mesh-link-establishment-03.txt In-Reply-To: <2E20BD63-02D7-4275-A3C1-2E070D9BB90E@thomasclausen.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "" , "<6lowpan@ietf.org>" <6lowpan@ietf.org>, "" Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 14:27:19 -0000 Hi Thomas, Sorry it was late when I wrote that response :-) We debated a long time on MLE. We knew we needed a one hop information exchange between nodes to help with 6LoWPAN ND (eg exchange long address information), link quality (eg. for creation and maintenance of symmetric links), etc. We looked at a lot of transport options and UDP seemed to make the most sense. One nice thing about having MLE use UDP: If someone wishes to extend MLE they don't need to have work done in ICMP or ROLL to make it happen. I think we arrived at the Internet area for the draft since part of MLE helps with 6LoWPAN ND, other functions help with ROLL RPL parent selection. I think we made these generic so others with similar needs could make use of MLE without necessarily using either 6LoWPAN ND or ROLL RPL. That said, if ROLL is interested in this draft, Richard Kelsey (the drafts author) has plenty of experience there :-) Don On 6/15/12 3:32 AM, "Thomas Heide Clausen" wrote: >Not sure how fantastic (or not) it is - it is not immediately clear to me >how tied MLE should be to RPL - if it truly aims at being for _MESH_ link >establishment, then it would appear to be a much larger scope, and should >not be tied narrowly to a special-purpose protocol's type-space (& >conventions etc., that do not apply universally). > >I guess I'm expressing some sort of support for Don's position... > >-- >Thomas Heide Clausen >http://www.thomasclausen.org/ > >"Any simple problem can be made insoluble if enough meetings are held to > discuss it." > -- Mitchell's Law of Committees > > >On 15 Jun 2012, at 01:43, Don Sturek wrote: > >> All sounds fantastic but we don't have time for all these changes so >>will >> opt to use MLE as written using UDP ( at least for our application....) >> >> Don >> >> >> >> On 6/14/12 1:13 PM, "Michael Richardson" wrote: >> >>> >>> In draft-kelsey-intarea-mesh-link-establishment-03.txt it says that >>> MLE messages are sent using UDP. >>> >>> I want to suggest that MLE messages should be sent at least as IPv6 >>> ICMP messages. >>> >>> Further, I think that it could use the RPL type 155, and RPL would >>> allocate a new "code" codepoint. >>> >>> There would be some preference to have the general structure of MLE >>> match that of RPL, but I think that this isn't particularly a strong >>> requirement. Allocating a new ICMP type code for MLE alone might be >>> seen as excessive, but I can not speak for the folks in 6man. >>> >>> -- >>> Michael Richardson , Sandelman Software Works >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >> >> >> _______________________________________________ >> 6lowpan mailing list >> 6lowpan@ietf.org >> https://www.ietf.org/mailman/listinfo/6lowpan From mcr@sandelman.ca Fri Jun 15 07:30:48 2012 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 0185921F8620; Fri, 15 Jun 2012 07:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.408 X-Spam-Level: X-Spam-Status: No, score=-1.408 tagged_above=-999 required=5 tests=[AWL=0.546, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hwMohASu44EL; Fri, 15 Jun 2012 07:30:47 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 830B121F87A0; Fri, 15 Jun 2012 07:30:47 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 09ABE8549; Fri, 15 Jun 2012 10:28:18 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id E6FCC98C2E; Fri, 15 Jun 2012 10:30:45 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E1F8B98C2D; Fri, 15 Jun 2012 10:30:45 -0400 (EDT) From: Michael Richardson To: Don Sturek In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 15 Jun 2012 10:30:45 -0400 Message-ID: <10344.1339770645@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: "" , "<6lowpan@ietf.org>" <6lowpan@ietf.org>, "" Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 14:30:48 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Don" =3D=3D Don Sturek writes: Don> We believe UDP makes the most sense as a transport for MLE. ICMP = will Don> take entirely too long and will end up being a maintenance issue i= f there Don> are additional information exchanges needed using MLE. I can't see a difference myself in "length of time", unless you mean time to change hardware/firmware/software. ICMP is even 4 bytes shorter than UDP. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT9tHFYqHRg3pndX9AQIRpwP9HQtqV4Vd1K9YKKUaoojKj45oeMHjGZ91 JyIGiCLt68JFckjtdf2zParPXmuvX34zcFSUNRFeg+ZzBm8AKQXcqhTw2myRyfBp IBgr7Ou1Ustk521qglIct4MOc60GnM8IgAILPNGKqfNveuxSdq0Zn/MH7Ph/MI4w wsP0uA3lfoM= =xNbW -----END PGP SIGNATURE----- --=-=-=-- From d.sturek@att.net Fri Jun 15 07:48:21 2012 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 DA29321F879C for ; Fri, 15 Jun 2012 07:48:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.065 X-Spam-Level: X-Spam-Status: No, score=-2.065 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9xDrWAKk7ob for ; Fri, 15 Jun 2012 07:48:21 -0700 (PDT) Received: from nm30-vm0.access.bullet.mail.mud.yahoo.com (nm30-vm0.access.bullet.mail.mud.yahoo.com [66.94.237.86]) by ietfa.amsl.com (Postfix) with SMTP id CC4EE21F8792 for ; Fri, 15 Jun 2012 07:48:20 -0700 (PDT) Received: from [66.94.237.195] by nm30.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Jun 2012 14:48:18 -0000 Received: from [98.139.244.53] by tm6.access.bullet.mail.mud.yahoo.com with NNFMP; 15 Jun 2012 14:48:18 -0000 Received: from [127.0.0.1] by smtp115.sbc.mail.bf1.yahoo.com with NNFMP; 15 Jun 2012 14:48:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1339771697; bh=T8h+qqj8CRezqE+pPTf+0wRQ4HMDJ5acTT+PMqBwpEI=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=kjp6qopJ+DebqwOXWOsFNW5XjCO/qrkNPbtMg4VeS9azLBf53rf2KucZiATOai5+PKi5xmvyLUinxxAoS1ZcW4zK0/cDgLIji5JeFqyLCuY4QPtldB7F8GvSI2V8epg/Td0lJWOwLu1d9PwsdypJAlfEyvfZ+YMk+f2idhOPS8k= X-Yahoo-Newman-Id: 982799.5990.bm@smtp115.sbc.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: .qiTxgkVM1k3aIeXEKHrtOlsGJJxuV6EL1j3Da0PgBhgAtj 5kE6DG_h1svGeQfTZi8M7OjjPLRU9EN2Qvr4McxQj0F9cXEHDxyEIK5YM31N DeyBhHLDupelzqlI3rtAWRIZSAh1fG0FoaROKwqxflNzLZtYbqd2zs.Q6wVP oAZrd0AbMlOSAhMickVD9k66kBk0k9pWQuTQfAQ.mrO7k30SICQuOtC0WEZv Zjkdxnp8aivqnI65HY_iQopcH.SCLhV.Z2LWQzmT_xmpiyVyQJRfWMQ6t8ra ou569zgbf8tr1eI68PxG8kmpkJ1Ml30amt.XaMr39etG.Jz7Rshyw.Db8Sm. mC1DujFt7Ih2oFxJahKOGy6mHCPoAanVHNJBZSsGdBmX7XGPuecbbXlmj_OJ GsTqyi3FtEaqi6ujM4c09zpX1uQQhySHiVMrvMoSBtmp.F.kMxlUWXWLkxse azJ_MFKBWuO3QR1h8h9MsZINnCJsiQX7eZLRARwuFDEbLLkBfkwj8jZ5le00 hvExBopTKApKBVcrqQ1wS5VM5KA-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.43.94] (d.sturek@208.54.80.212 with login) by smtp115.sbc.mail.bf1.yahoo.com with SMTP; 15 Jun 2012 07:48:17 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Fri, 15 Jun 2012 07:45:15 -0700 From: Don Sturek To: Michael Richardson Message-ID: Thread-Topic: [6lowpan] [Roll] draft-kelsey-intarea-mesh-link-establishment-03.txt In-Reply-To: <10344.1339770645@marajade.sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "" , "<6lowpan@ietf.org>" <6lowpan@ietf.org>, "" Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 14:48:22 -0000 Hi Michael, It is the process needed to make additions to ICMP. We have multiple implementers using the existing MLE draft so we also are trying to get closure if we can since we plan to being commercial certification shortly. To us, MLE provides the features we need and there is ownership that does not rely on ourside work groups. If others find use in MLE (and we believe they will) then it is offered as a draft to the IETF community. If the protocol fundamentally changes and has dependencies on other groups, I would doubt it would be ready for implementation in our timeframe. Don On 6/15/12 7:30 AM, "Michael Richardson" wrote: > >>>>>> "Don" == Don Sturek writes: > Don> We believe UDP makes the most sense as a transport for MLE. >ICMP will > Don> take entirely too long and will end up being a maintenance issue >if there > Don> are additional information exchanges needed using MLE. > >I can't see a difference myself in "length of time", unless you mean >time to change hardware/firmware/software. > >ICMP is even 4 bytes shorter than UDP. > >-- >Michael Richardson , Sandelman Software Works >IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > From abdussalambaryun@gmail.com Fri Jun 15 08:00:58 2012 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 43A9F21F87BC; Fri, 15 Jun 2012 08:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ODjSKfkixX69; Fri, 15 Jun 2012 08:00:57 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2152421F86B8; Fri, 15 Jun 2012 08:00:57 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1985296vbb.31 for ; Fri, 15 Jun 2012 08:00:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9l8Wr5JJxfyle5NqnhTzt/LorZpz1EJ1CyFOC/EWLtM=; b=0BhMdFc9zb3s6kKzTnwq/4SEd8JjO4MwOcWJfCf2Pt2eR7OQlTIROyPpTDXAMjZGAN x4oCd+cs91Z6gYJgxIxLxIz5TUr4IPCFZkISaZmIQYuVnQrLlGw9ZiAhD+3zRipLxyLN ZgGgoLKuaAfd6H1cD0ZrJVoFYZa3g97xK0jdfabypMQiBeXCOXBHArPZAqojwRHmDE8z qUPI4pMSDBinVhVbZdmeDbt/eV30wIOJgFbWOCkNXQzuceACxskeFzzUsf7U21rZLd4n EyuN3R73LnIAEFT1CK778fl/cTbZi83GxTquUMfGDnIMjBAqY3m/l7cWm996IiUr+HWo fF5Q== MIME-Version: 1.0 Received: by 10.220.153.80 with SMTP id j16mr3240783vcw.55.1339772448062; Fri, 15 Jun 2012 08:00:48 -0700 (PDT) Received: by 10.220.211.72 with HTTP; Fri, 15 Jun 2012 08:00:47 -0700 (PDT) In-Reply-To: References: <6FE0075D-CB42-4FE1-A5D2-20330917542C@thomasclausen.org> Date: Fri, 15 Jun 2012 16:00:47 +0100 Message-ID: From: Abdussalam Baryun To: Don Sturek Content-Type: multipart/alternative; boundary=f46d043be15ad8be8d04c284149e Cc: roll@ietf.org, 6lowpan@ietf.org Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 15:00:58 -0000 --f46d043be15ad8be8d04c284149e Content-Type: text/plain; charset=ISO-8859-1 +1 AB On Fri, Jun 15, 2012 at 2:57 PM, Don Sturek wrote: > Hi Thomas (and Michael), > > I don't agree that MLE targets only RPL. The draft was written carefully > to avoid having a narrow focus around RPL. That said, the deployment we > are using this draft for uses 6LoWPAN, 6LoWPAN ND, ROLL RPL (non-storing) > and I think many others will find the information exchanged between > neighbors using MLE as useful. > > Don > > > > > > On 6/15/12 6:15 AM, "Thomas Heide Clausen" wrote: > > > > >On Jun 15, 2012, at 15:12 , Michael Richardson wrote: > > > >> > >>>>>>> "Thomas" == Thomas Heide Clausen writes: > >> Thomas> Not sure how fantastic (or not) it is - it is not > >> Thomas> immediately clear to me how tied MLE should be to RPL - if > >> Thomas> it truly aims at being for _MESH_ link establishment, then > >> Thomas> it would appear to be a much larger scope, and should not be > >> Thomas> tied narrowly to a special-purpose protocol's type-space (& > >> Thomas> conventions etc., that do not apply universally). > >> > >> Thomas, you will note that: > >> 1) I suggested it go under IPv6 ICMP first, and if there was such push > >> back about allocating a new type, that RPL could allocate a > >>type/code. > >> 2) ZigBee alliance (the proposal), *IS* using RPL. > >> > > > >In that case, the draft must be very narrowly scoped and written such > >that it's clear that it's applicable _only_ to that context > >(special-purpose deployments of a special-purpose protocol), and > >specifically to not pretend to do general mesh link establishment. > > > >> I see running it over UDP very architecturally strange. > > > >I don't. > > > >Thomas > > > >> -- > >> Michael Richardson , Sandelman Software Works > >> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > >> > > > > > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > --f46d043be15ad8be8d04c284149e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+1
=A0
AB

On Fri, Jun 15, 2012 at 2:57 PM, Don Sturek <d.s= turek@att.net> wrote:
Hi Thomas (and Michael),

I don= 't agree that MLE targets only RPL. =A0The draft was written carefully<= br> to avoid having a narrow focus around RPL. =A0That said, the deployment we<= br>are using this draft for uses 6LoWPAN, 6LoWPAN ND, ROLL RPL (non-storing= )
and I think many others will find the information exchanged between neighbors using MLE as useful.

Don





On 6/15/12 6:15 AM, "Thomas Heid= e Clausen" <ietf@thomascl= ausen.org> wrote:

>
>On Jun 15, 2012, at 15:12 , Mic= hael Richardson wrote:
>
>>
>>>>>>> "Thomas" =3D=3D = Thomas Heide Clausen <ietf@tho= masclausen.org> writes:
>> =A0 =A0Thomas> Not sure how f= antastic (or not) it is - it is not
>> =A0 =A0Thomas> immediately clear to me how tied MLE should be t= o RPL - if
>> =A0 =A0Thomas> it truly aims at being for _MESH_ = link establishment, then
>> =A0 =A0Thomas> it would appear to b= e a much larger scope, and should not be
>> =A0 =A0Thomas> tied narrowly to a special-purpose protocol'= s type-space (&
>> =A0 =A0Thomas> conventions etc., that do= not apply universally).
>>
>> Thomas, you will note that= :
>> =A01) I suggested it go under IPv6 ICMP first, and if there was su= ch push
>> =A0 =A0 back about allocating a new type, that RPL coul= d allocate a
>>type/code.
>> =A02) ZigBee alliance (the p= roposal), *IS* using RPL.
>>
>
>In that case, the draft must be very narrowly scope= d and written such
>that it's clear that it's applicable _onl= y_ to that context
>(special-purpose deployments of a special-purpose= protocol), and
>specifically to not pretend to do general mesh link establishment.
&= gt;
>> I see running it over UDP very architecturally strange.
= >
>I don't.
>
>Thomas
>
>> --
>> Michael Richardson <= mcr+IETF@sandelman.ca>, Sandelman Software Works
>> IETF RO= LL WG co-chair. =A0 =A0http://datatracker.ietf.org/wg/roll/charter/
>>
>


_______________________________________________=
6lowpan mailing list
6lowpan@iet= f.org
https://www.ietf.org/mailman/listinfo/6lowpan

--f46d043be15ad8be8d04c284149e-- From ietf@thomasclausen.org Fri Jun 15 09:28:12 2012 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 6FE8621F846F; Fri, 15 Jun 2012 09:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4H-9-3FOUDM; Fri, 15 Jun 2012 09:28:11 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id D415321F8467; Fri, 15 Jun 2012 09:28:11 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 591F755809E; Fri, 15 Jun 2012 09:28:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id D2AC51C6E5B; Fri, 15 Jun 2012 09:28:09 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.147.40.163] (37-8-181-55.coucou-networks.fr [37.8.181.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 3BEC81C6DBA; Fri, 15 Jun 2012 09:28:09 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Fri, 15 Jun 2012 18:28:16 +0200 To: Don Sturek Cc: "" , "<6lowpan@ietf.org>" <6lowpan@ietf.org>, "" Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 16:28:12 -0000 On 15 Jun 2012, at 15:57, Don Sturek wrote: > Hi Thomas (and Michael), >=20 > I don't agree that MLE targets only RPL. The draft was written carefully > to avoid having a narrow focus around RPL. That said, the deployment we > are using this draft for uses 6LoWPAN, 6LoWPAN ND, ROLL RPL (non-storing) > and I think many others will find the information exchanged between > neighbors using MLE as useful. >=20 > Don >=20 Hi Don, Note that I was replying to Michael's suggestions that MLE be married to RPL= . If you think it's not, then MLE should neither be developed in ROLL nor be c= onstrained by RPL code-points, messages or principles. Thomas > On 6/15/12 6:15 AM, "Thomas Heide Clausen" wrote:= >=20 >>=20 >> On Jun 15, 2012, at 15:12 , Michael Richardson wrote: >>=20 >>>=20 >>>>>>>> "Thomas" =3D=3D Thomas Heide Clausen write= s: >>> Thomas> Not sure how fantastic (or not) it is - it is not >>> Thomas> immediately clear to me how tied MLE should be to RPL - if >>> Thomas> it truly aims at being for _MESH_ link establishment, then >>> Thomas> it would appear to be a much larger scope, and should not be >>> Thomas> tied narrowly to a special-purpose protocol's type-space (& >>> Thomas> conventions etc., that do not apply universally). >>>=20 >>> Thomas, you will note that: >>> 1) I suggested it go under IPv6 ICMP first, and if there was such push >>> back about allocating a new type, that RPL could allocate a >>> type/code. >>> 2) ZigBee alliance (the proposal), *IS* using RPL. >>>=20 >>=20 >> In that case, the draft must be very narrowly scoped and written such >> that it's clear that it's applicable _only_ to that context >> (special-purpose deployments of a special-purpose protocol), and >> specifically to not pretend to do general mesh link establishment. >>=20 >>> I see running it over UDP very architecturally strange. >>=20 >> I don't. >>=20 >> Thomas >>=20 >>> --=20 >>> Michael Richardson , Sandelman Software Works >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>>=20 >>=20 >=20 >=20 From d.sturek@att.net Fri Jun 15 09:41:46 2012 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 52DD421F84B6 for ; Fri, 15 Jun 2012 09:41:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0DeItah0CnL for ; Fri, 15 Jun 2012 09:41:42 -0700 (PDT) Received: from nm20-vm0.bullet.mail.bf1.yahoo.com (nm20-vm0.bullet.mail.bf1.yahoo.com [98.139.213.165]) by ietfa.amsl.com (Postfix) with SMTP id BA9EE21F847D for ; Fri, 15 Jun 2012 09:41:42 -0700 (PDT) Received: from [98.139.212.148] by nm20.bullet.mail.bf1.yahoo.com with NNFMP; 15 Jun 2012 16:41:41 -0000 Received: from [68.142.200.227] by tm5.bullet.mail.bf1.yahoo.com with NNFMP; 15 Jun 2012 16:41:41 -0000 Received: from [66.94.237.123] by t8.bullet.mud.yahoo.com with NNFMP; 15 Jun 2012 16:41:41 -0000 Received: from [127.0.0.1] by omp1028.access.mail.mud.yahoo.com with NNFMP; 15 Jun 2012 16:41:41 -0000 X-Yahoo-Newman-Id: 769783.50822.bm@omp1028.access.mail.mud.yahoo.com Received: (qmail 67846 invoked from network); 15 Jun 2012 16:41:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1339778501; bh=sqYeNsM7HukDm1JDpjqvfaK6Q1Gp2P8GtCdl7cqTV4c=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=ZjmkeCutl+cudL7Ib0H4Zwl3v5K3gV/QLyOQl+nNHJpjTIAd5im4XZzhoKiGIz5kG22KiQN8T2a4lKaie84qsN59j+X1kfsFKsqYhXj4FxCSHz+gZSi/PZR3jtdl1vUHhE0uEX2JYrjMQquUZJpbpRD92dEgEy7WIqeTCBqp9HQ= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: wKmM17sVM1kKnkMaOCweySlem2c7yoBvWlAyCqkZFuAXroK Xbi_TXDmuAF0K4z_v4a1JBv4ONbS2.QfYyxvosB.kD46h1gxSd.Bc3H4xAF6 SkxUZIAfbPnqJFgfhVt6.4AykgpifQZqJwApXIdkuwJ6idBRBuc9Bf7pt0zq BBIsmXiadHPG.qjZ5G6jOLjd7extnoy.87tiK45kmrteNpqXtq7blIIY4iEv U4aUWGHnoZB2yOVdoqGeQcvK4G3iSrtVpzQkBChwEitk_1NKDvd0.dJfX6mQ l3pQnQy9EUGf1qI46riG6UaLvcxsQfpe5JOySXHkbgRD5FYS5y8Z2fX2zSuG 30j_llEuqRfUQY.RINEYidTY7R5qtBo2SLEf1TZSYMOsDHefa6Cw2cq_MYYp aUSLpGcRaIsC9I_stk5yPOKFGJg8uRZrWe_Hzwn.CYS11ps5fgspC0lxY1Sm 7dFfeYic8XszjQc6S9JLkp6G_U7m1o20aPIicdOcFtXQTfPOv7oZf5yAuV8q 3kcTCzxhJ3YrGjjE- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.242.10.205] (d.sturek@208.54.15.4 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 15 Jun 2012 09:41:39 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Fri, 15 Jun 2012 09:41:32 -0700 From: Don Sturek To: Thomas Heide Clausen Message-ID: Thread-Topic: [6lowpan] [Roll] draft-kelsey-intarea-mesh-link-establishment-03.txt In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "" , "<6lowpan@ietf.org>" <6lowpan@ietf.org>, "" Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 16:41:46 -0000 Hi Thomas, I think our plan was to submit it to the Internet Area directly (Richard: That is from memory, am I correct?) Don On 6/15/12 9:28 AM, "Thomas Heide Clausen" wrote: > >On 15 Jun 2012, at 15:57, Don Sturek wrote: > >> Hi Thomas (and Michael), >> >> I don't agree that MLE targets only RPL. The draft was written >>carefully >> to avoid having a narrow focus around RPL. That said, the deployment we >> are using this draft for uses 6LoWPAN, 6LoWPAN ND, ROLL RPL >>(non-storing) >> and I think many others will find the information exchanged between >> neighbors using MLE as useful. >> >> Don >> > >Hi Don, > >Note that I was replying to Michael's suggestions that MLE be married to >RPL. > >If you think it's not, then MLE should neither be developed in ROLL nor >be constrained by RPL code-points, messages or principles. > > >Thomas > >> On 6/15/12 6:15 AM, "Thomas Heide Clausen" >>wrote: >> >>> >>> On Jun 15, 2012, at 15:12 , Michael Richardson wrote: >>> >>>> >>>>>>>>> "Thomas" == Thomas Heide Clausen writes: >>>> Thomas> Not sure how fantastic (or not) it is - it is not >>>> Thomas> immediately clear to me how tied MLE should be to RPL - if >>>> Thomas> it truly aims at being for _MESH_ link establishment, then >>>> Thomas> it would appear to be a much larger scope, and should not be >>>> Thomas> tied narrowly to a special-purpose protocol's type-space (& >>>> Thomas> conventions etc., that do not apply universally). >>>> >>>> Thomas, you will note that: >>>> 1) I suggested it go under IPv6 ICMP first, and if there was such push >>>> back about allocating a new type, that RPL could allocate a >>>> type/code. >>>> 2) ZigBee alliance (the proposal), *IS* using RPL. >>>> >>> >>> In that case, the draft must be very narrowly scoped and written such >>> that it's clear that it's applicable _only_ to that context >>> (special-purpose deployments of a special-purpose protocol), and >>> specifically to not pretend to do general mesh link establishment. >>> >>>> I see running it over UDP very architecturally strange. >>> >>> I don't. >>> >>> Thomas >>> >>>> -- >>>> Michael Richardson , Sandelman Software Works >>>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>>> >>> >> >> From ietf@thomasclausen.org Fri Jun 15 09:59:13 2012 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 BB38D21F8595; Fri, 15 Jun 2012 09:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zCsVonQqSE5I; Fri, 15 Jun 2012 09:59:13 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0214721F853D; Fri, 15 Jun 2012 09:59:13 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 910E3557F50; Fri, 15 Jun 2012 09:59:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 755041BD6C5E; Fri, 15 Jun 2012 09:59:11 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.147.40.163] (37-8-181-55.coucou-networks.fr [37.8.181.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E5CBD1BD6C5F; Fri, 15 Jun 2012 09:59:10 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <6EBA154B-EFDC-4E46-B04F-D86546B4F07E@thomasclausen.org> X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Fri, 15 Jun 2012 18:59:18 +0200 To: Don Sturek Cc: "" , "<6lowpan@ietf.org>" <6lowpan@ietf.org>, "" Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 16:59:13 -0000 Hi Don, On 15 Jun 2012, at 18:41, Don Sturek wrote: > Hi Thomas, >=20 > I think our plan was to submit it to the Internet Area directly (Richard: > That is from memory, am I correct?) >=20 If that's the case, then I think that it needs to be scoped carefully: the d= esign and direction of the work required would (IMO) be very different if it= aims narrowly for RPL, or broadly for "MESH", and the text in the specifica= tion should be very very clear as to this. If an AD sponsored submission is the intend, then I do honestly not know wha= t the proper way of shaping the process / forum for discussions / framing of= the specification would be, but I would hope that an AD could chirp in (as y= ou say INT, have you discussed this with Brian or Ralph, and could you or ei= ther of them let us know?) Note, I am not taking position for or against MLE at all - I just want to en= sure that a specification published be scoped so as to not be constraining f= or domains for which it hasn't been discussed. Thomas > Don >=20 >=20 >=20 > On 6/15/12 9:28 AM, "Thomas Heide Clausen" wrote:= >=20 >>=20 >> On 15 Jun 2012, at 15:57, Don Sturek wrote: >>=20 >>> Hi Thomas (and Michael), >>>=20 >>> I don't agree that MLE targets only RPL. The draft was written >>> carefully >>> to avoid having a narrow focus around RPL. That said, the deployment we= >>> are using this draft for uses 6LoWPAN, 6LoWPAN ND, ROLL RPL >>> (non-storing) >>> and I think many others will find the information exchanged between >>> neighbors using MLE as useful. >>>=20 >>> Don >>>=20 >>=20 >> Hi Don, >>=20 >> Note that I was replying to Michael's suggestions that MLE be married to >> RPL. >>=20 >> If you think it's not, then MLE should neither be developed in ROLL nor >> be constrained by RPL code-points, messages or principles. >>=20 >>=20 >> Thomas >>=20 >>> On 6/15/12 6:15 AM, "Thomas Heide Clausen" >>> wrote: >>>=20 >>>>=20 >>>> On Jun 15, 2012, at 15:12 , Michael Richardson wrote: >>>>=20 >>>>>=20 >>>>>>>>>> "Thomas" =3D=3D Thomas Heide Clausen wri= tes: >>>>> Thomas> Not sure how fantastic (or not) it is - it is not >>>>> Thomas> immediately clear to me how tied MLE should be to RPL - if >>>>> Thomas> it truly aims at being for _MESH_ link establishment, then >>>>> Thomas> it would appear to be a much larger scope, and should not be >>>>> Thomas> tied narrowly to a special-purpose protocol's type-space (& >>>>> Thomas> conventions etc., that do not apply universally). >>>>>=20 >>>>> Thomas, you will note that: >>>>> 1) I suggested it go under IPv6 ICMP first, and if there was such push= >>>>> back about allocating a new type, that RPL could allocate a >>>>> type/code. >>>>> 2) ZigBee alliance (the proposal), *IS* using RPL. >>>>>=20 >>>>=20 >>>> In that case, the draft must be very narrowly scoped and written such >>>> that it's clear that it's applicable _only_ to that context >>>> (special-purpose deployments of a special-purpose protocol), and >>>> specifically to not pretend to do general mesh link establishment. >>>>=20 >>>>> I see running it over UDP very architecturally strange. >>>>=20 >>>> I don't. >>>>=20 >>>> Thomas >>>>=20 >>>>> --=20 >>>>> Michael Richardson , Sandelman Software Works >>>>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/= >>>>>=20 >>>>=20 >>>=20 >>>=20 >=20 >=20 From d.sturek@att.net Fri Jun 15 10:07:06 2012 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 7B9F021F856F for ; Fri, 15 Jun 2012 10:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLX3DHI8+yE1 for ; Fri, 15 Jun 2012 10:07:05 -0700 (PDT) Received: from nm33.bullet.mail.ne1.yahoo.com (nm33.bullet.mail.ne1.yahoo.com [98.138.229.26]) by ietfa.amsl.com (Postfix) with SMTP id B9D9221F857D for ; Fri, 15 Jun 2012 10:07:05 -0700 (PDT) Received: from [98.138.90.54] by nm33.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jun 2012 17:07:02 -0000 Received: from [98.138.226.56] by tm7.bullet.mail.ne1.yahoo.com with NNFMP; 15 Jun 2012 17:07:02 -0000 Received: from [127.0.0.1] by smtp207.mail.ne1.yahoo.com with NNFMP; 15 Jun 2012 17:07:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1339780022; bh=6PeKJUeKDzwrcFWPtnuBYXX2p1pS5hOr8D1chWCnP6c=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Date:Subject:Message-ID:From:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=IFPR06OJdpmawQV2DdE+3IsXcuPLcNLhQb2zdhy1BeDCLQON2D0kqGJoJcA6la3dzAnzTSxVihkbZKMoSAnxxU10GSSp9PfPolRze2cfeQeS1hsf/0vzYPv+bBdYUSzPIYMVD1VFBVp9RjsVN6H6XBYZsPEBDwjC4sBXKYDhpHE= X-Yahoo-Newman-Id: 287445.86789.bm@smtp207.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: MQlAV9QVM1kx8PzkVLU8V8P3uFiJWlVTpqzTc1Si9kXU.I9 vy_VXUx3G6M8L8FgiEdh4Hs0UNDrLEFNsS3tm4WC5BDjORtRIjiUlBTjipEJ bgEe2kqoHDnl45qmpExo6DpkP1uZmpM8p0W9iHyF5CV5QdQ._38tMZYWpQoL HkuR84BMfFZHL6vQAvl9yjZdRL5XqA9y9fuwXN7hAU7hlru3hNz7v8itvhJw 8Nxvs34ADTBzjC_jfVhwyrQMZm_.2wScNOOmqY0yA_E7C5BN7lnOaaieOB6v TxkmVL6PtJ9ZWqdVW2U47Dj__XpJGPA7pgvucGYStv9qve4.MHxfG3RndtD5 SfV2K73ppot936DoPs0FcKBNtmA5vFGIRwMcFXaL0NW8PPOaJ_RT_jfnL.uW Uoc2h327l9LSCwBeavrmxlVpl6.Zr4bvKXpVRKmGBF5a23MknIh3RYs0_xA3 R0KmF56smveY5JgifKzOBJ0wUdqJapk21lC5n5TJioxOHF1NZjsjXa0A4iRw - X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from 100.165.83.40 (d.sturek@208.54.80.212 with plain) by smtp207.mail.ne1.yahoo.com with SMTP; 15 Jun 2012 10:07:01 -0700 PDT Date: Fri, 15 Jun 2012 12:06:49 -0500 Message-ID: From: Don Sturek To: Thomas Heide Clausen MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 Cc: "" , "<6lowpan@ietf.org>" <6lowpan@ietf.org>, "" Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 17:07:06 -0000 SGkgVGhvbWFzLAoKRmFpciBlbm91Z2guICBJIGRvIGtub3cgd2UgYXZvaWRlZCBtYWtpbmcgdGhl IGRyYWZ0IFJQTCBzcGVjaWZpYyBzbyBsb29rIGZvcndhcmQgdG8gaGVhcmluZyBmcm9tIHRoZSBp bnRhcmVhIEFEcyBvbiB3aGVyZSB3ZSBzaG91bGQgZGlyZWN0IHRoZSBkcmFmdC4KCkRvbgoKU2Vu dCBmcm9tIFQtTW9iaWxlIEcyIHdpdGggR29vZ2xlCgpUaG9tYXMgSGVpZGUgQ2xhdXNlbiA8aWV0 ZkB0aG9tYXNjbGF1c2VuLm9yZz4gd3JvdGU6Cgo+SGkgRG9uLAo+Cj4KPk9uIDE1IEp1biAyMDEy LCBhdCAxODo0MSwgRG9uIFN0dXJlayA8ZC5zdHVyZWtAYXR0Lm5ldD4gd3JvdGU6Cj4KPj4gSGkg VGhvbWFzLAo+PiAKPj4gSSB0aGluayBvdXIgcGxhbiB3YXMgdG8gc3VibWl0IGl0IHRvIHRoZSBJ bnRlcm5ldCBBcmVhIGRpcmVjdGx5IChSaWNoYXJkOgo+PiBUaGF0IGlzIGZyb20gbWVtb3J5LCBh bSBJIGNvcnJlY3Q/KQo+PiAKPgo+SWYgdGhhdCdzIHRoZSBjYXNlLCB0aGVuIEkgdGhpbmsgdGhh dCBpdCBuZWVkcyB0byBiZSBzY29wZWQgY2FyZWZ1bGx5OiB0aGUgZGVzaWduIGFuZCBkaXJlY3Rp b24gb2YgdGhlIHdvcmsgcmVxdWlyZWQgd291bGQgKElNTykgYmUgdmVyeSBkaWZmZXJlbnQgaWYg aXQgYWltcyBuYXJyb3dseSBmb3IgUlBMLCBvciBicm9hZGx5IGZvciAiTUVTSCIsIGFuZCB0aGUg dGV4dCBpbiB0aGUgc3BlY2lmaWNhdGlvbiBzaG91bGQgYmUgdmVyeSB2ZXJ5IGNsZWFyIGFzIHRv IHRoaXMuCj4KPklmIGFuIEFEIHNwb25zb3JlZCBzdWJtaXNzaW9uIGlzIHRoZSBpbnRlbmQsIHRo ZW4gSSBkbyBob25lc3RseSBub3Qga25vdyB3aGF0IHRoZSBwcm9wZXIgd2F5IG9mIHNoYXBpbmcg dGhlIHByb2Nlc3MgLyBmb3J1bSBmb3IgZGlzY3Vzc2lvbnMgLyBmcmFtaW5nIG9mIHRoZSBzcGVj aWZpY2F0aW9uIHdvdWxkIGJlLCBidXQgSSB3b3VsZCBob3BlIHRoYXQgYW4gQUQgY291bGQgY2hp cnAgaW4gKGFzIHlvdSBzYXkgSU5ULCBoYXZlIHlvdSBkaXNjdXNzZWQgdGhpcyB3aXRoIEJyaWFu IG9yIFJhbHBoLCBhbmQgY291bGQgeW91IG9yIGVpdGhlciBvZiB0aGVtIGxldCB1cyBrbm93PykK Pgo+Tm90ZSwgSSBhbSBub3QgdGFraW5nIHBvc2l0aW9uIGZvciBvciBhZ2FpbnN0IE1MRSBhdCBh bGwgLSBJIGp1c3Qgd2FudCB0byBlbnN1cmUgdGhhdCBhIHNwZWNpZmljYXRpb24gcHVibGlzaGVk IGJlIHNjb3BlZCBzbyBhcyB0byBub3QgYmUgY29uc3RyYWluaW5nIGZvciBkb21haW5zIGZvciB3 aGljaCBpdCBoYXNuJ3QgYmVlbiBkaXNjdXNzZWQuCj4KPlRob21hcwo+Cj4KPj4gRG9uCj4+IAo+ PiAKPj4gCj4+IE9uIDYvMTUvMTIgOToyOCBBTSwgIlRob21hcyBIZWlkZSBDbGF1c2VuIiA8aWV0 ZkB0aG9tYXNjbGF1c2VuLm9yZz4gd3JvdGU6Cj4+IAo+Pj4gCj4+PiBPbiAxNSBKdW4gMjAxMiwg YXQgMTU6NTcsIERvbiBTdHVyZWsgPGQuc3R1cmVrQGF0dC5uZXQ+IHdyb3RlOgo+Pj4gCj4+Pj4g SGkgVGhvbWFzIChhbmQgTWljaGFlbCksCj4+Pj4gCj4+Pj4gSSBkb24ndCBhZ3JlZSB0aGF0IE1M RSB0YXJnZXRzIG9ubHkgUlBMLiAgVGhlIGRyYWZ0IHdhcyB3cml0dGVuCj4+Pj4gY2FyZWZ1bGx5 Cj4+Pj4gdG8gYXZvaWQgaGF2aW5nIGEgbmFycm93IGZvY3VzIGFyb3VuZCBSUEwuICBUaGF0IHNh aWQsIHRoZSBkZXBsb3ltZW50IHdlCj4+Pj4gYXJlIHVzaW5nIHRoaXMgZHJhZnQgZm9yIHVzZXMg NkxvV1BBTiwgNkxvV1BBTiBORCwgUk9MTCBSUEwKPj4+PiAobm9uLXN0b3JpbmcpCj4+Pj4gYW5k IEkgdGhpbmsgbWFueSBvdGhlcnMgd2lsbCBmaW5kIHRoZSBpbmZvcm1hdGlvbiBleGNoYW5nZWQg YmV0d2Vlbgo+Pj4+IG5laWdoYm9ycyB1c2luZyBNTEUgYXMgdXNlZnVsLgo+Pj4+IAo+Pj4+IERv bgo+Pj4+IAo+Pj4gCj4+PiBIaSBEb24sCj4+PiAKPj4+IE5vdGUgdGhhdCBJIHdhcyByZXBseWlu ZyB0byBNaWNoYWVsJ3Mgc3VnZ2VzdGlvbnMgdGhhdCBNTEUgYmUgbWFycmllZCB0bwo+Pj4gUlBM Lgo+Pj4gCj4+PiBJZiB5b3UgdGhpbmsgaXQncyBub3QsIHRoZW4gTUxFIHNob3VsZCBuZWl0aGVy IGJlIGRldmVsb3BlZCBpbiBST0xMIG5vcgo+Pj4gYmUgY29uc3RyYWluZWQgYnkgUlBMIGNvZGUt cG9pbnRzLCBtZXNzYWdlcyBvciBwcmluY2lwbGVzLgo+Pj4gCj4+PiAKPj4+IFRob21hcwo+Pj4g Cj4+Pj4gT24gNi8xNS8xMiA2OjE1IEFNLCAiVGhvbWFzIEhlaWRlIENsYXVzZW4iIDxpZXRmQHRo b21hc2NsYXVzZW4ub3JnPgo+Pj4+IHdyb3RlOgo+Pj4+IAo+Pj4+PiAKPj4+Pj4gT24gSnVuIDE1 LCAyMDEyLCBhdCAxNToxMiAsIE1pY2hhZWwgUmljaGFyZHNvbiB3cm90ZToKPj4+Pj4gCj4+Pj4+ PiAKPj4+Pj4+Pj4+Pj4gIlRob21hcyIgPT0gVGhvbWFzIEhlaWRlIENsYXVzZW4gPGlldGZAdGhv bWFzY2xhdXNlbi5vcmc+IHdyaXRlczoKPj4+Pj4+ICBUaG9tYXM+IE5vdCBzdXJlIGhvdyBmYW50 YXN0aWMgKG9yIG5vdCkgaXQgaXMgLSBpdCBpcyBub3QKPj4+Pj4+ICBUaG9tYXM+IGltbWVkaWF0 ZWx5IGNsZWFyIHRvIG1lIGhvdyB0aWVkIE1MRSBzaG91bGQgYmUgdG8gUlBMIC0gaWYKPj4+Pj4+ ICBUaG9tYXM+IGl0IHRydWx5IGFpbXMgYXQgYmVpbmcgZm9yIF9NRVNIXyBsaW5rIGVzdGFibGlz aG1lbnQsIHRoZW4KPj4+Pj4+ICBUaG9tYXM+IGl0IHdvdWxkIGFwcGVhciB0byBiZSBhIG11Y2gg bGFyZ2VyIHNjb3BlLCBhbmQgc2hvdWxkIG5vdCBiZQo+Pj4+Pj4gIFRob21hcz4gdGllZCBuYXJy b3dseSB0byBhIHNwZWNpYWwtcHVycG9zZSBwcm90b2NvbCdzIHR5cGUtc3BhY2UgKCYKPj4+Pj4+ ICBUaG9tYXM+IGNvbnZlbnRpb25zIGV0Yy4sIHRoYXQgZG8gbm90IGFwcGx5IHVuaXZlcnNhbGx5 KS4KPj4+Pj4+IAo+Pj4+Pj4gVGhvbWFzLCB5b3Ugd2lsbCBub3RlIHRoYXQ6Cj4+Pj4+PiAxKSBJ IHN1Z2dlc3RlZCBpdCBnbyB1bmRlciBJUHY2IElDTVAgZmlyc3QsIGFuZCBpZiB0aGVyZSB3YXMg c3VjaCBwdXNoCj4+Pj4+PiAgIGJhY2sgYWJvdXQgYWxsb2NhdGluZyBhIG5ldyB0eXBlLCB0aGF0 IFJQTCBjb3VsZCBhbGxvY2F0ZSBhCj4+Pj4+PiB0eXBlL2NvZGUuCj4+Pj4+PiAyKSBaaWdCZWUg YWxsaWFuY2UgKHRoZSBwcm9wb3NhbCksICpJUyogdXNpbmcgUlBMLgo+Pj4+Pj4gCj4+Pj4+IAo+ Pj4+PiBJbiB0aGF0IGNhc2UsIHRoZSBkcmFmdCBtdXN0IGJlIHZlcnkgbmFycm93bHkgc2NvcGVk IGFuZCB3cml0dGVuIHN1Y2gKPj4+Pj4gdGhhdCBpdCdzIGNsZWFyIHRoYXQgaXQncyBhcHBsaWNh YmxlIF9vbmx5XyB0byB0aGF0IGNvbnRleHQKPj4+Pj4gKHNwZWNpYWwtcHVycG9zZSBkZXBsb3lt ZW50cyBvZiBhIHNwZWNpYWwtcHVycG9zZSBwcm90b2NvbCksIGFuZAo+Pj4+PiBzcGVjaWZpY2Fs bHkgdG8gbm90IHByZXRlbmQgdG8gZG8gZ2VuZXJhbCBtZXNoIGxpbmsgZXN0YWJsaXNobWVudC4K Pj4+Pj4gCj4+Pj4+PiBJIHNlZSBydW5uaW5nIGl0IG92ZXIgVURQIHZlcnkgYXJjaGl0ZWN0dXJh bGx5IHN0cmFuZ2UuCj4+Pj4+IAo+Pj4+PiBJIGRvbid0Lgo+Pj4+PiAKPj4+Pj4gVGhvbWFzCj4+ Pj4+IAo+Pj4+Pj4gLS0gCj4+Pj4+PiBNaWNoYWVsIFJpY2hhcmRzb24gPG1jcitJRVRGQHNhbmRl bG1hbi5jYT4sIFNhbmRlbG1hbiBTb2Z0d2FyZSBXb3Jrcwo+Pj4+Pj4gSUVURiBST0xMIFdHIGNv LWNoYWlyLiAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvcm9sbC9jaGFydGVyLwo+ Pj4+Pj4gCj4+Pj4+IAo+Pj4+IAo+Pj4+IAo+PiAKPj4gCg== From richard.kelsey@ember.com Fri Jun 15 10:44:19 2012 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 7AB4D21F867B; Fri, 15 Jun 2012 10:44: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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSrlFGE4GzxL; Fri, 15 Jun 2012 10:44:18 -0700 (PDT) Received: from p01c11o149.mxlogic.net (p01c11o149.mxlogic.net [208.65.144.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9B88A21F864E; Fri, 15 Jun 2012 10:44:17 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO p01c11o149.mxlogic.net) by p01c11o149.mxlogic.net(mxl_mta-6.14.0-1) with ESMTP id 1747bdf4.5674f940.40732.00-564.102062.p01c11o149.mxlogic.net (envelope-from ); Fri, 15 Jun 2012 11:44:17 -0600 (MDT) X-MXL-Hash: 4fdb747102445f15-e59dbdcc1581da98a51caaa2df48e1b18d25f826 Received: from unknown [216.236.254.3] (EHLO usmail.ember.com) by p01c11o149.mxlogic.net(mxl_mta-6.14.0-1) over TLS secured channel with ESMTP id 1247bdf4.0.40401.00-379.101205.p01c11o149.mxlogic.net (envelope-from ); Fri, 15 Jun 2012 11:43:05 -0600 (MDT) X-MXL-Hash: 4fdb7429441ceccb-1840f6b5b4ab7b70f9090aa284514fb949903a7f Received: from kelsey-ws.hq.ember.com (192.168.81.75) by usmail.ember.com (192.168.80.105) with Microsoft SMTP Server id 14.2.283.3; Fri, 15 Jun 2012 13:42:57 -0400 Date: Fri, 15 Jun 2012 13:38:10 -0400 Message-ID: <87lijojx19.fsf@kelsey-ws.hq.ember.com> To: Thomas Heide Clausen In-Reply-To: <6EBA154B-EFDC-4E46-B04F-D86546B4F07E@thomasclausen.org> (message from Thomas Heide Clausen on Fri, 15 Jun 2012 18:59:18 +0200) From: Richard Kelsey X-Auto-Response-Suppress: DR, OOF, AutoReply References: <6EBA154B-EFDC-4E46-B04F-D86546B4F07E@thomasclausen.org> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [192.168.81.75] 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=2.0 cv=C9BeP3z+ c=1 sm=0 a=MYqPJgym4Kx47q1P90kooQ==:17 a] X-AnalysisOut: [=u0NvnAFnSA0A:10 a=OFb--ukilxYA:10 a=saA6nF2ZJaAA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=OQ_ktunLAAAA:8 a=pJo66KLIAAAA:8 a=HZJGGiqLA] X-AnalysisOut: [AAA:8 a=lt3peZ0jL1c_Qe6UbLgA:9 a=Qmq8LIWCQqsA:10 a=HeoGohO] X-AnalysisOut: [dMD0A:10] Cc: roll@ietf.org, 6lowpan@ietf.org, ipv6@ietf.org Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 17:44:20 -0000 Hi Thomas, As Don said, the intent is that MLE not be tied to RPL and that it be submitted as an AD-sponsored submission. I have spoken with Ralph about it on several occasions. We both would have preferred that MLE go through a WG, but there doesn't seem to be an appropriate one. If MLE were intended for use exclusively with ROLL (or MANET or 6LoWPAN), this wouldn't be an issue. Ralph and I discussed it again yesterday, and decided to go with an AD-sponsored submission. My plan was to add some clarifications to the draft before announcing it to the usual suspects (6lowpan, MANET, ROLL). This thread jumped the gun by a day or two. -Richard Kelsey > From: Thomas Heide Clausen > Date: Fri, 15 Jun 2012 18:59:18 +0200 > > Hi Don, > > On 15 Jun 2012, at 18:41, Don Sturek wrote: > > > Hi Thomas, > > > > I think our plan was to submit it to the Internet Area directly (Richard: > > That is from memory, am I correct?) > > > > If that's the case, then I think that it needs to be scoped > carefully: the design and direction of the work required would > (IMO) be very different if it aims narrowly for RPL, or broadly > for "MESH", and the text in the specification should be very > very clear as to this. > > If an AD sponsored submission is the intend, then I do honestly > not know what the proper way of shaping the process / forum for > discussions / framing of the specification would be, but I > would hope that an AD could chirp in (as you say INT, have you > discussed this with Brian or Ralph, and could you or either of > them let us know?) > > Note, I am not taking position for or against MLE at all - I > just want to ensure that a specification published be scoped so > as to not be constraining for domains for which it hasn't been > discussed. > > Thomas From ietf@thomasclausen.org Fri Jun 15 10:50:33 2012 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 CEA3121F8658; Fri, 15 Jun 2012 10:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.869 X-Spam-Level: X-Spam-Status: No, score=-0.869 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id feL3ql5p6Mmh; Fri, 15 Jun 2012 10:50:33 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5F89821F850B; Fri, 15 Jun 2012 10:50:33 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 41D125580D9; Fri, 15 Jun 2012 10:50:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C3BB91BE16A6; Fri, 15 Jun 2012 10:50:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.147.40.163] (37-8-181-55.coucou-networks.fr [37.8.181.55]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 5A5381BE16A5; Fri, 15 Jun 2012 10:50:32 -0700 (PDT) References: <6EBA154B-EFDC-4E46-B04F-D86546B4F07E@thomasclausen.org> <87lijojx19.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87lijojx19.fsf@kelsey-ws.hq.ember.com> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Fri, 15 Jun 2012 19:50:41 +0200 To: Richard Kelsey Cc: "" , "<6lowpan@ietf.org>" <6lowpan@ietf.org>, "" Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2012 17:50:34 -0000 Dear Richard, Thank you for the clarifications, I appreciate it. I look forward to the next version, which I will endeavor to review carefull= y with what you state below in mind. Best, Thomas --=20 Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees On 15 Jun 2012, at 19:38, Richard Kelsey wrote: > Hi Thomas, >=20 > As Don said, the intent is that MLE not be tied to RPL and that > it be submitted as an AD-sponsored submission. I have spoken > with Ralph about it on several occasions. We both would have > preferred that MLE go through a WG, but there doesn't seem to be > an appropriate one. If MLE were intended for use exclusively > with ROLL (or MANET or 6LoWPAN), this wouldn't be an issue. >=20 > Ralph and I discussed it again yesterday, and decided to go with > an AD-sponsored submission. My plan was to add some clarifications > to the draft before announcing it to the usual suspects (6lowpan, > MANET, ROLL). This thread jumped the gun by a day or two. >=20 > -Richard Kelsey >=20 >> From: Thomas Heide Clausen >> Date: Fri, 15 Jun 2012 18:59:18 +0200 >>=20 >> Hi Don, >>=20 >> On 15 Jun 2012, at 18:41, Don Sturek wrote: >>=20 >>> Hi Thomas, >>>=20 >>> I think our plan was to submit it to the Internet Area directly (Richard= : >>> That is from memory, am I correct?) >>>=20 >>=20 >> If that's the case, then I think that it needs to be scoped >> carefully: the design and direction of the work required would >> (IMO) be very different if it aims narrowly for RPL, or broadly >> for "MESH", and the text in the specification should be very >> very clear as to this. >>=20 >> If an AD sponsored submission is the intend, then I do honestly >> not know what the proper way of shaping the process / forum for >> discussions / framing of the specification would be, but I >> would hope that an AD could chirp in (as you say INT, have you >> discussed this with Brian or Ralph, and could you or either of >> them let us know?) >>=20 >> Note, I am not taking position for or against MLE at all - I >> just want to ensure that a specification published be scoped so >> as to not be constraining for domains for which it hasn't been >> discussed. >>=20 >> Thomas From dat@exegin.com Thu Jun 21 09:05:16 2012 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 4BD5B21F8738 for ; Thu, 21 Jun 2012 09:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fw63sY6d5le1 for ; Thu, 21 Jun 2012 09:05:15 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5419F21F866D for ; Thu, 21 Jun 2012 09:05:15 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so2370663pbc.31 for ; Thu, 21 Jun 2012 09:05:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=inG5Ll05yj0Ff6tKVbfZ+ACB6Pe+BpSStJXs6294GVA=; b=IGFzjmc55P9sPkChUDWe171roCfo518BIMp2E6a/P6WTlnUivp4EGT1zmNqvAQTP8N RjrOhQ34p7Jv7ZpDgNUmTzSEt41cE39YpgSdma2F3yR/kSJVkMkIAnz1f/CSVZ02wM4y NPNssbzo9+zIuhJFjMyOISOw91aACOTCPkB93hisE7G1xaNOf8haKKWWo8qKpztKbAof zlSDLBU+fOtjqldWFYd/4AvWEAW/N8weZ7xsps+XUkQncw1hpoPu5/T/KxMCqN4kipbt HT3uHhY7QmFOyCMRQ0Dri8e1BlkiJQWnKuiOwAg0WPScjGQ39NZtUYw49OzCZpjdJ12E uYUw== Received: by 10.68.234.104 with SMTP id ud8mr89202683pbc.163.1340294714844; Thu, 21 Jun 2012 09:05:14 -0700 (PDT) Received: from [172.16.1.52] ([184.71.143.130]) by mx.google.com with ESMTPS id pq5sm7456364pbb.30.2012.06.21.09.05.12 (version=SSLv3 cipher=OTHER); Thu, 21 Jun 2012 09:05:13 -0700 (PDT) Message-ID: <4FE34635.6080201@exegin.com> Date: Thu, 21 Jun 2012 09:05:09 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0) Gecko/20110922 Thunderbird/7.0 MIME-Version: 1.0 To: Jonathan Hui References: <4FC978A2.30202@exegin.com> <07C8A712-9390-4704-8823-5E38C9635DBC@cisco.com> In-Reply-To: <07C8A712-9390-4704-8823-5E38C9635DBC@cisco.com> Content-Type: multipart/alternative; boundary="------------040508060500040006010603" X-Gm-Message-State: ALoCoQlM0HcMfSBMvgrp+2LDR/THtnx8EhWWzG7+ysEZXCubB5FxFAek7WtK0jH9HpFqBDFJsCdh Cc: "roll@ietf.org" Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554 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 Jun 2012 16:05:16 -0000 This is a multi-part message in MIME format. --------------040508060500040006010603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Jonathan Sorry, for late response to your email. Consider the scenario where a DODAG root node supports two or more RPL instances under one prefix. Each instance providing different routing objectives (i.e. different objective functions). Potentially, the source-route to a destination under one instance can be different to the source-route to the same destination under a different instance. For example: Instance 1 could have a source-route R-->X-->Y-->D, while instance 2 could have a source-route R-->X-->Z-->D. Lets say node Y sent a Destination Unreachable ("Error in source-route") back to R, because D was unreachable from Y. How would R know which source-route needed repair and, consequently, which instance needed a DTSN update? Regards Dario On 01/06/2012 7:46 PM, Jonathan Hui wrote: > > I don't understand the need for knowing the RPLInstanceID when > handling an ICMP Destination Unreachable error. The SRH does not > follow any RPL Instance, just the IPv6 addresses listed in the SRH. > Receiving an ICMP Destination Unreachable error from a node S simply > means that S could not forward to the next IPv6 address in the SRH. > The inability of S to forward to the specified next hop would be true > regardless of what RPL Instance the SRH was constructed from. > > -- > Jonathan Hui > > On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote: > >> Yes, I noticed this as well. It is unfortunate because as you say, >> there is now no way to identify which instance a Error in SRH is for, >> and subsequently the root node can't just remove that routing entry >> in a specific instance. Instead it must either remove that entry from >> all instances or do nothing and wait for the next DAO to update the >> entry. >> >> Dario >> >> On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote: >>> >>> Hello, >>> >>> I have observed that the RPLInstanceID field from Source Routing >>> header (present in draft-ietf-6man-rpl-routing-header-07) was >>> removed in RFC6554. >>> >>> Are there particular reasons for this? This field is necessary at >>> the DODAG Root when it receives a Destination Unreachable with code >>> "Error in Source Routing Header" to identify the instance with the >>> problem (only if there are two instances with the same prefix and if >>> the node is Root in both of them). >>> >>> *Andreea Tecuceanu* >>> (Freescale Semiconductor) >>> >>> >>> >>> _______________________________________________ >>> 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 > --------------040508060500040006010603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Jonathan

Sorry, for late response to your email.

Consider the scenario where a DODAG root node supports two or more RPL instances under one prefix. Each instance providing different routing objectives (i.e. different objective functions). Potentially, the source-route to a destination under one instance can be different to the source-route to the same destination under a different instance. For example: Instance 1 could have a source-route R-->X-->Y-->D, while instance 2 could have a source-route R-->X-->Z-->D. Lets say node Y sent a Destination Unreachable ("Error in source-route") back to R, because D was unreachable from Y. How would R know which source-route needed repair and, consequently, which instance needed a DTSN update?

Regards
Dario

On 01/06/2012 7:46 PM, Jonathan Hui wrote:

I don't understand the need for knowing the RPLInstanceID when handling an ICMP Destination Unreachable error.  The SRH does not follow any RPL Instance, just the IPv6 addresses listed in the SRH.  Receiving an ICMP Destination Unreachable error from a node S simply means that S could not forward to the next IPv6 address in the SRH.  The inability of S to forward to the specified next hop would be true regardless of what RPL Instance the SRH was constructed from.

--
Jonathan Hui

On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote:

Yes, I noticed this as well. It is unfortunate because as you say, there is now no way to identify which instance a Error in SRH is for, and subsequently the root node can't just remove that routing entry in a specific instance. Instead it must either remove that entry from all instances or do nothing and wait for the next DAO to update the entry.

Dario

On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote:

Hello,

 

I have observed that the RPLInstanceID field from Source Routing header (present in  draft-ietf-6man-rpl-routing-header-07) was removed in RFC6554.

Are there particular reasons for this? This field is necessary at the DODAG Root when it receives a  Destination Unreachable with code "Error in Source Routing Header" to identify the instance with the problem (only if there are two instances with the same prefix and if the node is Root in both of them).

 

 

Andreea Tecuceanu
(Freescale Semiconductor)



_______________________________________________
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


--------------040508060500040006010603-- From prvs=512d68e0d=mukul@uwm.edu Thu Jun 21 09:51:12 2012 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 501D921F875C for ; Thu, 21 Jun 2012 09:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gDp-2fcSrq7z for ; Thu, 21 Jun 2012 09:51:11 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 908A521F866B for ; Thu, 21 Jun 2012 09:51:11 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAJ9Q409/AAAB/2dsb2JhbAA7CoVYsxkBAQEEAQEBIARHCwwPDgMEAQEDAg0ZAikoCAYTiAsLpxSJe4kABIEgig4QhHuBEgOIRoxkkAGCfYFB Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 9D37E12E3BC; Thu, 21 Jun 2012 11:51:10 -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 ESboU8fVvF+s; Thu, 21 Jun 2012 11:51:10 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 4676412E3BA; Thu, 21 Jun 2012 11:51:10 -0500 (CDT) Date: Thu, 21 Jun 2012 11:51:10 -0500 (CDT) From: Mukul Goyal To: Dario Tedeschi Message-ID: <1324724214.8004.1340297470152.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <4FE34635.6080201@exegin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554 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 Jun 2012 16:51:12 -0000 Could the answer be: all the instances that have Y in the source route to D= ? Thanks Mukul ----- Original Message ----- From: "Dario Tedeschi" To: "Jonathan Hui" Cc: roll@ietf.org Sent: Thursday, June 21, 2012 11:05:09 AM Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is m= issing in RFC6554 Hi Jonathan=20 Sorry, for late response to your email.=20 Consider the scenario where a DODAG root node supports two or more RPL inst= ances under one prefix. Each instance providing different routing objective= s (i.e. different objective functions). Potentially, the source-route to a = destination under one instance can be different to the source-route to the = same destination under a different instance. For example: Instance 1 could = have a source-route R-->X-->Y-->D, while instance 2 could have a source-rou= te R-->X-->Z-->D. Lets say node Y sent a Destination Unreachable ("Error in= source-route") back to R, because D was unreachable from Y. How would R kn= ow which source-route needed repair and, consequently, which instance neede= d a DTSN update?=20 Regards=20 Dario=20 On 01/06/2012 7:46 PM, Jonathan Hui wrote:=20 I don't understand the need for knowing the RPLInstanceID when handling an = ICMP Destination Unreachable error. =C2=A0The SRH does not follow any RPL I= nstance, just the IPv6 addresses listed in the SRH. =C2=A0Receiving an ICMP= Destination Unreachable error from a node S simply means that S could not = forward to the next IPv6 address in the SRH. =C2=A0The inability of S to fo= rward to the specified next hop would be true regardless of what RPL Instan= ce the SRH was constructed from.=20 --=20 Jonathan Hui=20 On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote:=20 Yes, I noticed this as well. It is unfortunate because as you say, there is= now no way to identify which instance a Error in SRH is for, and subsequen= tly the root node can't just remove that routing entry in a specific instan= ce. Instead it must either remove that entry from all instances or do nothi= ng and wait for the next DAO to update the entry.=20 Dario=20 On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote:=20 Hello,=20 =C2=A0=20 I have observed that the RPLInstanceID field from Source Routing header (pr= esent in =C2=A0draft-ietf-6man-rpl-routing-header-07) was removed in RFC655= 4.=20 Are there particular reasons for this? This field is necessary at the DODAG= Root when it receives a =C2=A0 Destination Unreachable with code "Error in= Source Routing Header" to identify the instance with the problem (only if = there are two instances with the same prefix and if the node is Root in bot= h of them).=20 =C2=A0=20 =C2=A0=20 Andreea Tecuceanu=20 (Freescale Semiconductor)=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll= =20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Thu Jun 21 10:09:00 2012 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 DEF8221F86DD for ; Thu, 21 Jun 2012 10:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ry4ntvokVAxk for ; Thu, 21 Jun 2012 10:08:57 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id BCD2021F86DB for ; Thu, 21 Jun 2012 10:08:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=13545; q=dns/txt; s=iport; t=1340298536; x=1341508136; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=VGH1b8YPZ8Ec6TvMyo7sSuVgJ68IYrgw5BrozH5zYmk=; b=jk3gLjwPCPcLWJGoCNxtPWU7TmdXsr7AIT9seKo/GI79Rq9kHcx7h1ds DiEp9ZHxlCmknPbb+adYQtbYmOmVs6yQJkD6nGUIa/O2EAnMquMRCUUam A50LGcg3RFtg1K27wK6QEap3WqeDEfNrV24S7LcOzt2XrG46lx1O40xUX 0=; X-IronPort-AV: E=Sophos;i="4.77,452,1336348800"; d="scan'208,217";a="94642784" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 21 Jun 2012 17:08:56 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id q5LH8usF029310 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 21 Jun 2012 17:08:56 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.99]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0298.004; Thu, 21 Jun 2012 12:08:56 -0500 From: "Pascal Thubert (pthubert)" To: Dario Tedeschi , Jonathan Hui Thread-Topic: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554 Thread-Index: AQHNT8erVPW3MkC8Mke3tJq8Hxbtt5cE/SMg Date: Thu, 21 Jun 2012 17:08:55 +0000 Deferred-Delivery: Thu, 21 Jun 2012 17:08:00 +0000 Message-ID: References: <4FC978A2.30202@exegin.com> <07C8A712-9390-4704-8823-5E38C9635DBC@cisco.com> <4FE34635.6080201@exegin.com> In-Reply-To: <4FE34635.6080201@exegin.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.88.114] x-tm-as-product-ver: SMEX-10.2.0.1135-7.000.1014-18986.003 x-tm-as-result: No--39.108200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD807D093FFxmbrcdx01ciscoc_" MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554 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 Jun 2012 17:09:00 -0000 --_000_E045AECD98228444A58C61C200AE1BD807D093FFxmbrcdx01ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Dario: The root might be using more than one path to go to a target via a node Y.= So even in a given instance there might be more than possible RH. What the root needs to know is that connectivity from Y to child Z is broke= n. Then it can clean up all instances that use Y->Z. Z can be found in the RH in the packet in error that should be passed with = the ICMP. But that's not too practical. It would be better if we had a new icmp error where Y could signal that con= nectivity to Z is lost. Cheers, Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Dar= io Tedeschi Sent: jeudi 21 juin 2012 18:05 To: Jonathan Hui Cc: roll@ietf.org Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is m= issing in RFC6554 Hi Jonathan Sorry, for late response to your email. Consider the scenario where a DODAG root node supports two or more RPL inst= ances under one prefix. Each instance providing different routing objective= s (i.e. different objective functions). Potentially, the source-route to a = destination under one instance can be different to the source-route to the = same destination under a different instance. For example: Instance 1 could = have a source-route R-->X-->Y-->D, while instance 2 could have a source-rou= te R-->X-->Z-->D. Lets say node Y sent a Destination Unreachable ("Error in= source-route") back to R, because D was unreachable from Y. How would R kn= ow which source-route needed repair and, consequently, which instance neede= d a DTSN update? Regards Dario On 01/06/2012 7:46 PM, Jonathan Hui wrote: I don't understand the need for knowing the RPLInstanceID when handling an = ICMP Destination Unreachable error. The SRH does not follow any RPL Instan= ce, just the IPv6 addresses listed in the SRH. Receiving an ICMP Destinati= on Unreachable error from a node S simply means that S could not forward to= the next IPv6 address in the SRH. The inability of S to forward to the sp= ecified next hop would be true regardless of what RPL Instance the SRH was = constructed from. -- Jonathan Hui On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote: Yes, I noticed this as well. It is unfortunate because as you say, there is= now no way to identify which instance a Error in SRH is for, and subsequen= tly the root node can't just remove that routing entry in a specific instan= ce. Instead it must either remove that entry from all instances or do nothi= ng and wait for the next DAO to update the entry. Dario On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote: Hello, I have observed that the RPLInstanceID field from Source Routing header (pr= esent in draft-ietf-6man-rpl-routing-header-07) was removed in RFC6554. Are there particular reasons for this? This field is necessary at the DODAG= Root when it receives a Destination Unreachable with code "Error in Sourc= e Routing Header" to identify the instance with the problem (only if there = are two instances with the same prefix and if the node is Root in both of t= hem). Andreea Tecuceanu (Freescale Semiconductor) _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_E045AECD98228444A58C61C200AE1BD807D093FFxmbrcdx01ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Dario:

 

The root might be usin= g more than one path  to go to a target via a node Y. So even in a giv= en instance there might be more than possible RH.

What the root needs to= know is that connectivity from Y to child Z is broken. Then it can clean u= p all instances that use Y->Z.

Z can be found in the = RH in the packet in error that should be passed with the ICMP. But thatR= 17;s not too practical.

It would be better if = we had a new icmp error where Y could signal that connectivity to Z is lost= .

 

Cheers,

 

Pascal

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.o= rg] On Behalf Of Dario Tedeschi
Sent: jeudi 21 juin 2012 18:05
To: Jonathan Hui
Cc: roll@ietf.org
Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Head= er is missing in RFC6554

 

Hi Jonathan

Sorry, for late response to your email.

Consider the scenario where a DODAG root node supports two or more RPL inst= ances under one prefix. Each instance providing different routing objective= s (i.e. different objective functions). Potentially, the source-route to a = destination under one instance can be different to the source-route to the same destination under a different= instance. For example: Instance 1 could have a source-route R-->X-->= Y-->D, while instance 2 could have a source-route R-->X-->Z-->D= . Lets say node Y sent a Destination Unreachable ("Error in source-route") back to R, because D was unreachable from Y. How wo= uld R know which source-route needed repair and, consequently, which instan= ce needed a DTSN update?

Regards
Dario

On 01/06/2012 7:46 PM, Jonathan Hui wrote:

 

I don't understand the need for knowing the RPLInsta= nceID when handling an ICMP Destination Unreachable error.  The SRH do= es not follow any RPL Instance, just the IPv6 addresses listed in the SRH. =  Receiving an ICMP Destination Unreachable error from a node S simply means that S could not forward to the next IPv6= address in the SRH.  The inability of S to forward to the specified n= ext hop would be true regardless of what RPL Instance the SRH was construct= ed from.

 

--

Jonathan Hui

 

On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote:



Yes, I noticed this as well. It is unfortunate becau= se as you say, there is now no way to identify which instance a Error in SR= H is for, and subsequently the root node can't just remove that routing ent= ry in a specific instance. Instead it must either remove that entry from all instances or do nothing and wait= for the next DAO to update the entry.

Dario

On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote:

Hello,<= /o:p>

 <= /o:p>

I have observed tha= t the RPLInstanceID field from Source Routing header (present in  draf= t-ietf-6man-rpl-routing-header-07) was removed in RFC6554.

Are there particula= r reasons for this? This field is necessary at the DODAG Root when it recei= ves a  Destination= Unreachable with code "Error in Source Routing Header" to identify the instance with the problem (only if there are = two instances with the same prefix and if the node is Root in both of them)= .

 <= /span>

 <= /o:p>

Andreea Tecuceanu=
(Freescale Semiconductor)




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

 

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

 

 

--_000_E045AECD98228444A58C61C200AE1BD807D093FFxmbrcdx01ciscoc_-- From mcr@sandelman.ca Thu Jun 21 19:04:43 2012 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 F3C4A21F8594; Thu, 21 Jun 2012 19:04:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQbnhuWxkoy5; Thu, 21 Jun 2012 19:04:42 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 24EEF21F8503; Thu, 21 Jun 2012 19:04:42 -0700 (PDT) Received: from sandelman.ca (wlan203.sandelman.ca [209.87.252.203]) by relay.sandelman.ca (Postfix) with ESMTPS id 6020F84D9; Thu, 21 Jun 2012 22:01:57 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id C4E9A98C2F; Thu, 21 Jun 2012 22:04:40 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B4B2A98C2D; Thu, 21 Jun 2012 22:04:40 -0400 (EDT) From: Michael Richardson To: Thomas Heide Clausen In-Reply-To: <6EBA154B-EFDC-4E46-B04F-D86546B4F07E@thomasclausen.org> References: <6EBA154B-EFDC-4E46-B04F-D86546B4F07E@thomasclausen.org> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 21 Jun 2012 22:04:40 -0400 Message-ID: <32622.1340330680@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: "" , "" , "<6lowpan@ietf.org>" <6lowpan@ietf.org> Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 02:04:43 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Thomas" =3D=3D Thomas Heide Clausen writes: Thomas> If an AD sponsored submission is the intend, then I do Thomas> honestly not know what the proper way of shaping the process Thomas> / forum for discussions / framing of the specification would Thomas> be, but I would hope that an AD could chirp in (as you say Thomas> INT, have you discussed this with Brian or Ralph, and could Thomas> you or either of them let us know?) AD sponsored submission is more than enough process. (it could go via independent submission easily too) Unless I missed something, the only proceedural thing MLE needs is a UDP port number, which is available via Expert Review.=20=20 Zigbee could publish MLE itself if it wanted to, but I understand that it may have application beyond the links defined/used by Zigbee. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT+PSuIqHRg3pndX9AQKmOwQAhpA3jf8KLaGjMRBBJNQAy4hPioTtK6GJ qBX8YHg4UgqmiyNG9Wx16VJXllI7AWkZCXF4TbtkD6ernrvtjXmBB80s76+mR0jx 0wNu5Nkl30qJLb4x86bBd+6tdHSOZFhwwe4tZBd2fir9noIOf29+FUQny0iby9er hMxborokYbs= =e+Xa -----END PGP SIGNATURE----- --=-=-=-- From d.sturek@att.net Thu Jun 21 19:14:11 2012 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 8CAAC21F8628 for ; Thu, 21 Jun 2012 19:14:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avvSlT1AP6lS for ; Thu, 21 Jun 2012 19:14:10 -0700 (PDT) Received: from nm25-vm0.access.bullet.mail.sp2.yahoo.com (nm25-vm0.access.bullet.mail.sp2.yahoo.com [98.139.44.184]) by ietfa.amsl.com (Postfix) with SMTP id 5ACA521F861E for ; Thu, 21 Jun 2012 19:14:10 -0700 (PDT) Received: from [98.139.44.105] by nm25.access.bullet.mail.sp2.yahoo.com with NNFMP; 22 Jun 2012 02:14:07 -0000 Received: from [98.139.44.65] by tm10.access.bullet.mail.sp2.yahoo.com with NNFMP; 22 Jun 2012 02:14:07 -0000 Received: from [127.0.0.1] by omp1002.access.mail.sp2.yahoo.com with NNFMP; 22 Jun 2012 02:14:07 -0000 X-Yahoo-Newman-Id: 55510.45140.bm@omp1002.access.mail.sp2.yahoo.com Received: (qmail 24075 invoked from network); 22 Jun 2012 02:14:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1340331246; bh=1T9TXREwILjiUYTpcIcNoRbDqxPSozdbBCwA39WZfSk=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=OI3uF87N7YVQeLLh6dTauI5pO+Flgur+WwrIMWnyugWwJx4Zd8ldjjhVlWEBKTDFlz+i38OsmZx/zx07dPdKKPE3l52xoXMc46L73enF4swSuEFX2OUiTYk73817NBLujz61D/ruAGnh47TqJsgCJoKvC/ftKyptMqRNcjd6K8c= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 4ynG0ZUVM1la0bjkc20jnm71uNG.6slAq.01eRt2J0URVxp dA7KELGmCeyy1TFHSlMZjI6UQOMDlN2LQZDKC14TVLcH1llW6ScEA5F3nRUm GyPsfbsq1Rwz9ylPq5p23VNGoy9MNnKRe2Pp7dQ07_OUpas2SlcZmYCC7pTu uAk1BP4w1eEK5sDhSYib1ZHt5m44bxmW7p1LUz8beb3tpUPbW8bkGIQEApYg 94Im8hr4rwKwW3euSJekT1YTf28_sha_JLej2A5_vh_uzvcCTu_zJCcuVP7V sm_KPlb.wXyQmwsBnIWbB6gG5zL23gwlFs0zQyy6gPMAGD1q1HB0VkIvixKc aHli5VbdJJjA.P26ULYkV6UR4U8QmERthCJhtVBczfd2GZb_UbItjMm964ez Hk2tT2MaUHW9fNgNUqIFQS0aPj2E2_lh5qXisXVlTyQ2QSNlfUg7GO1.zFMS pxYjI0rFw0MFMow1QEXmVVrSf5qcjTSvM4Hv02eHwHGWc11VElfZgLMP7Lzk n X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.192] (d.sturek@69.224.126.218 with login) by smtp106.sbc.mail.ne1.yahoo.com with SMTP; 21 Jun 2012 19:14:01 -0700 PDT User-Agent: Microsoft-MacOutlook/14.2.2.120421 Date: Thu, 21 Jun 2012 19:13:56 -0700 From: Don Sturek To: Michael Richardson , Thomas Heide Clausen Message-ID: Thread-Topic: [6lowpan] [Roll] draft-kelsey-intarea-mesh-link-establishment-03.txt In-Reply-To: <32622.1340330680@marajade.sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "" , "<6lowpan@ietf.org>" <6lowpan@ietf.org>, "" Subject: Re: [Roll] [6lowpan] draft-kelsey-intarea-mesh-link-establishment-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2012 02:14:11 -0000 We (the ZigBee Alliance) will request a port number to use with MLE. After discussion this week at the ZigBee Alliance members meeting, we will follow the AD sponsored draft route. We will elicit input from as many related IETF WG's who might be interested in MLE> We look forward to comments from 6LoWPAN, ROLL and others on the draft (including Thomas who has generously provided input already). Don On 6/21/12 7:04 PM, "Michael Richardson" wrote: > >>>>>> "Thomas" == Thomas Heide Clausen writes: > Thomas> If an AD sponsored submission is the intend, then I do > Thomas> honestly not know what the proper way of shaping the process > Thomas> / forum for discussions / framing of the specification would > Thomas> be, but I would hope that an AD could chirp in (as you say > Thomas> INT, have you discussed this with Brian or Ralph, and could > Thomas> you or either of them let us know?) > >AD sponsored submission is more than enough process. >(it could go via independent submission easily too) > >Unless I missed something, the only proceedural thing MLE needs is a UDP >port number, which is available via Expert Review. >Zigbee could publish MLE itself if it wanted to, but I understand that >it may have application beyond the links defined/used by Zigbee. > >-- >Michael Richardson , Sandelman Software Works >IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > From jonhui@cisco.com Thu Jun 21 22:54:57 2012 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 2E89611E8080 for ; Thu, 21 Jun 2012 22:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSuqpi0FJKuf for ; Thu, 21 Jun 2012 22:54:56 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 45ED221F85E0 for ; Thu, 21 Jun 2012 22:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=11363; q=dns/txt; s=iport; t=1340344496; x=1341554096; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=L4YT4mie3dkSydoa6pqk0K6Cay2AgJi1l0I/I3A169o=; b=PV84z9Q8+cmmESxbqagdX48nxM9M/NUHMCZW558cQzDmnYF3gNaIEhg+ BguoYx17upNRdelTBlrkxYhppDA90WgWuaTWrdQZyaoOUAIT6r0iMG+Pm qGXVvh9WRVs4XLTAalxTrJ1HxuQQZ9okM0QmEJcAd7H9pRMqfqkuoFQaL Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAL8H5E+rRDoH/2dsb2JhbAA7CoJFsx2BB4IYAQEBAwEBAQEPARQGQQsFCwsOCi4nMAYTIodkBAyaJ6AKBIsuEIUSYAOIR4xljhuBZoJ/gT8 X-IronPort-AV: E=Sophos;i="4.77,455,1336348800"; d="scan'208,217";a="47266992" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-3.cisco.com with ESMTP; 22 Jun 2012 05:54:54 +0000 Received: from sjc-vpn6-1052.cisco.com (sjc-vpn6-1052.cisco.com [10.21.124.28]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5M5srcu032527; Fri, 22 Jun 2012 05:54:54 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_D2541D89-182D-4B8B-B9AF-E22E3CA6D69F" From: Jonathan Hui In-Reply-To: <4FE34635.6080201@exegin.com> Date: Thu, 21 Jun 2012 22:54:53 -0700 Message-Id: <65511524-625D-4F29-9228-C60FD12BFFCC@cisco.com> References: <4FC978A2.30202@exegin.com> <07C8A712-9390-4704-8823-5E38C9635DBC@cisco.com> <4FE34635.6080201@exegin.com> To: Dario Tedeschi X-Mailer: Apple Mail (2.1278) Cc: "roll@ietf.org" Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554 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, 22 Jun 2012 05:54:57 -0000 --Apple-Mail=_D2541D89-182D-4B8B-B9AF-E22E3CA6D69F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Dario, The ICMP Error message will contain the IPv6 header of the = error-generating packet. If link A -> B is broken, the IPv6 Destination = Address will indicate B and the SRH will indicate A. My point is that if you want to clean up routes, you need to clean up = all routes that use A -> B, not just the particular Instance that you = used to generate the route and discover the error. -- Jonathan Hui On Jun 21, 2012, at 9:05 AM, Dario Tedeschi wrote: > Hi Jonathan >=20 > Sorry, for late response to your email.=20 >=20 > Consider the scenario where a DODAG root node supports two or more RPL = instances under one prefix. Each instance providing different routing = objectives (i.e. different objective functions). Potentially, the = source-route to a destination under one instance can be different to the = source-route to the same destination under a different instance. For = example: Instance 1 could have a source-route R-->X-->Y-->D, while = instance 2 could have a source-route R-->X-->Z-->D. Lets say node Y sent = a Destination Unreachable ("Error in source-route") back to R, because D = was unreachable from Y. How would R know which source-route needed = repair and, consequently, which instance needed a DTSN update? >=20 > Regards > Dario >=20 > On 01/06/2012 7:46 PM, Jonathan Hui wrote: >>=20 >>=20 >> I don't understand the need for knowing the RPLInstanceID when = handling an ICMP Destination Unreachable error. The SRH does not follow = any RPL Instance, just the IPv6 addresses listed in the SRH. Receiving = an ICMP Destination Unreachable error from a node S simply means that S = could not forward to the next IPv6 address in the SRH. The = inability of S to forward to the specified next hop would be true = regardless of what RPL Instance the SRH was constructed from. >>=20 >> -- >> Jonathan Hui >>=20 >> On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote: >>=20 >>> Yes, I noticed this as well. It is unfortunate because as you say, = there is now no way to identify which instance a Error in SRH is for, = and subsequently the root node can't just remove that routing entry in a = specific instance. Instead it must either remove that entry from all = instances or do nothing and wait for the next DAO to update the entry. >>>=20 >>> Dario >>>=20 >>> On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote: >>>>=20 >>>> Hello, >>>> =20 >>>> I have observed that the RPLInstanceID field from Source Routing = header (present in draft-ietf-6man-rpl-routing-header-07) was removed = in RFC6554. >>>> Are there particular reasons for this? This field is necessary at = the DODAG Root when it receives a Destination Unreachable with code = "Error in Source Routing Header" to identify the instance with the = problem (only if there are two instances with the same prefix and if the = node is Root in both of them). >>>> =20 >>>> =20 >>>> Andreea Tecuceanu >>>> (Freescale Semiconductor) >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 --Apple-Mail=_D2541D89-182D-4B8B-B9AF-E22E3CA6D69F Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

Hi Dario,

The ICMP Error message will contain the IPv6 header of the error-generating packet.  If link A -> B is broken, the IPv6 Destination Address will indicate B and the SRH will indicate A.

My point is that if you want to clean up routes, you need to clean up all routes that use A -> B, not just the particular Instance that you used to generate the route and discover the error.

--
Jonathan Hui

On Jun 21, 2012, at 9:05 AM, Dario Tedeschi wrote:

Hi Jonathan

Sorry, for late response to your email.

Consider the scenario where a DODAG root node supports two or more RPL instances under one prefix. Each instance providing different routing objectives (i.e. different objective functions). Potentially, the source-route to a destination under one instance can be different to the source-route to the same destination under a different instance. For example: Instance 1 could have a source-route R-->X-->Y-->D, while instance 2 could have a source-route R-->X-->Z-->D. Lets say node Y sent a Destination Unreachable ("Error in source-route") back to R, because D was unreachable from Y. How would R know which source-route needed repair and, consequently, which instance needed a DTSN update?

Regards
Dario

On 01/06/2012 7:46 PM, Jonathan Hui wrote:

I don't understand the need for knowing the RPLInstanceID when handling an ICMP Destination Unreachable error.  The SRH does not follow any RPL Instance, just the IPv6 addresses listed in the SRH.  Receiving an ICMP Destination Unreachable error from a node S simply means that S could not forward to the next IPv6 address in the SRH.  The inability of S to forward to the specified next hop would be true regardless of what RPL Instance the SRH was constructed from.

--
Jonathan Hui

On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote:

Yes, I noticed this as well. It is unfortunate because as you say, there is now no way to identify which instance a Error in SRH is for, and subsequently the root node can't just remove that routing entry in a specific instance. Instead it must either remove that entry from all instances or do nothing and wait for the next DAO to update the entry.

Dario

On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote:

Hello,

 

I have observed that the RPLInstanceID field from Source Routing header (present in  draft-ietf-6man-rpl-routing-header-07) was removed in RFC6554.

Are there particular reasons for this? This field is necessary at the DODAG Root when it receives a  Destination Unreachable with code "Error in Source Routing Header" to identify the instance with the problem (only if there are two instances with the same prefix and if the node is Root in both of them).

 

 

Andreea Tecuceanu
(Freescale Semiconductor)



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

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



--Apple-Mail=_D2541D89-182D-4B8B-B9AF-E22E3CA6D69F-- From c.chauvenet@watteco.com Fri Jun 22 03:13:13 2012 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 708A721F861D for ; Fri, 22 Jun 2012 03:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Li49Xkrlj7l4 for ; Fri, 22 Jun 2012 03:13:12 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id AA68621F861A for ; Fri, 22 Jun 2012 03:13:12 -0700 (PDT) Received: from mail81-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.23; Fri, 22 Jun 2012 10:11:43 +0000 Received: from mail81-tx2 (localhost [127.0.0.1]) by mail81-tx2-R.bigfish.com (Postfix) with ESMTP id 0ADD4360483; Fri, 22 Jun 2012 10:11:43 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT004.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -81 X-BigFish: VPS-81(zzbb2dI98dIc89bh542M1dbaI1432I1418I15caKJ14ffIzz1202hzz1033IL8275bh8275dhz2dh2a8h668h839hd25hf0ah) Received: from mail81-tx2 (localhost.localdomain [127.0.0.1]) by mail81-tx2 (MessageSwitch) id 1340359900516713_14829; Fri, 22 Jun 2012 10:11:40 +0000 (UTC) Received: from TX2EHSMHS028.bigfish.com (unknown [10.9.14.245]) by mail81-tx2.bigfish.com (Postfix) with ESMTP id 7B30F1400EF; Fri, 22 Jun 2012 10:11:40 +0000 (UTC) Received: from DBXPRD0510HT004.eurprd05.prod.outlook.com (157.56.252.165) by TX2EHSMHS028.bigfish.com (10.9.99.128) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 22 Jun 2012 10:11:40 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.215]) by DBXPRD0510HT004.eurprd05.prod.outlook.com ([10.255.67.167]) with mapi id 14.16.0164.004; Fri, 22 Jun 2012 10:13:03 +0000 From: C Chauvenet To: 'Abdussalam Baryun' , "Pascal Thubert (pthubert)" Thread-Topic: [Roll] Node Ability to Participate (NAP) Thread-Index: AQHNRIv/1FnSK8b/vEGEuTOnYY1xMpbvWQ0AgABw9YCAFmsNwA== Date: Fri, 22 Jun 2012 10:13:03 +0000 Message-ID: <97B69B30E0EF244B940B65EA541E3F2D02296E1C@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <1FFD6787-3529-462B-B59A-115ADC99B842@cisco.com> <13731.1338814785@marajade.sandelman.ca> <4787.1338995178@marajade.sandelman.ca> <17448.1339014690@marajade.sandelman.ca> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [82.241.54.131] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll Subject: Re: [Roll] Node Ability to Participate (NAP) 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, 22 Jun 2012 10:13:13 -0000 Hi,=20 Could RFC6551 (the ex-metric draft) help ? I think the metric container option could embed a constraint to adress the= NAP functionality you are describing=20 Best, C=E9dric. -----Message d'origine----- De=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de A= bdussalam Baryun Envoy=E9=A0: vendredi 8 juin 2012 05:48 =C0=A0: Pascal Thubert (pthubert) Cc=A0: roll; roll-owner Objet=A0: Re: [Roll] Node Ability to Participate (NAP) Hi Pascal, I was thinking of route-control enhancement, not network management, howeve= r, I agree it is an iteresting issue as well, you gave me a new point, than= ks, Abdussalam Baryun =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D On 6/7/12, Pascal Thubert (pthubert) wrote: > Hello Abdussalam: > > I'd say it is a great discussion that might end up impacting routing.=20 > But also basic network operations (DNS, DHCP ...) and services. > So where is the right place to start with? > Tthe COMA mailing list is starting about network management, and I'd=20 > have thought that your discussion could begin there. > > What do you think? > > > " > List address: coma@ietf.org > Archive: http://www.ietf.org/mail-archive/web/coma/ > To subscribe: https://www.ietf.org/mailman/listinfo/coma > > Purpose: This list is for the discussion related to the management of=20 > constrained networks and devices. The IETF so far has not developed=20 > specific technologies for the management of constrained networks.=20 > There is a need to understand the requirements for the management of=20 > such a constrained network and its devices. > " > > Cheers, > > Pascal > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > Of Abdussalam Baryun > Sent: jeudi 7 juin 2012 11:00 > To: roll > Cc: roll-owner > Subject: [Roll] Node Ability to Participate (NAP) > > +++++++++++++++++ Possible Duplication +++++++++++++++++++++++ > Hi All, > > I want to discuss is there a need to consider the node ability to=20 > participate (NAP) in LLN functions? > > I think that the node ability (considering; energy consumption issue,=20 > routing issue, and environment-event issue), it is good for some=20 > node-originators to know neighbor nodes/sinks ability ( NAP to-route,=20 > or NAP continue-to-route, or NAP to-survive, NAP to-store, NAP=20 > to-manage, or other abilities), but not sure if it is available in=20 > some of the ROLL or 6lowpan protocols, nor sure if it can make side=20 > effects to LLN performance. The node-ability can be useful if we have=20 > different devices capabilities and conditions. This knowledge-factor=20 > can be useful and may be included in some technique, or forwarding table = in the protocol specification. > > I want to know your advises and opinion, thanking you, > > Best regards > > Abdussalam Baryun, > University of Glamorgan, UK. > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D > < One may be wrong, or may be right, but it does not matter if we=20 > work together as a group to discuss and resolve all issues. IETF WGs=20 > are always right > > ********************************************************************** > ****************** This email and any attachments are confidential to=20 > the intended recipient and may also be privileged. If you are not the=20 > intended recipient please delete it from your system and notify the=20 > sender. The contents are comply to the IETF regulations, and WG=20 > procedures. You should not copy the email nor use it for any purpose=20 > other than IETF procedures' purposes. > ********************************************************************** > ******************* _______________________________________________ > 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 abdussalambaryun@gmail.com Fri Jun 22 13:54:58 2012 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 ECC1011E80C9; Fri, 22 Jun 2012 13:54: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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmwQsEosJs3E; Fri, 22 Jun 2012 13:54:57 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D7E3C11E80C7; Fri, 22 Jun 2012 13:54:56 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so1226464vbb.31 for ; Fri, 22 Jun 2012 13:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=on0C8nVMgAfO4V31apkRbQ+9xKVa/hTXBBvz7KRc5eg=; b=pZYqV1iSYOpfVhYtLm2eYhnROZYPdNjhpymZ9DshzUYLjTemOu9dGCpMqTc6dkk8wo gzsw3aBkf1YzQDAdi8kUe+Tymb/vVEEtCa87KGm1Vhc8rbGaR4RvxRgnyaQAdzbVmWdK fyjGJkolxvbWXJzn14aRita3DsQg3tfTNDwcZdrOKOKAnhYJ0mOzFXg4lN6E6EjicwzN xcFdvbCRkGkOAfXKnx+0Tnk/oFgPBbjm6CM9JVhUWu3n/Ar33RMlGrRUXsvE0NLqPluV PqHxAHkFHU5bofnXGK5e75DP2JknbUOg1vPqa3KK4+rvuCWNmeWpO4m8pblmdIbkqtGa Vk5Q== MIME-Version: 1.0 Received: by 10.52.65.145 with SMTP id x17mr1436385vds.117.1340398496057; Fri, 22 Jun 2012 13:54:56 -0700 (PDT) Received: by 10.220.211.72 with HTTP; Fri, 22 Jun 2012 13:54:55 -0700 (PDT) In-Reply-To: <97B69B30E0EF244B940B65EA541E3F2D02296E1C@DBXPRD0510MB395.eurprd05.prod.outlook.com> References: <1FFD6787-3529-462B-B59A-115ADC99B842@cisco.com> <13731.1338814785@marajade.sandelman.ca> <4787.1338995178@marajade.sandelman.ca> <17448.1339014690@marajade.sandelman.ca> <97B69B30E0EF244B940B65EA541E3F2D02296E1C@DBXPRD0510MB395.eurprd05.prod.outlook.com> Date: Fri, 22 Jun 2012 22:54:55 +0200 Message-ID: From: Abdussalam Baryun To: C Chauvenet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: manet , roll , 6lowpan <6lowpan@ietf.org> Subject: Re: [Roll] Node Ability to Participate (NAP) 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, 22 Jun 2012 20:54:58 -0000 Hi C=E9dric, I am writing the draft for NAP, and studying different approaches. Yes RFC6551 will help thanks, I see in may be used under the . I will try to update the ROLL WG in the coming weeks, with my final suggestions for this idea protocol. The general idea is that each node may get to a situation to advertise its *ability* limits for the network benefit, on the other hand, some nodes in some situation may request information about such *ability* for their benefit. I think the NAP idea and protocol can be used for LLN, MANET and other dynamic networks. I thank you again for you comments, Regards Abdussalam Baryun University of Glamorgan, UK =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D On 6/22/12, C Chauvenet wrote: > Hi, > > Could RFC6551 (the ex-metric draft) help ? > > I think the metric container option could embed a constraint to adress t= he > NAP functionality you are describing > > Best, > > C=E9dric. > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de > Abdussalam Baryun > Envoy=E9 : vendredi 8 juin 2012 05:48 > =C0 : Pascal Thubert (pthubert) > Cc : roll; roll-owner > Objet : Re: [Roll] Node Ability to Participate (NAP) > > Hi Pascal, > > I was thinking of route-control enhancement, not network management, > however, I agree it is an iteresting issue as well, you gave me a new poi= nt, > thanks, > > Abdussalam Baryun > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > On 6/7/12, Pascal Thubert (pthubert) wrote: >> Hello Abdussalam: >> >> I'd say it is a great discussion that might end up impacting routing. >> But also basic network operations (DNS, DHCP ...) and services. >> So where is the right place to start with? >> Tthe COMA mailing list is starting about network management, and I'd >> have thought that your discussion could begin there. >> >> What do you think? >> >> >> " >> List address: coma@ietf.org >> Archive: http://www.ietf.org/mail-archive/web/coma/ >> To subscribe: https://www.ietf.org/mailman/listinfo/coma >> >> Purpose: This list is for the discussion related to the management of >> constrained networks and devices. The IETF so far has not developed >> specific technologies for the management of constrained networks. >> There is a need to understand the requirements for the management of >> such a constrained network and its devices. >> " >> >> Cheers, >> >> Pascal >> >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> Of Abdussalam Baryun >> Sent: jeudi 7 juin 2012 11:00 >> To: roll >> Cc: roll-owner >> Subject: [Roll] Node Ability to Participate (NAP) >> >> +++++++++++++++++ Possible Duplication +++++++++++++++++++++++ >> Hi All, >> >> I want to discuss is there a need to consider the node ability to >> participate (NAP) in LLN functions? >> >> I think that the node ability (considering; energy consumption issue, >> routing issue, and environment-event issue), it is good for some >> node-originators to know neighbor nodes/sinks ability ( NAP to-route, >> or NAP continue-to-route, or NAP to-survive, NAP to-store, NAP >> to-manage, or other abilities), but not sure if it is available in >> some of the ROLL or 6lowpan protocols, nor sure if it can make side >> effects to LLN performance. The node-ability can be useful if we have >> different devices capabilities and conditions. This knowledge-factor >> can be useful and may be included in some technique, or forwarding table >> in the protocol specification. >> >> I want to know your advises and opinion, thanking you, >> >> Best regards >> >> Abdussalam Baryun, >> University of Glamorgan, UK. >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >> < One may be wrong, or may be right, but it does not matter if we >> work together as a group to discuss and resolve all issues. IETF WGs >> are always right > >> ********************************************************************** >> ****************** This email and any attachments are confidential to >> the intended recipient and may also be privileged. If you are not the >> intended recipient please delete it from your system and notify the >> sender. The contents are comply to the IETF regulations, and WG >> procedures. You should not copy the email nor use it for any purpose >> other than IETF procedures' purposes. >> ********************************************************************** >> ******************* _______________________________________________ >> 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 dat@exegin.com Fri Jun 29 08:48:57 2012 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 607EF21F878A for ; Fri, 29 Jun 2012 08:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRSPiZ3UzQbx for ; Fri, 29 Jun 2012 08:48:56 -0700 (PDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6545C21F86D1 for ; Fri, 29 Jun 2012 08:48:56 -0700 (PDT) Received: by pbcwy7 with SMTP id wy7so4878945pbc.31 for ; Fri, 29 Jun 2012 08:48:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=YfnRg5IOY+F/mrQJl95Zq5TXzQakTfhevMWUkaQVjj4=; b=OSpVPjDv/EYesDBDBYhE2GX9v/XqcawL15cyGNEhie2iVFoJAD2KXKGmQrhbIeWyHi TIrpqIzWJXNyBj50UL3yK2uu7XK6NmqtAly6UJJrNCehH/UFpERUs7x6PGMwmg7F7LHe 6hNawVG+hZOgd/I725CGJIkGORGZyZ/3CX0uNUSRbW2R+Yk3fsXdvQjTLlysDLsMqolU CSKlopowefQ33YLVS4AnXd940//fQiXe8Ym5HbeVshPw9Trq3SCPXRXbw1Ts1pKtGpQl 1iQAKPv6ZEZ+e4BhFo7bB9SrO4NWMF9YI7rPUXXL4y3ZL4C66k8Suu+7PhViyfKj5PYa bf2w== Received: by 10.68.217.40 with SMTP id ov8mr7440431pbc.131.1340984935931; Fri, 29 Jun 2012 08:48:55 -0700 (PDT) Received: from [10.0.0.92] (173-11-86-161-SFBA.hfc.comcastbusiness.net. [173.11.86.161]) by mx.google.com with ESMTPS id nh6sm5782095pbc.44.2012.06.29.08.48.53 (version=SSLv3 cipher=OTHER); Fri, 29 Jun 2012 08:48:54 -0700 (PDT) Message-ID: <4FEDCE65.2030208@exegin.com> Date: Fri, 29 Jun 2012 08:48:53 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jonathan Hui References: <4FC978A2.30202@exegin.com> <07C8A712-9390-4704-8823-5E38C9635DBC@cisco.com> <4FE34635.6080201@exegin.com> <65511524-625D-4F29-9228-C60FD12BFFCC@cisco.com> In-Reply-To: <65511524-625D-4F29-9228-C60FD12BFFCC@cisco.com> Content-Type: multipart/alternative; boundary="------------000001080503010607080802" X-Gm-Message-State: ALoCoQmoClCBptqr0jREhxluoofRX/LWaVrgbyFir6ZXQ5gwL2PZsLijcZZVEkdQZalFuVXEf2BB Cc: "roll@ietf.org" Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 15:48:57 -0000 This is a multi-part message in MIME format. --------------000001080503010607080802 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Jonathan I would agree if link A -> B existed in more than one instance. In my example however, the source route for the first RPL instance has link Y -> D while the second instance has link Z -> D. How does R inform D to resend its DAO for only the first instance if only Y -> D is broken? Dario On 12-06-21 10:54 PM, Jonathan Hui wrote: > > Hi Dario, > > The ICMP Error message will contain the IPv6 header of the > error-generating packet. If link A -> B is broken, the IPv6 > Destination Address will indicate B and the SRH will indicate A. > > My point is that if you want to clean up routes, you need to clean up > all routes that use A -> B, not just the particular Instance that you > used to generate the route and discover the error. > > -- > Jonathan Hui > > On Jun 21, 2012, at 9:05 AM, Dario Tedeschi wrote: > >> Hi Jonathan >> >> Sorry, for late response to your email. >> >> Consider the scenario where a DODAG root node supports two or more >> RPL instances under one prefix. Each instance providing different >> routing objectives (i.e. different objective functions). Potentially, >> the source-route to a destination under one instance can be different >> to the source-route to the same destination under a different >> instance. For example: Instance 1 could have a source-route >> R-->X-->Y-->D, while instance 2 could have a source-route >> R-->X-->Z-->D. Lets say node Y sent a Destination Unreachable ("Error >> in source-route") back to R, because D was unreachable from Y. How >> would R know which source-route needed repair and, consequently, >> which instance needed a DTSN update? >> >> Regards >> Dario >> >> On 01/06/2012 7:46 PM, Jonathan Hui wrote: >>> >>> I don't understand the need for knowing the RPLInstanceID when >>> handling an ICMP Destination Unreachable error. The SRH does not >>> follow any RPL Instance, just the IPv6 addresses listed in the SRH. >>> Receiving an ICMP Destination Unreachable error from a node S >>> simply means that S could not forward to the next IPv6 address in >>> the SRH. The inability of S to forward to the specified next hop >>> would be true regardless of what RPL Instance the SRH was >>> constructed from. >>> >>> -- >>> Jonathan Hui >>> >>> On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote: >>> >>>> Yes, I noticed this as well. It is unfortunate because as you say, >>>> there is now no way to identify which instance a Error in SRH is >>>> for, and subsequently the root node can't just remove that routing >>>> entry in a specific instance. Instead it must either remove that >>>> entry from all instances or do nothing and wait for the next DAO to >>>> update the entry. >>>> >>>> Dario >>>> >>>> On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote: >>>>> >>>>> Hello, >>>>> >>>>> I have observed that the RPLInstanceID field from Source Routing >>>>> header (present in draft-ietf-6man-rpl-routing-header-07) was >>>>> removed in RFC6554. >>>>> >>>>> Are there particular reasons for this? This field is necessary at >>>>> the DODAG Root when it receives a Destination Unreachable with >>>>> code "Error in Source Routing Header" to identify the instance >>>>> with the problem (only if there are two instances with the same >>>>> prefix and if the node is Root in both of them). >>>>> >>>>> *Andreea Tecuceanu* >>>>> (Freescale Semiconductor) >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >> > --------------000001080503010607080802 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Jonathan

I would agree if link A -> B existed in more than one instance. In my example however, the source route for the first RPL instance has link Y -> D while the second instance has link Z -> D. How does R inform D to resend its DAO for only the first instance if only Y -> D is broken?

Dario


On 12-06-21 10:54 PM, Jonathan Hui wrote:

Hi Dario,

The ICMP Error message will contain the IPv6 header of the error-generating packet.  If link A -> B is broken, the IPv6 Destination Address will indicate B and the SRH will indicate A.

My point is that if you want to clean up routes, you need to clean up all routes that use A -> B, not just the particular Instance that you used to generate the route and discover the error.

--
Jonathan Hui

On Jun 21, 2012, at 9:05 AM, Dario Tedeschi wrote:

Hi Jonathan

Sorry, for late response to your email.

Consider the scenario where a DODAG root node supports two or more RPL instances under one prefix. Each instance providing different routing objectives (i.e. different objective functions). Potentially, the source-route to a destination under one instance can be different to the source-route to the same destination under a different instance. For example: Instance 1 could have a source-route R-->X-->Y-->D, while instance 2 could have a source-route R-->X-->Z-->D. Lets say node Y sent a Destination Unreachable ("Error in source-route") back to R, because D was unreachable from Y. How would R know which source-route needed repair and, consequently, which instance needed a DTSN update?

Regards
Dario

On 01/06/2012 7:46 PM, Jonathan Hui wrote:

I don't understand the need for knowing the RPLInstanceID when handling an ICMP Destination Unreachable error.  The SRH does not follow any RPL Instance, just the IPv6 addresses listed in the SRH.  Receiving an ICMP Destination Unreachable error from a node S simply means that S could not forward to the next IPv6 address in the SRH.  The inability of S to forward to the specified next hop would be true regardless of what RPL Instance the SRH was constructed from.

--
Jonathan Hui

On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote:

Yes, I noticed this as well. It is unfortunate because as you say, there is now no way to identify which instance a Error in SRH is for, and subsequently the root node can't just remove that routing entry in a specific instance. Instead it must either remove that entry from all instances or do nothing and wait for the next DAO to update the entry.

Dario

On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote:

Hello,

 

I have observed that the RPLInstanceID field from Source Routing header (present in  draft-ietf-6man-rpl-routing-header-07) was removed in RFC6554.

Are there particular reasons for this? This field is necessary at the DODAG Root when it receives a  Destination Unreachable with code "Error in Source Routing Header" to identify the instance with the problem (only if there are two instances with the same prefix and if the node is Root in both of them).

 

 

Andreea Tecuceanu
(Freescale Semiconductor)



_______________________________________________
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




--------------000001080503010607080802-- From jonhui@cisco.com Fri Jun 29 08:56:19 2012 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 A0CF621F87C9 for ; Fri, 29 Jun 2012 08:56:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GO1x5OR-4vxZ for ; Fri, 29 Jun 2012 08:56:18 -0700 (PDT) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 471B021F87D2 for ; Fri, 29 Jun 2012 08:56:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jonhui@cisco.com; l=15143; q=dns/txt; s=iport; t=1340985378; x=1342194978; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=I3geIf/UZtwXBoj4p9Obpy55naeSFRBXlYCzMvS8XtE=; b=UTSQFz7OGmAspSzQGtW/El0kXTkZwdO6snJ+3iBkcPQNZKh1/GGymzQ2 7ZWsjcT8M1Z1pXklam/ouB0RLElFQptLLaWcG3FgNXwtfrlmcYEDtbmXv 8SfhQi3ROYg4RRYUO6n6rZ2qG5m89nu1d4t+wIQVztd2TnUjHZTSx/MwK 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADTP7U+rRDoH/2dsb2JhbAA7CoJFtBKBB4IYAQEBAwEBAQEPARQGQQsFCwsOCi4nMAYTIodkBAybWqBIBIs3EIUaYAOISoxpjh2BZoJ/gT8 X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208,217";a="50500371" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 29 Jun 2012 15:56:18 +0000 Received: from sjc-vpn3-252.cisco.com (sjc-vpn3-252.cisco.com [10.21.64.252]) by mtv-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id q5TFuHsW001629; Fri, 29 Jun 2012 15:56:17 GMT Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_B706E957-2874-43E6-ADBE-35065A4A8DA2" From: Jonathan Hui In-Reply-To: <4FEDCE65.2030208@exegin.com> Date: Fri, 29 Jun 2012 08:56:17 -0700 Message-Id: References: <4FC978A2.30202@exegin.com> <07C8A712-9390-4704-8823-5E38C9635DBC@cisco.com> <4FE34635.6080201@exegin.com> <65511524-625D-4F29-9228-C60FD12BFFCC@cisco.com> <4FEDCE65.2030208@exegin.com> To: Dario Tedeschi X-Mailer: Apple Mail (2.1278) Cc: "roll@ietf.org" Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 15:56:20 -0000 --Apple-Mail=_B706E957-2874-43E6-ADBE-35065A4A8DA2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Dario, The ICMPv6 Destination Unreachable error will come from Y and indicate Y = -> D is broken. Any RPL Path that utilizes Y -> D (again, regardless of = the RPL Instance) will require repair. The DAG Root can choose to issue = a DTSN update for any RPL Instance that utilizes link Y -> D in a = downward path. It can even choose the RPL Instance that it uses to = route the original packet. Because the ICMPv6 Destination Unreachable = message encapsulates the error-generating packet (both the SRH and = original packet), it has all the information it needs. -- Jonathan Hui On Jun 29, 2012, at 8:48 AM, Dario Tedeschi wrote: > Hi Jonathan >=20 > I would agree if link A -> B existed in more than one instance. In my = example however, the source route for the first RPL instance has link Y = -> D while the second instance has link Z -> D. How does R inform D to = resend its DAO for only the first instance if only Y -> D is broken? >=20 > Dario >=20 >=20 > On 12-06-21 10:54 PM, Jonathan Hui wrote: >>=20 >>=20 >> Hi Dario, >>=20 >> The ICMP Error message will contain the IPv6 header of the = error-generating packet. If link A -> B is broken, the IPv6 Destination = Address will indicate B and the SRH will indicate A. >>=20 >> My point is that if you want to clean up routes, you need to clean up = all routes that use A -> B, not just the particular Instance that you = used to generate the route and discover the error. >>=20 >> -- >> Jonathan Hui >>=20 >> On Jun 21, 2012, at 9:05 AM, Dario Tedeschi wrote: >>=20 >>> Hi Jonathan >>>=20 >>> Sorry, for late response to your email.=20 >>>=20 >>> Consider the scenario where a DODAG root node supports two or more = RPL instances under one prefix. Each instance providing different = routing objectives (i.e. different objective functions). Potentially, = the source-route to a destination under one instance can be different to = the source-route to the same destination under a different instance. For = example: Instance 1 could have a source-route R-->X-->Y-->D, while = instance 2 could have a source-route R-->X-->Z-->D. Lets say node Y sent = a Destination Unreachable ("Error in source-route") back to R, because D = was unreachable from Y. How would R know which source-route needed = repair and, consequently, which instance needed a DTSN update? >>>=20 >>> Regards >>> Dario >>>=20 >>> On 01/06/2012 7:46 PM, Jonathan Hui wrote: >>>>=20 >>>>=20 >>>> I don't understand the need for knowing the RPLInstanceID when = handling an ICMP Destination Unreachable error. The SRH does not follow = any RPL Instance, just the IPv6 addresses listed in the SRH. Receiving = an ICMP Destination Unreachable error from a node S simply means that S = could not forward to the next IPv6 address in the SRH. The inability of = S to forward to the specified next hop would be true regardless of what = RPL Instance the SRH was constructed from. >>>>=20 >>>> -- >>>> Jonathan Hui >>>>=20 >>>> On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote: >>>>=20 >>>>> Yes, I noticed this as well. It is unfortunate because as you say, = there is now no way to identify which instance a Error in SRH is for, = and subsequently the root node can't just remove that routing entry in a = specific instance. Instead it must either remove that entry from all = instances or do nothing and wait for the next DAO to update the entry. >>>>>=20 >>>>> Dario >>>>>=20 >>>>> On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote: >>>>>>=20 >>>>>> Hello, >>>>>> =20 >>>>>> I have observed that the RPLInstanceID field from Source Routing = header (present in draft-ietf-6man-rpl-routing-header-07) was removed = in RFC6554. >>>>>> Are there particular reasons for this? This field is necessary at = the DODAG Root when it receives a Destination Unreachable with code = "Error in Source Routing Header" to identify the instance with the = problem (only if there are two instances with the same prefix and if the = node is Root in both of them). >>>>>> =20 >>>>>> =20 >>>>>> Andreea Tecuceanu >>>>>> (Freescale Semiconductor) >>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>=20 >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_B706E957-2874-43E6-ADBE-35065A4A8DA2 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=iso-8859-1

Hi Dario,

The ICMPv6 Destination Unreachable error will come from Y and indicate Y -> D is broken.  Any RPL Path that utilizes Y -> D (again, regardless of the RPL Instance) will require repair.  The DAG Root can choose to issue a DTSN update for any RPL Instance that utilizes link Y -> D in a downward path.  It can even choose the RPL Instance that it uses to route the original packet.  Because the ICMPv6 Destination Unreachable message encapsulates the error-generating packet (both the SRH and original packet), it has all the information it needs.

--
Jonathan Hui

On Jun 29, 2012, at 8:48 AM, Dario Tedeschi wrote:

Hi Jonathan

I would agree if link A -> B existed in more than one instance. In my example however, the source route for the first RPL instance has link Y -> D while the second instance has link Z -> D. How does R inform D to resend its DAO for only the first instance if only Y -> D is broken?

Dario


On 12-06-21 10:54 PM, Jonathan Hui wrote:

Hi Dario,

The ICMP Error message will contain the IPv6 header of the error-generating packet.  If link A -> B is broken, the IPv6 Destination Address will indicate B and the SRH will indicate A.

My point is that if you want to clean up routes, you need to clean up all routes that use A -> B, not just the particular Instance that you used to generate the route and discover the error.

--
Jonathan Hui

On Jun 21, 2012, at 9:05 AM, Dario Tedeschi wrote:

Hi Jonathan

Sorry, for late response to your email.

Consider the scenario where a DODAG root node supports two or more RPL instances under one prefix. Each instance providing different routing objectives (i.e. different objective functions). Potentially, the source-route to a destination under one instance can be different to the source-route to the same destination under a different instance. For example: Instance 1 could have a source-route R-->X-->Y-->D, while instance 2 could have a source-route R-->X-->Z-->D. Lets say node Y sent a Destination Unreachable ("Error in source-route") back to R, because D was unreachable from Y. How would R know which source-route needed repair and, consequently, which instance needed a DTSN update?

Regards
Dario

On 01/06/2012 7:46 PM, Jonathan Hui wrote:

I don't understand the need for knowing the RPLInstanceID when handling an ICMP Destination Unreachable error.  The SRH does not follow any RPL Instance, just the IPv6 addresses listed in the SRH.  Receiving an ICMP Destination Unreachable error from a node S simply means that S could not forward to the next IPv6 address in the SRH.  The inability of S to forward to the specified next hop would be true regardless of what RPL Instance the SRH was constructed from.

--
Jonathan Hui

On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote:

Yes, I noticed this as well. It is unfortunate because as you say, there is now no way to identify which instance a Error in SRH is for, and subsequently the root node can't just remove that routing entry in a specific instance. Instead it must either remove that entry from all instances or do nothing and wait for the next DAO to update the entry.

Dario

On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote:

Hello,

 

I have observed that the RPLInstanceID field from Source Routing header (present in  draft-ietf-6man-rpl-routing-header-07) was removed in RFC6554.

Are there particular reasons for this? This field is necessary at the DODAG Root when it receives a  Destination Unreachable with code "Error in Source Routing Header" to identify the instance with the problem (only if there are two instances with the same prefix and if the node is Root in both of them).

 

 

Andreea Tecuceanu
(Freescale Semiconductor)



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

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





--Apple-Mail=_B706E957-2874-43E6-ADBE-35065A4A8DA2-- From gnawali@cs.uh.edu Fri Jun 29 09:22:05 2012 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 07E6B21F877A for ; Fri, 29 Jun 2012 09:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.377 X-Spam-Level: X-Spam-Status: No, score=-5.377 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_26=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7W-KJi4CwQIN for ; Fri, 29 Jun 2012 09:22:04 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id BFEE521F86A5 for ; Fri, 29 Jun 2012 09:22:03 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 3606D23CAB5 for ; Fri, 29 Jun 2012 11:22:00 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id siPefawbJYt0 for ; Fri, 29 Jun 2012 11:21:55 -0500 (CDT) Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id D8C2B23CA8F for ; Fri, 29 Jun 2012 11:21:55 -0500 (CDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by it.cs.uh.edu (Postfix) with ESMTP id 1060F2A280C0 for ; Fri, 29 Jun 2012 11:21:07 -0500 (CDT) Received: by dacx6 with SMTP id x6so4760342dac.31 for ; Fri, 29 Jun 2012 09:21:58 -0700 (PDT) Received: by 10.68.193.195 with SMTP id hq3mr7853704pbc.30.1340986917952; Fri, 29 Jun 2012 09:21:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.9.202 with HTTP; Fri, 29 Jun 2012 09:21:36 -0700 (PDT) In-Reply-To: References: <4FD137A4.3080801@innovationslab.net> From: Omprakash Gnawali Date: Fri, 29 Jun 2012 09:21:36 -0700 Message-ID: To: Don Sturek Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Brian Haberman , roll , Stiemerling Martin , Michael Richardson Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 16:22:05 -0000 Do we have a resolution on this topic - how to select OF+metric to be used? - om_p On Mon, Jun 11, 2012 at 1:27 PM, Don Sturek wrote: > Hi Brian, > > From our experience implementing RPL and MrHOF, all devices in a RPL > instance MUST implement the same OF. > > I think this is why there is so much discussion on the reflector on how t= o > convey the OF to the prospective joining devices. > > Don > > > On 6/7/12 4:22 PM, "Brian Haberman" wrote: > >>On 6/7/12 6:12 PM, Omprakash Gnawali wrote: >>> On Thu, Jun 7, 2012 at 4:49 PM, Pascal Thubert (pthubert) >>> =A0wrote: >>>> >>>> On Jun 6, 2012, at 10:43 AM 6/6/12, Philip Levis wrote: >>>> >>>>> Responses inline. >>>>> >>>>> On Jun 4, 2012, at 9:31 AM, Ralph Droms wrote: >>>>> >>>>>>> >>>>>> >>>>>> My question here is why a single objective function "MRHOF" is >>>>>> defined to use several different metrics. =A0My understanding is >>>>>> that any specific RPL instance will use one metric as its >>>>>> "selected metric" for MRHOF. =A0Another way to organize the >>>>>> objective functions would be to define a different OF number >>>>>> for each metric, binding the OF number to the selected metric. >>>>> >>>>> This was a design decision made early in RPL. There were two >>>>> options: OFs are metric-specific, or OFs can be general with >>>>> respect to metrics. The design team concluded the second approach >>>>> was better, as the former would lead to a possibly huge number of >>>>> OFs that would be hard to manage. >>>> >>>> Now that a real OF has actually been designed and specified, >>>> perhaps this would be a good time to reconfirm that design >>>> decision. >>>> >>>> Given that MRHOF is a pretty general objective function, and works >>>> over 5 (or perhaps 3) metrics, 16 bits would seem to provide plenty >>>> of code points for metric-specific OFs. >>>> >>>> A bigger issue, I think, is expressing the semantics or behavior of >>>> an OF in its OCP. =A0I read section 18.6 of RFC 6550 to indicate that >>>> a node will use information including the OF (as indicated by the >>>> OCP) to compare against the node's policy for joining a DODAG. =A0As >>>> an aside, is there a reason why a node would choose to join a >>>> specific DODAG within a RPL Instance and on what basis would it >>>> make that choice? =A0Anyway, wouldn't the selected metric =A0used by >>>> MRHOF in a particular RPL Instance be a useful parameter for the >>>> policy rules? =A0For example, I can imagine a node preferring to join >>>> a RPL Instance providing minimal latency over one providing best >>>> ETX. =A0If the OCP is metric-specific, that selected metric will be >>>> immediately available for the policy rules. >>>> >>>> >>>> [Pascal] I agree with Ralph here. I fail to be convinced that there >>>> will an explosion of OCPs if we fail to factorize the metrics. But >>>> I see how the device implementation can be simplified if the OCP >>>> says it all. Also, we do not want to force a device that implements >>>> MRHOF to have to implement all metrics in the I-D. Conversely, say >>>> we extend MrHof to other metrics with further work, wouldn't it >>>> become OCP 2 anyway? I wouldn't mind blocking OCP 1..9 for current >>>> and future MrHof metric variations. >>> >>> Just one clarification - MRHOF does not require the devices to >>> support all the metrics listed in the I-D. All it says is it must >>> implement at least one metric. >> >>Excuse the pedantic question, but won't there be an issue if half the >>devices in an RPL instance implement one metric and the other half >>implement a different metric? =A0This would seem to force users to select >>all their devices based on which metric they want to use. >> >>Regards, >>Brian >> >>_______________________________________________ >>Roll mailing list >>Roll@ietf.org >>https://www.ietf.org/mailman/listinfo/roll > > From dat@exegin.com Fri Jun 29 09:33:07 2012 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 CCFB721F8780 for ; Fri, 29 Jun 2012 09:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjrEzer6agch for ; Fri, 29 Jun 2012 09:33:06 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5912421F86A8 for ; Fri, 29 Jun 2012 09:33:06 -0700 (PDT) Received: by dacx6 with SMTP id x6so4772759dac.31 for ; Fri, 29 Jun 2012 09:33:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:x-gm-message-state; bh=c8UtHi7CZZ7umTT1l7z2TASus5Il4miUTerz+HFbbpM=; b=VK34YEdDefv11FprDse8CF9lUCOIBtLrlDPb8iizxPDjBY/9sHL7asQyoEQjaS0Tn4 iVSF5zX4GfH+nA9jwoE8i1Ygu4MUlD6q3x6jSOQTraYDDjWIHrVx9PwfG/x7KcuAjzSC Y03xD25TTMg+cw46h5sM2YCdRAvSybAxgxCWIne5hiwy/KBAtSiUeQfpnqJKEE+p4afa N0lIg1GGJb3f2+rkL2lpOdIIrM+QnRuneFMfJccN+wn2NpL0/qpo0twh6qkEMNfD/inr 3qEJEnOQxGBKiygxORAtsJXZvsoFvuD36wY/tw8d9MGBOnPk1ocLcPhw7YNiP7BKweep HJ8g== Received: by 10.66.86.165 with SMTP id q5mr1777235paz.72.1340987586012; Fri, 29 Jun 2012 09:33:06 -0700 (PDT) Received: from ?IPv6:2001:470:67:2cc:9c81:aaf0:67b6:e544? ([2001:470:67:2cc:9c81:aaf0:67b6:e544]) by mx.google.com with ESMTPS id tj4sm5886690pbc.33.2012.06.29.09.33.04 (version=SSLv3 cipher=OTHER); Fri, 29 Jun 2012 09:33:05 -0700 (PDT) Message-ID: <4FEDD8BC.7070600@exegin.com> Date: Fri, 29 Jun 2012 09:33:00 -0700 From: Dario Tedeschi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: Jonathan Hui References: <4FC978A2.30202@exegin.com> <07C8A712-9390-4704-8823-5E38C9635DBC@cisco.com> <4FE34635.6080201@exegin.com> <65511524-625D-4F29-9228-C60FD12BFFCC@cisco.com> <4FEDCE65.2030208@exegin.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080404000300050301070408" X-Gm-Message-State: ALoCoQmMiylUpFkOILDRVY57Qd6Cp/E3nRRRnBDylxZVZVwFOVZHpxI8q01TIn9V38eY/vtfQrD7 Cc: "roll@ietf.org" Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 16:33:08 -0000 This is a multi-part message in MIME format. --------------080404000300050301070408 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ok, I think I've got it. That's similar to what Mukul suggested: "all the instances that have Y in the source route to D" However, I still think it's a bit unfortunate from an implementation perspective. Thank you for the explanation. Dario On 12-06-29 08:56 AM, Jonathan Hui wrote: > > Hi Dario, > > The ICMPv6 Destination Unreachable error will come from Y and indicate > Y -> D is broken. Any RPL Path that utilizes Y -> D (again, > regardless of the RPL Instance) will require repair. The DAG Root can > choose to issue a DTSN update for any RPL Instance that utilizes link > Y -> D in a downward path. It can even choose the RPL Instance that > it uses to route the original packet. Because the ICMPv6 Destination > Unreachable message encapsulates the error-generating packet (both the > SRH and original packet), it has all the information it needs. > > -- > Jonathan Hui > > On Jun 29, 2012, at 8:48 AM, Dario Tedeschi wrote: > >> Hi Jonathan >> >> I would agree if link A -> B existed in more than one instance. In my >> example however, the source route for the first RPL instance has link >> Y -> D while the second instance has link Z -> D. How does R inform D >> to resend its DAO for only the first instance if only Y -> D is broken? >> >> Dario >> >> >> On 12-06-21 10:54 PM, Jonathan Hui wrote: >>> >>> Hi Dario, >>> >>> The ICMP Error message will contain the IPv6 header of the >>> error-generating packet. If link A -> B is broken, the IPv6 >>> Destination Address will indicate B and the SRH will indicate A. >>> >>> My point is that if you want to clean up routes, you need to clean >>> up all routes that use A -> B, not just the particular Instance that >>> you used to generate the route and discover the error. >>> >>> -- >>> Jonathan Hui >>> >>> On Jun 21, 2012, at 9:05 AM, Dario Tedeschi wrote: >>> >>>> Hi Jonathan >>>> >>>> Sorry, for late response to your email. >>>> >>>> Consider the scenario where a DODAG root node supports two or more >>>> RPL instances under one prefix. Each instance providing different >>>> routing objectives (i.e. different objective functions). >>>> Potentially, the source-route to a destination under one instance >>>> can be different to the source-route to the same destination under >>>> a different instance. For example: Instance 1 could have a >>>> source-route R-->X-->Y-->D, while instance 2 could have a >>>> source-route R-->X-->Z-->D. Lets say node Y sent a Destination >>>> Unreachable ("Error in source-route") back to R, because D was >>>> unreachable from Y. How would R know which source-route needed >>>> repair and, consequently, which instance needed a DTSN update? >>>> >>>> Regards >>>> Dario >>>> >>>> On 01/06/2012 7:46 PM, Jonathan Hui wrote: >>>>> >>>>> I don't understand the need for knowing the RPLInstanceID when >>>>> handling an ICMP Destination Unreachable error. The SRH does not >>>>> follow any RPL Instance, just the IPv6 addresses listed in the >>>>> SRH. Receiving an ICMP Destination Unreachable error from a node >>>>> S simply means that S could not forward to the next IPv6 address >>>>> in the SRH. The inability of S to forward to the specified next >>>>> hop would be true regardless of what RPL Instance the SRH was >>>>> constructed from. >>>>> >>>>> -- >>>>> Jonathan Hui >>>>> >>>>> On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote: >>>>> >>>>>> Yes, I noticed this as well. It is unfortunate because as you >>>>>> say, there is now no way to identify which instance a Error in >>>>>> SRH is for, and subsequently the root node can't just remove that >>>>>> routing entry in a specific instance. Instead it must either >>>>>> remove that entry from all instances or do nothing and wait for >>>>>> the next DAO to update the entry. >>>>>> >>>>>> Dario >>>>>> >>>>>> On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I have observed that the RPLInstanceID field from Source Routing >>>>>>> header (present in draft-ietf-6man-rpl-routing-header-07) was >>>>>>> removed in RFC6554. >>>>>>> >>>>>>> Are there particular reasons for this? This field is necessary >>>>>>> at the DODAG Root when it receives a Destination Unreachable >>>>>>> with code "Error in Source Routing Header" to identify the >>>>>>> instance with the problem (only if there are two instances with >>>>>>> the same prefix and if the node is Root in both of them). >>>>>>> >>>>>>> *Andreea Tecuceanu* >>>>>>> (Freescale Semiconductor) >>>>>>> >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>>> >>>> >>> >> > --------------080404000300050301070408 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ok, I think I've got it. That's similar to what Mukul suggested: "all the instances that have Y in the source route to D"
 
However, I still think it's a bit unfortunate from an implementation perspective.

Thank you for the explanation.

Dario

On 12-06-29 08:56 AM, Jonathan Hui wrote:

Hi Dario,

The ICMPv6 Destination Unreachable error will come from Y and indicate Y -> D is broken.  Any RPL Path that utilizes Y -> D (again, regardless of the RPL Instance) will require repair.  The DAG Root can choose to issue a DTSN update for any RPL Instance that utilizes link Y -> D in a downward path.  It can even choose the RPL Instance that it uses to route the original packet.  Because the ICMPv6 Destination Unreachable message encapsulates the error-generating packet (both the SRH and original packet), it has all the information it needs.

--
Jonathan Hui

On Jun 29, 2012, at 8:48 AM, Dario Tedeschi wrote:

Hi Jonathan

I would agree if link A -> B existed in more than one instance. In my example however, the source route for the first RPL instance has link Y -> D while the second instance has link Z -> D. How does R inform D to resend its DAO for only the first instance if only Y -> D is broken?

Dario


On 12-06-21 10:54 PM, Jonathan Hui wrote:

Hi Dario,

The ICMP Error message will contain the IPv6 header of the error-generating packet.  If link A -> B is broken, the IPv6 Destination Address will indicate B and the SRH will indicate A.

My point is that if you want to clean up routes, you need to clean up all routes that use A -> B, not just the particular Instance that you used to generate the route and discover the error.

--
Jonathan Hui

On Jun 21, 2012, at 9:05 AM, Dario Tedeschi wrote:

Hi Jonathan

Sorry, for late response to your email.

Consider the scenario where a DODAG root node supports two or more RPL instances under one prefix. Each instance providing different routing objectives (i.e. different objective functions). Potentially, the source-route to a destination under one instance can be different to the source-route to the same destination under a different instance. For example: Instance 1 could have a source-route R-->X-->Y-->D, while instance 2 could have a source-route R-->X-->Z-->D. Lets say node Y sent a Destination Unreachable ("Error in source-route") back to R, because D was unreachable from Y. How would R know which source-route needed repair and, consequently, which instance needed a DTSN update?

Regards
Dario

On 01/06/2012 7:46 PM, Jonathan Hui wrote:

I don't understand the need for knowing the RPLInstanceID when handling an ICMP Destination Unreachable error.  The SRH does not follow any RPL Instance, just the IPv6 addresses listed in the SRH.  Receiving an ICMP Destination Unreachable error from a node S simply means that S could not forward to the next IPv6 address in the SRH.  The inability of S to forward to the specified next hop would be true regardless of what RPL Instance the SRH was constructed from.

--
Jonathan Hui

On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote:

Yes, I noticed this as well. It is unfortunate because as you say, there is now no way to identify which instance a Error in SRH is for, and subsequently the root node can't just remove that routing entry in a specific instance. Instead it must either remove that entry from all instances or do nothing and wait for the next DAO to update the entry.

Dario

On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote:

Hello,

 

I have observed that the RPLInstanceID field from Source Routing header (present in  draft-ietf-6man-rpl-routing-header-07) was removed in RFC6554.

Are there particular reasons for this? This field is necessary at the DODAG Root when it receives a  Destination Unreachable with code "Error in Source Routing Header" to identify the instance with the problem (only if there are two instances with the same prefix and if the node is Root in both of them).

 

 

Andreea Tecuceanu
(Freescale Semiconductor)



_______________________________________________
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







--------------080404000300050301070408-- From johui@cisco.com Fri Jun 29 09:50:27 2012 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 F0BCF21F8800 for ; Fri, 29 Jun 2012 09:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.135 X-Spam-Level: X-Spam-Status: No, score=-7.135 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvwqjzLV9x+9 for ; Fri, 29 Jun 2012 09:50:22 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7E22921F87ED for ; Fri, 29 Jun 2012 09:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=johui@cisco.com; l=18715; q=dns/txt; s=iport; t=1340988613; x=1342198213; h=subject:references:content-transfer-encoding:from: in-reply-to:message-id:date:to:cc:mime-version; bh=oXViC96bCV7Rg9RQrVnSHqFje0uy/RkomeSVUlFASCg=; b=iDASR0Ra3QAzp/51Kb3cw67JbNORt6epxnCJDb4zLx5Hw40GqAWImszB vfBPCgi0FhFLiyA4rMjrmlVqstDFWfGk4sPMPpRkquESDiy30nItcumHD GOUs4QNaNO0djonX2poMFcPjBhAT8OKLmUL7U6LbzUV+MEZXJGJyZpkKI Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhEGAGrb7U+tJV2b/2dsb2JhbAA7CoJFgxWwewKBB4IYAQEBAwEBAQEPARAEBkELBQsCAQgOCioCAicwAQEEEyKHZAULm2CNGZMnBIs3EAqEXjJgA4gXM4xpjh2BZoJ/gT8 X-IronPort-AV: E=Sophos;i="4.77,498,1336348800"; d="scan'208,217";a="97356419" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 29 Jun 2012 16:50:12 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id q5TGoCpl030935; Fri, 29 Jun 2012 16:50:12 GMT Received: from xmb-rcd-207.cisco.com ([72.163.62.214]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 29 Jun 2012 11:50:12 -0500 Received: from 72.163.62.214 ([72.163.62.214]) by XMB-RCD-207.cisco.com ([72.163.62.214]) with Microsoft Exchange Server HTTP-DAV ; Fri, 29 Jun 2012 16:50:12 +0000 References: <4FC978A2.30202@exegin.com> <07C8A712-9390-4704-8823-5E38C9635DBC@cisco.com> <4FE34635.6080201@exegin.com> <65511524-625D-4F29-9228-C60FD12BFFCC@cisco.com> <4FEDCE65.2030208@exegin.com> <4FEDD8BC.7070600@exegin.com> Content-Transfer-Encoding: 7bit From: "Jonathan Hui (johui)" Content-Type: multipart/alternative; boundary="Apple-Mail-F0671A94-BE1C-4B33-A654-7B61B87DBB59"; charset="iso-8859-1" Thread-Topic: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554 Thread-Index: Ac1WF0ADaRFzNiXPTYWnsed+AoVG+g== In-Reply-To: <4FEDD8BC.7070600@exegin.com> Message-ID: Date: Fri, 29 Jun 2012 09:50:06 -0700 To: "Dario Tedeschi" MIME-Version: 1.0 (1.0) X-OriginalArrivalTime: 29 Jun 2012 16:50:12.0747 (UTC) FILETIME=[4059B5B0:01CD5617] X-Mailman-Approved-At: Fri, 29 Jun 2012 10:23:12 -0700 Cc: roll@ietf.org Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 16:50:28 -0000 --Apple-Mail-F0671A94-BE1C-4B33-A654-7B61B87DBB59 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It doesn't have to be all. As mentioned in my previous mail, you can target= the specific RPL Instance by inspecting the original packet header in the I= CMP error payload. -- Jonathan Hui On Jun 29, 2012, at 9:33 AM, "Dario Tedeschi" wrote: > Ok, I think I've got it. That's similar to what Mukul suggested: "all the i= nstances that have Y in the source route to D" > =20 > However, I still think it's a bit unfortunate from an implementation persp= ective. >=20 > Thank you for the explanation. >=20 > Dario >=20 > On 12-06-29 08:56 AM, Jonathan Hui wrote: >>=20 >>=20 >> Hi Dario, >>=20 >> The ICMPv6 Destination Unreachable error will come from Y and indicate Y -= > D is broken. Any RPL Path that utilizes Y -> D (again, regardless of the R= PL Instance) will require repair. The DAG Root can choose to issue a DTSN u= pdate for any RPL Instance that utilizes link Y -> D in a downward path. It= can even choose the RPL Instance that it uses to route the original packet.= Because the ICMPv6 Destination Unreachable message encapsulates the error-= generating packet (both the SRH and original packet), it has all the informa= tion it needs. >>=20 >> -- >> Jonathan Hui >>=20 >> On Jun 29, 2012, at 8:48 AM, Dario Tedeschi wrote: >>=20 >>> Hi Jonathan >>>=20 >>> I would agree if link A -> B existed in more than one instance. In my ex= ample however, the source route for the first RPL instance has link Y -> D w= hile the second instance has link Z -> D. How does R inform D to resend its D= AO for only the first instance if only Y -> D is broken? >>>=20 >>> Dario >>>=20 >>>=20 >>> On 12-06-21 10:54 PM, Jonathan Hui wrote: >>>>=20 >>>>=20 >>>> Hi Dario, >>>>=20 >>>> The ICMP Error message will contain the IPv6 header of the error-genera= ting packet. If link A -> B is broken, the IPv6 Destination Address will in= dicate B and the SRH will indicate A. >>>>=20 >>>> My point is that if you want to clean up routes, you need to clean up a= ll routes that use A -> B, not just the particular Instance that you used to= generate the route and discover the error. >>>>=20 >>>> -- >>>> Jonathan Hui >>>>=20 >>>> On Jun 21, 2012, at 9:05 AM, Dario Tedeschi wrote: >>>>=20 >>>>> Hi Jonathan >>>>>=20 >>>>> Sorry, for late response to your email.=20 >>>>>=20 >>>>> Consider the scenario where a DODAG root node supports two or more RPL= instances under one prefix. Each instance providing different routing objec= tives (i.e. different objective functions). Potentially, the source-route to= a destination under one instance can be different to the source-route to th= e same destination under a different instance. For example: Instance 1 could= have a source-route R-->X-->Y-->D, while instance 2 could have a source-rou= te R-->X-->Z-->D. Lets say node Y sent a Destination Unreachable ("Error in s= ource-route") back to R, because D was unreachable from Y. How would R know w= hich source-route needed repair and, consequently, which instance needed a D= TSN update? >>>>>=20 >>>>> Regards >>>>> Dario >>>>>=20 >>>>> On 01/06/2012 7:46 PM, Jonathan Hui wrote: >>>>>>=20 >>>>>>=20 >>>>>> I don't understand the need for knowing the RPLInstanceID when handli= ng an ICMP Destination Unreachable error. The SRH does not follow any RPL I= nstance, just the IPv6 addresses listed in the SRH. Receiving an ICMP Desti= nation Unreachable error from a node S simply means t= hat S could not forward to the next IPv6 address in the SRH. The inability o= f S to forward to the specified next hop would be true regardless of what RP= L Instance the SRH was constructed from. >>>>>>=20 >>>>>> -- >>>>>> Jonathan Hui >>>>>>=20 >>>>>> On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote: >>>>>>=20 >>>>>>> Yes, I noticed this as well. It is unfortunate because as you say, t= here is now no way to identify which instance a Error in SRH is for, and sub= sequently the root node can't just remove that routing entry in a specific i= nstance. Instead it must either remove that entry from all instances or do n= othing and wait for the next DAO to update the entry. >>>>>>>=20 >>>>>>> Dario >>>>>>>=20 >>>>>>> On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote: >>>>>>>>=20 >>>>>>>> Hello, >>>>>>>> =20 >>>>>>>> I have observed that the RPLInstanceID field from Source Routing he= ader (present in draft-ietf-6man-rpl-routing-header-07) was removed in RFC6= 554. >>>>>>>> Are there particular reasons for this? This field is necessary at t= he DODAG Root when it receives a Destination Unreachable with code "Error i= n Source Routing Header" to identify the instance with the problem (only if t= here are two instances with the same prefix and if the node is Root in both o= f them). >>>>>>>> =20 >>>>>>>> =20 >>>>>>>> Andreea Tecuceanu >>>>>>>> (Freescale Semiconductor) >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> Roll mailing list >>>>>>>> Roll@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Roll mailing list >>>>>>> Roll@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 >=20 --Apple-Mail-F0671A94-BE1C-4B33-A654-7B61B87DBB59 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
It doesn't have to be all.  As mentioned in my previous mail, you can target the specific RPL Instance by inspecting the original packet header in the ICMP error payload.

--
Jonathan Hui

On Jun 29, 2012, at 9:33 AM, "Dario Tedeschi" <dat@exegin.com> wrote:

Ok, I think I've got it. That's similar to what Mukul suggested: "all the instances that have Y in the source route to D"
 
However, I still think it's a bit unfortunate from an implementation perspective.

Thank you for the explanation.

Dario

On 12-06-29 08:56 AM, Jonathan Hui wrote:

Hi Dario,

The ICMPv6 Destination Unreachable error will come from Y and indicate Y -> D is broken.  Any RPL Path that utilizes Y -> D (again, regardless of the RPL Instance) will require repair.  The DAG Root can choose to issue a DTSN update for any RPL Instance that utilizes link Y -> D in a downward path.  It can even choose the RPL Instance that it uses to route the original packet.  Because the ICMPv6 Destination Unreachable message encapsulates the error-generating packet (both the SRH and original packet), it has all the information it needs.

--
Jonathan Hui

On Jun 29, 2012, at 8:48 AM, Dario Tedeschi wrote:

Hi Jonathan

I would agree if link A -> B existed in more than one instance. In my example however, the source route for the first RPL instance has link Y -> D while the second instance has link Z -> D. How does R inform D to resend its DAO for only the first instance if only Y -> D is broken?

Dario


On 12-06-21 10:54 PM, Jonathan Hui wrote:

Hi Dario,

The ICMP Error message will contain the IPv6 header of the error-generating packet.  If link A -> B is broken, the IPv6 Destination Address will indicate B and the SRH will indicate A.

My point is that if you want to clean up routes, you need to clean up all routes that use A -> B, not just the particular Instance that you used to generate the route and discover the error.

--
Jonathan Hui

On Jun 21, 2012, at 9:05 AM, Dario Tedeschi wrote:

Hi Jonathan

Sorry, for late response to your email.

Consider the scenario where a DODAG root node supports two or more RPL instances under one prefix. Each instance providing different routing objectives (i.e. different objective functions). Potentially, the source-route to a destination under one instance can be different to the source-route to the same destination under a different instance. For example: Instance 1 could have a source-route R-->X-->Y-->D, while instance 2 could have a source-route R-->X-->Z-->D. Lets say node Y sent a Destination Unreachable ("Error in source-route") back to R, because D was unreachable from Y. How would R know which source-route needed repair and, consequently, which instance needed a DTSN update?

Regards
Dario

On 01/06/2012 7:46 PM, Jonathan Hui wrote:

I don't understand the need for knowing the RPLInstanceID when handling an ICMP Destination Unreachable error.  The SRH does not follow any RPL Instance, just the IPv6 addresses listed in the SRH.  Receiving an ICMP Destination Unreachable error from a node S simply means that S could not forward to the next IPv6 address in the SRH.  The inability of S to forward to the specified next hop would be true regardless of what RPL Instance the SRH was constructed from.

--
Jonathan Hui

On Jun 1, 2012, at 7:21 PM, Dario Tedeschi wrote:

Yes, I noticed this as well. It is unfortunate because as you say, there is now no way to identify which instance a Error in SRH is for, and subsequently the root node can't just remove that routing entry in a specific instance. Instead it must either remove that entry from all instances or do nothing and wait for the next DAO to update the entry.

Dario

On 30/05/2012 1:58 AM, Tecuceanu Andreea-Dana-B10623 wrote:

Hello,

 

I have observed that the RPLInstanceID field from Source Routing header (present in  draft-ietf-6man-rpl-routing-header-07) was removed in RFC6554.

Are there particular reasons for this? This field is necessary at the DODAG Root when it receives a  Destination Unreachable with code "Error in Source Routing Header" to identify the instance with the problem (only if there are two instances with the same prefix and if the node is Root in both of them).

 

 

Andreea Tecuceanu
(Freescale Semiconductor)



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

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







--Apple-Mail-F0671A94-BE1C-4B33-A654-7B61B87DBB59-- From trakadasp@yahoo.gr Fri Jun 29 10:43:28 2012 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 19F5621F8639 for ; Fri, 29 Jun 2012 10:43:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_26=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0cxgMT33le9e for ; Fri, 29 Jun 2012 10:43:27 -0700 (PDT) Received: from nm9-vm0.bullet.mail.ird.yahoo.com (nm9-vm0.bullet.mail.ird.yahoo.com [77.238.189.197]) by ietfa.amsl.com (Postfix) with SMTP id A806321F87E0 for ; Fri, 29 Jun 2012 10:43:26 -0700 (PDT) Received: from [77.238.189.54] by nm9.bullet.mail.ird.yahoo.com with NNFMP; 29 Jun 2012 17:43:22 -0000 Received: from [212.82.108.113] by tm7.bullet.mail.ird.yahoo.com with NNFMP; 29 Jun 2012 17:43:22 -0000 Received: from [127.0.0.1] by omp1022.mail.ird.yahoo.com with NNFMP; 29 Jun 2012 17:43:22 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 245729.88151.bm@omp1022.mail.ird.yahoo.com Received: (qmail 81484 invoked by uid 60001); 29 Jun 2012 17:43:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.gr; s=s1024; t=1340991802; bh=Y48cNBO0yvIxImYfhQ1RMiqB4teed64bqzt4kr9dsd4=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=v9zSpjKeDncWw+wMRBPoTDNPSh1prVHyUa8uZCsEhdr0eH0sovVzN70w/mWXQQnvwFa02/fa+ApavrWr1h7IAoXMgMm0kGHj1qxpg8YE5l96VuNjwAKgbJ7hAnKZJUGoDi01/HrZjJmPIuu2OHMoLUK860IZwAjHjOHCT1iopFs= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.gr; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type; b=3XVEwWv6BS+kDiVapUth/EhhSV/+whFBTBLBNqI4C0RvYh/Ey2sbcEIVcTkyxGd6ObqgBXhbmhqVADSJEIfNQIWTDHpAVPWE08tXn91hGfjDdQCWH7qhZB5gWoUdCLyyqvtQOI5F6AGBk1bE37VVSyiEyip6iDRCz+Fxaf9gCrg=; X-YMail-OSG: BwE2jygVM1lPS640tnCsamS99wlhBNDhwS3IlWt_6Yf5C23 ATzV6JIaeOfOuttGriawC0qwjePS.Uqw5P3hw_xciFgyrYJYr1wfKW_0RmLk oPFVrUGRPXil9nh5pZC89jiaUBR4EYS9k6_2ClwAf0JMb3rEwT91VbBPEeiX yl4KxPZP0Cw5_cUPYqh0dC1zHTe1k9Cv2lugeTZDznbaU207F82AbqMsm4ti P4jv7LDR34apV3A8BDGwQdtTBmhiZadA0d6rAizi6ZBph.9dfOEYIaaKvcjU 7p5t6_sTSwbPNaP_UncrtALCqThwreAkVCBTv0F66G0P_BtYFUl2zufdCqRF wBfH2eZEaqa3PNWywgNGWRPsngUWmhypXsSon2eq6Sy14ve0NZiqGhwdNi_. GC77ddUMwjki.o9iyc_uTGRNRPiiKqKT2k88- Received: from [213.249.12.179] by web29605.mail.ird.yahoo.com via HTTP; Fri, 29 Jun 2012 18:43:22 BST X-Mailer: YahooMailWebService/0.8.118.349524 Message-ID: <1340991802.79739.yext-apple-iphone@web29605.mail.ird.yahoo.com> Date: Fri, 29 Jun 2012 18:43:22 +0100 (BST) From: Panos Trakadas To: Omprakash Gnawali MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-557664637-497515277-1340991802=:79739" Cc: Stiemerling Martin , Brian Haberman , roll , Michael Richardson Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Panos Trakadas List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 17:43:28 -0000 ---557664637-497515277-1340991802=:79739 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Well, IMO it depends on the specific user requirements set by the root node= . =0AIt could be a nice idea to investigate the metrics (and techniques lik= e hysteresis or composition) that would commonly be used in each one of the= application areas that RPL is targeting (more as a proposition/guideline f= or the developers). =0ATo be honest, we have already started reading the re= spective RFCs and the AMI draft to figure out the appropriate metrics per a= pplication domain in order to include them in the next version of metrics-c= omposition draft.=0APanos=0A=0A=0AOn 29 Jun 2012, at 19:21, Omprakash Gnawa= li wrote:=0A=0ADo we have a resolution on this topic - = how to select OF+metric to be used?=0A=0A- om_p=0A=0AOn Mon, Jun 11, 2012 a= t 1:27 PM, Don Sturek wrote:=0AHi Brian,=0A=0AFrom our e= xperience implementing RPL and MrHOF, all devices in a RPL=0Ainstance MUST = implement the same OF.=0A=0AI think this is why there is so much discussion= on the reflector on how to=0Aconvey the OF to the prospective joining devi= ces.=0A=0ADon=0A=0A=0AOn 6/7/12 4:22 PM, "Brian Haberman" wrote:=0A=0AOn 6/7/12 6:12 PM, Omprakash Gnawali wrote:=0AOn Thu,= Jun 7, 2012 at 4:49 PM, Pascal Thubert (pthubert)=0A = wrote:=0A=0AOn Jun 6, 2012, at 10:43 AM 6/6/12, Philip Levis wrote:=0A=0ARe= sponses inline.=0A=0AOn Jun 4, 2012, at 9:31 AM, Ralph Droms wrote:=0A=0A= =0A=0AMy question here is why a single objective function "MRHOF" is=0Adefi= ned to use several different metrics. My understanding is=0Athat any speci= fic RPL instance will use one metric as its=0A"selected metric" for MRHOF. = Another way to organize the=0Aobjective functions would be to define a dif= ferent OF number=0Afor each metric, binding the OF number to the selected m= etric.=0A=0AThis was a design decision made early in RPL. There were two=0A= options: OFs are metric-specific, or OFs can be general with=0Arespect to m= etrics. The design team concluded the second approach=0Awas better, as the = former would lead to a possibly huge number of=0AOFs that would be hard to = manage.=0A=0ANow that a real OF has actually been designed and specified,= =0Aperhaps this would be a good time to reconfirm that design=0Adecision.= =0A=0AGiven that MRHOF is a pretty general objective function, and works=0A= over 5 (or perhaps 3) metrics, 16 bits would seem to provide plenty=0Aof co= de points for metric-specific OFs.=0A=0AA bigger issue, I think, is express= ing the semantics or behavior of=0Aan OF in its OCP. I read section 18.6 o= f RFC 6550 to indicate that=0Aa node will use information including the OF = (as indicated by the=0AOCP) to compare against the node's policy for joinin= g a DODAG. As=0Aan aside, is there a reason why a node would choose to joi= n a=0Aspecific DODAG within a RPL Instance and on what basis would it=0Amak= e that choice? Anyway, wouldn't the selected metric used by=0AMRHOF in a = particular RPL Instance be a useful parameter for the=0Apolicy rules? For = example, I can imagine a node preferring to join=0Aa RPL Instance providing= minimal latency over one providing best=0AETX. If the OCP is metric-speci= fic, that selected metric will be=0Aimmediately available for the policy ru= les.=0A=0A=0A[Pascal] I agree with Ralph here. I fail to be convinced that = there=0Awill an explosion of OCPs if we fail to factorize the metrics. But= =0AI see how the device implementation can be simplified if the OCP=0Asays = it all. Also, we do not want to force a device that implements=0AMRHOF to h= ave to implement all metrics in the I-D. Conversely, say=0Awe extend MrHof = to other metrics with further work, wouldn't it=0Abecome OCP 2 anyway? I wo= uldn't mind blocking OCP 1..9 for current=0Aand future MrHof metric variati= ons.=0A=0AJust one clarification - MRHOF does not require the devices to=0A= support all the metrics listed in the I-D. All it says is it must=0Aimpleme= nt at least one metric.=0A=0AExcuse the pedantic question, but won't there = be an issue if half the=0Adevices in an RPL instance implement one metric a= nd the other half=0Aimplement a different metric? This would seem to force= users to select=0Aall their devices based on which metric they want to use= .=0A=0ARegards,=0ABrian=0A=0A______________________________________________= _=0ARoll mailing list=0ARoll@ietf.org=0Ahttps://www.ietf.org/mailman/listin= fo/roll=0A=0A=0A_______________________________________________=0ARoll mail= ing list=0ARoll@ietf.org=0Ahttps://www.ietf.org/mailman/listinfo/roll=0A ---557664637-497515277-1340991802=:79739-- From gnawali@cs.uh.edu Fri Jun 29 10:54:30 2012 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 766D121F882E for ; Fri, 29 Jun 2012 10:54:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.077 X-Spam-Level: X-Spam-Status: No, score=-5.077 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_26=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cn9lMndliRFu for ; Fri, 29 Jun 2012 10:54:29 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 882C921F8817 for ; Fri, 29 Jun 2012 10:54:29 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 2ACB823CAAA for ; Fri, 29 Jun 2012 12:54:26 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8ezq5XzPeuF for ; Fri, 29 Jun 2012 12:54:26 -0500 (CDT) Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 638D723CAAD for ; Fri, 29 Jun 2012 12:54:23 -0500 (CDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by it.cs.uh.edu (Postfix) with ESMTP id CE6092A280CE for ; Fri, 29 Jun 2012 12:53:35 -0500 (CDT) Received: by pbcwy7 with SMTP id wy7so5022588pbc.31 for ; Fri, 29 Jun 2012 10:54:25 -0700 (PDT) Received: by 10.66.80.34 with SMTP id o2mr2277161pax.36.1340992465393; Fri, 29 Jun 2012 10:54:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.9.202 with HTTP; Fri, 29 Jun 2012 10:54:05 -0700 (PDT) In-Reply-To: <1340991802.79739.yext-apple-iphone@web29605.mail.ird.yahoo.com> References: <1340991802.79739.yext-apple-iphone@web29605.mail.ird.yahoo.com> From: Omprakash Gnawali Date: Fri, 29 Jun 2012 10:54:05 -0700 Message-ID: To: Panos Trakadas Content-Type: text/plain; charset=ISO-8859-7 Content-Transfer-Encoding: quoted-printable Cc: Stiemerling Martin , Brian Haberman , roll , Michael Richardson Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 17:54:30 -0000 Sorry, I should have been clearer. I was asking if we have a consensus that it is the combination of: 1. metric in the DIO, and 2. OCP that will tell us which metric+OF we have decided to use. Most thought that this is the case but there were some with the opinion that it might be clearer to use separate OCP for each metric,OF combination. It is clear that we will benefit by explicitly stating how to tell what metric+OF is used in the network. Unless there is any objection, I will will proceed with the explanation that metric selection is indicated by the presence of the metric in the container and OF selection by OCP. For example, MRHOF(ETX) will use OF for MRHOF and ETX will be in the metric container. There was a separate discussion on allocating some OCP for proprietary/private OFs that people might want to have but that is a separate discussion. - om_p On Fri, Jun 29, 2012 at 10:43 AM, Panos Trakadas wrote= : > Well, IMO it depends on the specific user requirements set by the root no= de. > It could be a nice idea to investigate the metrics (and techniques like h= ysteresis or composition) that would commonly be used in each one of the ap= plication areas that RPL is targeting (more as a proposition/guideline for = the developers). > To be honest, we have already started reading the respective RFCs and the= AMI draft to figure out the appropriate metrics per application domain in = order to include them in the next version of metrics-composition draft. > Panos > > > On 29 Jun 2012, at 19:21, Omprakash Gnawali wrote: > > Do we have a resolution on this topic - how to select OF+metric to be use= d? > > - om_p > > On Mon, Jun 11, 2012 at 1:27 PM, Don Sturek wrote: > Hi Brian, > > From our experience implementing RPL and MrHOF, all devices in a RPL > instance MUST implement the same OF. > > I think this is why there is so much discussion on the reflector on how t= o > convey the OF to the prospective joining devices. > > Don > > > On 6/7/12 4:22 PM, "Brian Haberman" wrote: > > On 6/7/12 6:12 PM, Omprakash Gnawali wrote: > On Thu, Jun 7, 2012 at 4:49 PM, Pascal Thubert (pthubert) > =A0wrote: > > On Jun 6, 2012, at 10:43 AM 6/6/12, Philip Levis wrote: > > Responses inline. > > On Jun 4, 2012, at 9:31 AM, Ralph Droms wrote: > > > > My question here is why a single objective function "MRHOF" is > defined to use several different metrics. =A0My understanding is > that any specific RPL instance will use one metric as its > "selected metric" for MRHOF. =A0Another way to organize the > objective functions would be to define a different OF number > for each metric, binding the OF number to the selected metric. > > This was a design decision made early in RPL. There were two > options: OFs are metric-specific, or OFs can be general with > respect to metrics. The design team concluded the second approach > was better, as the former would lead to a possibly huge number of > OFs that would be hard to manage. > > Now that a real OF has actually been designed and specified, > perhaps this would be a good time to reconfirm that design > decision. > > Given that MRHOF is a pretty general objective function, and works > over 5 (or perhaps 3) metrics, 16 bits would seem to provide plenty > of code points for metric-specific OFs. > > A bigger issue, I think, is expressing the semantics or behavior of > an OF in its OCP. =A0I read section 18.6 of RFC 6550 to indicate that > a node will use information including the OF (as indicated by the > OCP) to compare against the node's policy for joining a DODAG. =A0As > an aside, is there a reason why a node would choose to join a > specific DODAG within a RPL Instance and on what basis would it > make that choice? =A0Anyway, wouldn't the selected metric =A0used by > MRHOF in a particular RPL Instance be a useful parameter for the > policy rules? =A0For example, I can imagine a node preferring to join > a RPL Instance providing minimal latency over one providing best > ETX. =A0If the OCP is metric-specific, that selected metric will be > immediately available for the policy rules. > > > [Pascal] I agree with Ralph here. I fail to be convinced that there > will an explosion of OCPs if we fail to factorize the metrics. But > I see how the device implementation can be simplified if the OCP > says it all. Also, we do not want to force a device that implements > MRHOF to have to implement all metrics in the I-D. Conversely, say > we extend MrHof to other metrics with further work, wouldn't it > become OCP 2 anyway? I wouldn't mind blocking OCP 1..9 for current > and future MrHof metric variations. > > Just one clarification - MRHOF does not require the devices to > support all the metrics listed in the I-D. All it says is it must > implement at least one metric. > > Excuse the pedantic question, but won't there be an issue if half the > devices in an RPL instance implement one metric and the other half > implement a different metric? =A0This would seem to force users to select > all their devices based on which metric they want to use. > > Regards, > Brian > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=520c6ee4b=mukul@uwm.edu Fri Jun 29 12:00:17 2012 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 373D521F889E for ; Fri, 29 Jun 2012 12:00:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_26=0.6, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knYKFAJnb+6K for ; Fri, 29 Jun 2012 12:00:15 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE6B21F8892 for ; Fri, 29 Jun 2012 12:00:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EANn67U9/AAAB/2dsb2JhbABFDoVMtBsBAQEEAQEBIEsLDA8RBAEBAQICDRkCKSgIBhOHfQMLC6kDiUQFCEqJAASBIIkzZIR4gRIDiEqMaYsDhQCCJlc Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 1D8CA1FD014; Fri, 29 Jun 2012 14:00:13 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h72y-u1RrS6r; Fri, 29 Jun 2012 14:00:12 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 86C711FD013; Fri, 29 Jun 2012 14:00:12 -0500 (CDT) Date: Fri, 29 Jun 2012 14:00:12 -0500 (CDT) From: Mukul Goyal To: Omprakash Gnawali Message-ID: <283139735.80026.1340996412381.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: Brian Haberman , Stiemerling Martin , roll , Michael Richardson Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 19:00:18 -0000 >It is clear that we will benefit by explicitly stating how to tell what metric+OF is used in the network. Unless there is any objection, I will will proceed with the explanation that metric selection is indicated by the presence of the metric in the container and OF selection by OCP. For example, MRHOF(ETX) will use OF for MRHOF and ETX will be in the metric container. I agree except that, for MRHOF, absence of a metric container means that ET= X is the metric in use. Thanks Mukul ----- Original Message ----- From: "Omprakash Gnawali" To: "Panos Trakadas" Cc: "Stiemerling Martin" , "Brian Haberman" , "roll" , "Michael Richardson" Sent: Friday, June 29, 2012 12:54:05 PM Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec Sorry, I should have been clearer. I was asking if we have a consensus that it is the combination of: 1. metric in the DIO, and 2. OCP that will tell us which metric+OF we have decided to use. Most thought that this is the case but there were some with the opinion that it might be clearer to use separate OCP for each metric,OF combination. It is clear that we will benefit by explicitly stating how to tell what metric+OF is used in the network. Unless there is any objection, I will will proceed with the explanation that metric selection is indicated by the presence of the metric in the container and OF selection by OCP. For example, MRHOF(ETX) will use OF for MRHOF and ETX will be in the metric container. There was a separate discussion on allocating some OCP for proprietary/private OFs that people might want to have but that is a separate discussion. - om_p On Fri, Jun 29, 2012 at 10:43 AM, Panos Trakadas wrote= : > Well, IMO it depends on the specific user requirements set by the root no= de. > It could be a nice idea to investigate the metrics (and techniques like h= ysteresis or composition) that would commonly be used in each one of the ap= plication areas that RPL is targeting (more as a proposition/guideline for = the developers). > To be honest, we have already started reading the respective RFCs and the= AMI draft to figure out the appropriate metrics per application domain in = order to include them in the next version of metrics-composition draft. > Panos > > > On 29 Jun 2012, at 19:21, Omprakash Gnawali wrote: > > Do we have a resolution on this topic - how to select OF+metric to be use= d? > > - om_p > > On Mon, Jun 11, 2012 at 1:27 PM, Don Sturek wrote: > Hi Brian, > > From our experience implementing RPL and MrHOF, all devices in a RPL > instance MUST implement the same OF. > > I think this is why there is so much discussion on the reflector on how t= o > convey the OF to the prospective joining devices. > > Don > > > On 6/7/12 4:22 PM, "Brian Haberman" wrote: > > On 6/7/12 6:12 PM, Omprakash Gnawali wrote: > On Thu, Jun 7, 2012 at 4:49 PM, Pascal Thubert (pthubert) > =C2=A0wrote: > > On Jun 6, 2012, at 10:43 AM 6/6/12, Philip Levis wrote: > > Responses inline. > > On Jun 4, 2012, at 9:31 AM, Ralph Droms wrote: > > > > My question here is why a single objective function "MRHOF" is > defined to use several different metrics. =C2=A0My understanding is > that any specific RPL instance will use one metric as its > "selected metric" for MRHOF. =C2=A0Another way to organize the > objective functions would be to define a different OF number > for each metric, binding the OF number to the selected metric. > > This was a design decision made early in RPL. There were two > options: OFs are metric-specific, or OFs can be general with > respect to metrics. The design team concluded the second approach > was better, as the former would lead to a possibly huge number of > OFs that would be hard to manage. > > Now that a real OF has actually been designed and specified, > perhaps this would be a good time to reconfirm that design > decision. > > Given that MRHOF is a pretty general objective function, and works > over 5 (or perhaps 3) metrics, 16 bits would seem to provide plenty > of code points for metric-specific OFs. > > A bigger issue, I think, is expressing the semantics or behavior of > an OF in its OCP. =C2=A0I read section 18.6 of RFC 6550 to indicate that > a node will use information including the OF (as indicated by the > OCP) to compare against the node's policy for joining a DODAG. =C2=A0As > an aside, is there a reason why a node would choose to join a > specific DODAG within a RPL Instance and on what basis would it > make that choice? =C2=A0Anyway, wouldn't the selected metric =C2=A0used b= y > MRHOF in a particular RPL Instance be a useful parameter for the > policy rules? =C2=A0For example, I can imagine a node preferring to join > a RPL Instance providing minimal latency over one providing best > ETX. =C2=A0If the OCP is metric-specific, that selected metric will be > immediately available for the policy rules. > > > [Pascal] I agree with Ralph here. I fail to be convinced that there > will an explosion of OCPs if we fail to factorize the metrics. But > I see how the device implementation can be simplified if the OCP > says it all. Also, we do not want to force a device that implements > MRHOF to have to implement all metrics in the I-D. Conversely, say > we extend MrHof to other metrics with further work, wouldn't it > become OCP 2 anyway? I wouldn't mind blocking OCP 1..9 for current > and future MrHof metric variations. > > Just one clarification - MRHOF does not require the devices to > support all the metrics listed in the I-D. All it says is it must > implement at least one metric. > > Excuse the pedantic question, but won't there be an issue if half the > devices in an RPL instance implement one metric and the other half > implement a different metric? =C2=A0This would seem to force users to sel= ect > all their devices based on which metric they want to use. > > Regards, > Brian > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From gnawali@cs.uh.edu Fri Jun 29 12:06:03 2012 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 06B2621F8855 for ; Fri, 29 Jun 2012 12:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.227 X-Spam-Level: X-Spam-Status: No, score=-5.227 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlPbsDnGU-OI for ; Fri, 29 Jun 2012 12:06:02 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 72C1221F88A3 for ; Fri, 29 Jun 2012 12:06:02 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 03BD623CA99 for ; Fri, 29 Jun 2012 14:05:59 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48YCfNthmuQn for ; Fri, 29 Jun 2012 14:05:58 -0500 (CDT) Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 38AC223CAAD for ; Fri, 29 Jun 2012 14:05:56 -0500 (CDT) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by it.cs.uh.edu (Postfix) with ESMTP id DFD592A280CE for ; Fri, 29 Jun 2012 14:05:08 -0500 (CDT) Received: by pbcwy7 with SMTP id wy7so5097825pbc.31 for ; Fri, 29 Jun 2012 12:05:58 -0700 (PDT) Received: by 10.68.194.201 with SMTP id hy9mr8881249pbc.69.1340996758355; Fri, 29 Jun 2012 12:05:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.9.202 with HTTP; Fri, 29 Jun 2012 12:05:38 -0700 (PDT) In-Reply-To: <283139735.80026.1340996412381.JavaMail.root@mail17.pantherlink.uwm.edu> References: <283139735.80026.1340996412381.JavaMail.root@mail17.pantherlink.uwm.edu> From: Omprakash Gnawali Date: Fri, 29 Jun 2012 12:05:38 -0700 Message-ID: To: Mukul Goyal Content-Type: text/plain; charset=ISO-8859-1 Cc: Brian Haberman , Stiemerling Martin , roll , Michael Richardson Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 19:06:03 -0000 On Fri, Jun 29, 2012 at 12:00 PM, Mukul Goyal wrote: >>It is clear that we will benefit by explicitly stating how to tell > what metric+OF is used in the network. Unless there is any objection, > I will will proceed with the explanation that metric selection is > indicated by the presence of the metric in the container and OF > selection by OCP. For example, MRHOF(ETX) will use OF for MRHOF and > ETX will be in the metric container. > > I agree except that, for MRHOF, absence of a metric container means that ETX is the metric in use. Agree. Thanks for the reminder. - om_p From rdroms.ietf@gmail.com Fri Jun 29 13:13:18 2012 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 F045321F8885 for ; Fri, 29 Jun 2012 13:13:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.299 X-Spam-Level: X-Spam-Status: No, score=-103.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6Xi9ip29JEJ for ; Fri, 29 Jun 2012 13:13:18 -0700 (PDT) Received: from mail-qa0-f51.google.com (mail-qa0-f51.google.com [209.85.216.51]) by ietfa.amsl.com (Postfix) with ESMTP id 4662C21F85A4 for ; Fri, 29 Jun 2012 13:13:18 -0700 (PDT) Received: by qaea16 with SMTP id a16so890746qae.10 for ; Fri, 29 Jun 2012 13:13:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=JAHNUuYalJ/flDFuhOlpxR9hK9UjN65wNFk+oQHWsDE=; b=wzyrIGO8VG/1Zsd7jr2KwP8Q2FotnwBWy8n6dd+o/8F0f/W51NsXOm7anz3uiKtzG+ MQrkwK1d3P8qXc8HxKr5unDvSNgw3Po2RVsFxv1sZPxFOf1/Hl1Y42ZaDIIlnAkuyo5l MGZkhsZam97YciVGUS6n/tCU/ONX+A9j2dY2G/3ZzwEUu1Je5fT/bmzG18ZnT2IFOf0M AQvUkJEHXrk+RMNTcWlPep9cHHkiWl4gubUVPdIbkCgBfW7ZDKn6z75iqqvYOHA2wfSN xLRURIt7NX+HzthI+SesUBUFOJq+L6uu2NCLlgm/Q4RQlyYSuApyfXokHGgIqP0T0D0Y QI9g== Received: by 10.229.135.149 with SMTP id n21mr1532619qct.82.1341000797627; Fri, 29 Jun 2012 13:13:17 -0700 (PDT) Received: from [161.44.65.173] ([161.44.65.173]) by mx.google.com with ESMTPS id cv19sm12336028qab.20.2012.06.29.13.13.15 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 29 Jun 2012 13:13:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Ralph Droms In-Reply-To: Date: Fri, 29 Jun 2012 16:13:14 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <329D1266-9381-404B-B48C-E89B67881B58@gmail.com> References: <283139735.80026.1340996412381.JavaMail.root@mail17.pantherlink.uwm.edu> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1278) Cc: Brian Haberman , Stiemerling Martin , Michael Richardson , roll Subject: Re: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jun 2012 20:13:19 -0000 On Jun 29, 2012, at 3:05 PM 6/29/12, Omprakash Gnawali wrote: > On Fri, Jun 29, 2012 at 12:00 PM, Mukul Goyal wrote: >>> It is clear that we will benefit by explicitly stating how to tell >> what metric+OF is used in the network. Unless there is any objection, >> I will will proceed with the explanation that metric selection is >> indicated by the presence of the metric in the container and OF >> selection by OCP. For example, MRHOF(ETX) will use OF for MRHOF and >> ETX will be in the metric container. >>=20 >> I agree except that, for MRHOF, absence of a metric container means = that ETX is the metric in use. >=20 > Agree. Thanks for the reminder. OK ... that's not the design decision I would have made, but a design = decision is not an issue to hold a Discuss on. A corollary of this design decision is that there can be at most one (in = the case of ETX as the metric, zero) metric in the container. The draft = will need some editing to be consistent about that constraint. - Ralph >=20 > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abdussalambaryun@gmail.com Fri Jun 29 22:14:43 2012 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 8568021F86F6; Fri, 29 Jun 2012 22:14:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.49 X-Spam-Level: X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.109, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d9NIs0Hr1Yvv; Fri, 29 Jun 2012 22:14:42 -0700 (PDT) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D7BDB21F86F5; Fri, 29 Jun 2012 22:14:41 -0700 (PDT) Received: by vbbez10 with SMTP id ez10so2987890vbb.31 for ; Fri, 29 Jun 2012 22:14:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=OfHS+z2+tUjYmdWSKs9nSMpFfeBDh8aA4YMCb1I1u5E=; b=Zfnp3gLlH4tOEkG4OqKXmCPVDoDiYo6PFPJ3ZMV/5ZZmUmkoK75RVGkrY7pMkaJ8Yn dlyZ4cRbPHlXgQToUHikyXNS3huK+3QqKzndVlKCfO8TXOUjRDt+myQ75U24kYzOmZwd MHKDCUhDRZshChaRwMDahCE84XSUE+sAxFllD5CQg9jsFqqHEDxc70U9aayKDMoWp2oN VX231mQb3eaVZBDdtllSogzcPFPjx0YtynDg2sdEFTcNXJQbNVF14edzf1STHjQRUwe0 tUkW2V1/kr4uGn4Mc+daWSnHu7Z91rr0gJp7S6Twoz7RTjbmQ0J4FBZG+hD3B51Vey3W Q7wQ== MIME-Version: 1.0 Received: by 10.52.94.36 with SMTP id cz4mr2022817vdb.10.1341033281145; Fri, 29 Jun 2012 22:14:41 -0700 (PDT) Received: by 10.220.145.9 with HTTP; Fri, 29 Jun 2012 22:14:40 -0700 (PDT) In-Reply-To: <4FEE77C4.5050605@saloits.com> References: <4FEE77C4.5050605@saloits.com> Date: Sat, 30 Jun 2012 07:14:40 +0200 Message-ID: From: Abdussalam Baryun To: "Timothy J. Salo" Content-Type: text/plain; charset=ISO-8859-1 Cc: roll , "6lowpan@ietf.org" <6lowpan@ietf.org> Subject: Re: [Roll] [6lowpan] IP over Narrowband Radios X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2012 05:14:43 -0000 Hi Tim, I agree with you in the design issues, but think that your proposal is more suitable/applicable for ROLL WG not in 6LoWPAN WG, because this WG is more about WPAN. However, it is an interesting to see your work/proposal in a draft I-D. I have not worked on your topic but understand that the engineering comparison of short range and large range may not be correct by excluding network complexity and cost. In particular, I think you need to be sure that the layer 1 (Radio) is defined and specified, I recommend that layer 2 (L2) to be a standard (e.g. IEEE, ITU, or other standards ORG). Then in the I-D you propose standard of IP over (L2 of VHF/UHF Radio) similar to 6Lowpan I-Ds, but I don't think we can standard L2 in IETF if it is not existed and used in the Internet. I may be wrong, if so please reply, AB +++ On 6/30/12, Timothy J. Salo wrote: > Hi, > > Is anyone looking at running IP over narrowband very high frequency > (VHF) and ultra high frequency (UHF) data radios? A couple of major > issues come to mind. > > First, bandwidth is extremely limited and valuable. These radios may > provide bandwidths of only 9,600 bits-per-second (bps), 4,800 bps, or > even less. Networks composed of these radios might be viewed as > _wide-area_ wireless sensor networks (WSNs) (in contrast to the > "local-area" WSNs typically built with 6lowpan devices). Link > distances in these narrowband networks may be kilometers or even > tens-of-kilometers long. The narrowband radios used in these networks > may transmit with one to five watts of power. In my view, the > extremely low bandwidths of these networks, combined with the very high > energy cost of transmitting a bit, is likely to drive different > engineering tradeoffs in protocol design (compared to 802.15.4 > networks, where link bandwidths are relatively high and the cost of > transmitting a bit is relatively low). For example, in a narrowband > network, it may make much more sense to compute or store information > whenever possible, rather than transmitting it (more than one) over > the air. While I have not yet done the analysis, it seems to me that > it is quite likely that the engineering tradeoffs make in 6lowpan are > different than the engineering tradeoffs that might be made in a > narrowband radio network. Perhaps, there is utility in a collection of > IP-over-narrowband-radio RFCs. > > Second, there is a pretty complete lack of standards for narrowband > data radios, most importantly at the physical and MAC layers. While > this topic is outside of the purview of the IETF, it is a serious > impediment to building interoperable products. It might also complicate > the process of standardizing IP-over-narrowband-radio specifications. > > -tjs > _______________________________________________ > 6lowpan mailing list > 6lowpan@ietf.org > https://www.ietf.org/mailman/listinfo/6lowpan > From internet-drafts@ietf.org Fri Jun 29 23:12:05 2012 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 3B3ED21F86D6; Fri, 29 Jun 2012 23:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JUEbLEaae3Ls; Fri, 29 Jun 2012 23:12:03 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87A1D21F84FB; Fri, 29 Jun 2012 23:11:36 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.21p1 Message-ID: <20120630061136.6274.62757.idtracker@ietfa.amsl.com> Date: Fri, 29 Jun 2012 23:11:36 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-minrank-hysteresis-of-11.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: Sat, 30 Jun 2012 06:12:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : The Minimum Rank with Hysteresis Objective Function Author(s) : Omprakash Gnawali Philip Levis Filename : draft-ietf-roll-minrank-hysteresis-of-11.txt Pages : 14 Date : 2012-06-29 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. This specification describes the Minimum Rank with Hysteresis Objective Function (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 datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-minrank-hysteresis-of-11 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-minrank-hysteresis-of-= 11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From gnawali@cs.uh.edu Fri Jun 29 23:17:22 2012 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 76D6121F86E0 for ; Fri, 29 Jun 2012 23:17:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.577 X-Spam-Level: X-Spam-Status: No, score=-5.577 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t1mvzEZk-t1l for ; Fri, 29 Jun 2012 23:17:21 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 1D29221F86AF for ; Fri, 29 Jun 2012 23:17:20 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 9103623CAB8 for ; Sat, 30 Jun 2012 01:17:17 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MXjVK3oLupP6 for ; Sat, 30 Jun 2012 01:17:14 -0500 (CDT) Received: from it.cs.uh.edu (www2.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 286CA23CAB3 for ; Sat, 30 Jun 2012 01:17:14 -0500 (CDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by it.cs.uh.edu (Postfix) with ESMTP id E340F2A280C0 for ; Sat, 30 Jun 2012 01:16:28 -0500 (CDT) Received: by dacx6 with SMTP id x6so5447053dac.31 for ; Fri, 29 Jun 2012 23:17:16 -0700 (PDT) Received: by 10.68.130.9 with SMTP id oa9mr12479969pbb.95.1341037036103; Fri, 29 Jun 2012 23:17:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.66.9.202 with HTTP; Fri, 29 Jun 2012 23:16:41 -0700 (PDT) In-Reply-To: <20120630061204.6274.9134.idtracker@ietfa.amsl.com> References: <20120630061204.6274.9134.idtracker@ietfa.amsl.com> From: Omprakash Gnawali Date: Fri, 29 Jun 2012 23:16:41 -0700 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [Roll] Fwd: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-11.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: Sat, 30 Jun 2012 06:17:22 -0000 Here are the changes made to this draft to address all the DISCUSS items. COMMENTs were also addressed but not listed here. Here is a link to -11: http://tools.ietf.org/html/draft-ietf-roll-minrank-hysteresis-of-11 And here is a link to the diff between -10 and -11: http://tools.ietf.org/rfcdiff?difftype=3D--hwdiff&url2=3Ddraft-ietf-roll-mi= nrank-hysteresis-of-11.txt How the DISCUSS items were addressed --- Brian Haberman: 1. Discuss - In sections 3.1 and 3.2.1, the draft says that messages can be delayed but should not be delayed too much? How much is too much? Is it dependent on the metric being used? Are there guidelines that should be provided? If different implementations try to interact, will their selection of delay values hinder performance/stability of the RPL-based network? Fixed. It now gives an example of reasonable delay: Trickle minimum interval (6550) and says longer delays will lead to stale information, suboptimal paths. ------ 2. Discuss - Section 5 says, "The best values for these parameters should be experimentally determined." Is this guidance to implementers to figure out what values to support in their implementation or advice to operators to test a range of values for their particular deployment? As a standards-track document, this type of nebulous statement concerns me from a variety of perspectives. Fixed as: The best values for these parameters are determined by the requirement of the specific RPL deployment. For instance, if we use ETX as the selected metric and UDP as the transport protocol, we should use a small MAX_LINK_METRIC (e.g., ETX of 1.1) so that link layer retransmissions are sufficient to provide a good chance of end-to-end reliability. ------ 3. Discuss - Section 8 asks IANA to allocate a code point, but where in the draft is that code point used? Is it used as a part of the transmission logic in section 3.4? This is a RPL parameter (not used in MRHOF) as suggested in the text: This specification requires a value allocated from the "Objective Code Point (OCP)" sub-registry of the "Routing Protocol for Low Power and Lossy Networks (RPL)" registry. A value of 1 is suggested. ------ Comment - acronyms should be referenced/expanded in first use. Fixed. ----- Martin Steimerling Discuss 1: Is there any recommendation or further reading on what the time is to be used to perform the periodically updates? Re-computing state periodically might be a good thing, but I would expect that a Standards Track document is much more specific on this. Fixed. .. Discuss 2: How much is the 'later time'? I would expect that a Standards Track document is much more specific on this, other than do whatever you think is appropriate. Fixed. ... Discuss 3: Is there any reference on how the WG came to the below numbers? This would be good for people trying to follow this up in the future. They might need to know how to came to these numbers. Here are the recommended numbers with proper ETX representation - MAX_LINK_METRIC: 512. MAX_PATH_COST: 32768. PARENT_SWITCH_THRESHOLD: 192. PARENT_SET_SIZE: 3. ALLOW_FLOATING_ROOT: 0. and the draft now cites: IP is Dead, Long Live IP for Wireless Sensor Networks Jonathan W. Hui and David E. Culler Proceedings of the 6th International Conference on Embedded Networked Sensor Systems ---- Discuss 1-4: 1. Why is one objective function defined for several potential metrics? The details of MRHOF seem to preclude the establishment of several RPL instances in an LLN, each of which uses MRHOF with a different selected metric. 2. How are the nodes in the RPL instance informed about the selected metric? My understanding of RPL is that only the objective function is included in the DIO received as an advertisement for a particular RPL instance, which means a node can't know the selected metric for that RPL instance and can't meaningfully decide among multiple RPL instances all using MRHOF as the objective function. As a followup to (1), if there were a way to encode the selected metric for a RPL instance in the DAO, a node would be able to select which RPL instance to use for a particular type of traffic. 3. Based on (1) and (2), would configuration and selection issues be ameliorated if the five candidate selected metrics were each asssigned a separate objective function? Use of a separate OF code point for each of the five possible selected metrics would allow multiple RPL instances. 4. Related to the above, I don't see anything in section 6 about managing the selected metric. Don't all of the nodes that join a RPL instance using MRHOF have to be configured to use the same selected metric? Fixed with this definition in the terminology section: The metric chosen by the network operator to use for path selection. MRHOF supports using a single metric for path selection. The decision to use a metric (other than ETX) as the selected metric is indicated by the presence of the chosen metric in the DIO metric container. The selection of the ETX metric is indicated by the absence of the metric container. ---- Discuss 5 - In section 3.2.2: a node MAY use a different objective function to select which of these neighbors should be considered to have the lowest cost. seems to contradict the statement in the Introduction that "all nodes in a network use a common OF." Should "different objective function" be replaced with "some other selection criteria?" Fixed: If there are multiple neighbors which share the smallest path cost, a node MAY use a different selection criteria to select which of these neighbors should be considered to have the lowest cost. ---- Discuss 6 - In section 5, are the RECOMMENDED values appropriate for all selected metrics or just for ETX? Are there any references that might be cited that would give background on the working group experience with ETX and the development of the recommended values? Fixed. See above. ---- 7. In section 6.1, why not "MUST support the DODAG Configuration option?" I don't see any RFC 2119 requirements on the implementation of the DODAG Configuration option (which would appera to be an oversight), but I don't understand how a node can operate in a RPL instance without, for example, being able to determine the Objective Function used by that instance. Fixed: A MRHOF implementation MUST support the DODAG Configuration option as described in and apply the parameters = it specifies. Care should be taken in the relationship between the MRHOF ... - om_p ---------- Forwarded message ---------- From: Date: Fri, Jun 29, 2012 at 11:12 PM Subject: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-11.txt To: gnawali@cs.uh.edu Cc: pal@cs.stanford.edu A new version of I-D, draft-ietf-roll-minrank-hysteresis-of-11.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 =A011 Title: =A0 =A0 =A0 =A0 =A0 The Minimum Rank with Hysteresis Objective Funct= ion Creation date: =A0 2012-06-29 WG ID: =A0 =A0 =A0 =A0 =A0 roll Number of pages: 14 URL: http://www.ietf.org/internet-drafts/draft-ietf-roll-minrank-hysteresis-of-1= 1.txt Status: http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of Htmlized: http://tools.ietf.org/html/draft-ietf-roll-minrank-hysteresis-of-11 Diff: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-minrank-hysteresis-of-= 11 Abstract: =A0 The Routing Protocol for Low Power and Lossy Networks (RPL) uses =A0 objective functions to construct routes that optimize or constrain =A0 the routes it selects and uses. =A0This specification describes the =A0 Minimum Rank with Hysteresis Objective Function (MRHOF), an objective =A0 function that selects routes that minimize a metric, while using =A0 hysteresis to reduce churn in response to small metric changes. =A0 MRHOF works with metrics that are additive along a route, and the =A0 metric it uses is determined by the metrics RPL Destination =A0 Information Object (DIO) messages advertise. The IETF Secretariat