From Internet-Drafts@ietf.org Tue Mar 1 04:15:02 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85CED3A67C1; Tue, 1 Mar 2011 04:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z5kKUwI9ZZHv; Tue, 1 Mar 2011 04:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E60DF3A67D4; Tue, 1 Mar 2011 04:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110301121501.30404.19869.idtracker@localhost> Date: Tue, 01 Mar 2011 04:15:01 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-routing-metrics-19.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 12:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Routing Metrics used for Path Calculation in Low Power and Lossy Networks Author(s) : J. Vasseur, et al. Filename : draft-ietf-roll-routing-metrics-19.txt Pages : 30 Date : 2011-03-01 Low power and Lossy Networks (LLNs) have unique characteristics compared with traditional wired and ad-hoc networks that require the specification of new routing metrics and constraints. By contrast with typical Interior Gateway Protocol (IGP) routing metrics using hop counts or link metrics, this document specifies a set of link and node routing metrics and constraints suitable to LLNs to be used by the Routing for Low Power and lossy networks (RPL) routing protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-19.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-routing-metrics-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-01041250.I-D@ietf.org> --NextPart-- From jpv@cisco.com Tue Mar 1 04:53:16 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFC2B3A67FB for ; Tue, 1 Mar 2011 04:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqnIfnfB0X4s for ; Tue, 1 Mar 2011 04:53:15 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 0A0D33A67AE for ; Tue, 1 Mar 2011 04:53:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=7711; q=dns/txt; s=iport; t=1298984058; x=1300193658; h=from:subject:date:references:to:message-id:mime-version; bh=+VG4H1hIcOG/XTH5GhpqnI55FtJSqfm/av4LBQoiu2U=; b=dnbh6EeJiLFgaPv3g7d/DnPyRE0ncggrwHV+k49DKrfUwry+XaY+Hx3/ vaW3cAGAZu33Z9D2XQKLODf+WJ5j2eW1sK2+0K3eTy79wZ87Rh2Ulkwlv JQiimfjG5GXHfUVTQ4/lJnhgzP3gfmFWMHhg5wdi13PXZ0WWWzsTUegHe 0=; X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoEIAPt6bE2Q/khMgWdsb2JhbACeWIcUXxUBARYiJZ5+nCuFYQSMH4NABg X-IronPort-AV: E=Sophos;i="4.62,246,1297036800"; d="scan'208,217";a="77678330" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 01 Mar 2011 12:54:17 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p21CsHD0025478 for ; Tue, 1 Mar 2011 12:54:17 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 13:54:17 +0100 Received: from [64.103.30.0] ([64.103.30.0]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Mar 2011 13:54:16 +0100 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-1003-701777174 Date: Tue, 1 Mar 2011 13:54:00 +0100 References: <20110301121501.30404.19869.idtracker@localhost> To: ROLL WG Message-Id: <65A25BC9-8372-4AD4-9FFA-45A379316DBF@cisco.com> Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 01 Mar 2011 12:54:16.0913 (UTC) FILETIME=[C60E5C10:01CBD80F] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17984.007 X-TM-AS-Result: No--18.826300-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-routing-metrics-19.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 12:53:17 -0000 --Apple-Mail-1003-701777174 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Jut a minor update, with few clarification on IANA section. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 1, 2011 1:15:01 PM GMT+01:00 > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: I-D Action:draft-ietf-roll-routing-metrics-19.txt > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Routing Over Low power and Lossy = networks Working Group of the IETF. >=20 >=20 > Title : Routing Metrics used for Path Calculation in = Low Power and Lossy Networks > Author(s) : J. Vasseur, et al. > Filename : draft-ietf-roll-routing-metrics-19.txt > Pages : 30 > Date : 2011-03-01 >=20 > Low power and Lossy Networks (LLNs) have unique characteristics > compared with traditional wired and ad-hoc networks that require the > specification of new routing metrics and constraints. By contrast > with typical Interior Gateway Protocol (IGP) routing metrics using > hop counts or link metrics, this document specifies a set of link and > node routing metrics and constraints suitable to LLNs to be used by > the Routing for Low Power and lossy networks (RPL) routing protocol. >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metrics-19.txt= >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-1003-701777174 Content-Type: multipart/mixed; boundary=Apple-Mail-1004-701777175 --Apple-Mail-1004-701777175 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Jut a = minor update, with few clarification on IANA = section.

Begin forwarded message:

Date: March 1, 2011 1:15:01 PM = GMT+01:00
Subject: I-D = Action:draft-ietf-roll-routing-metrics-19.txt
Reply-To: internet-drafts@ietf.org
<= /span>

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


= Title =           : Routing = Metrics used for Path Calculation in Low Power and Lossy = Networks
= Author(s)       : J. Vasseur, et = al.
= Filename        : = draft-ietf-roll-routing-metrics-19.txt
Pages =           : = 30
= Date =            : = 2011-03-01

Low power and Lossy Networks (LLNs) have unique = characteristics
compared with traditional wired and ad-hoc networks = that require the
specification of new routing metrics and = constraints.  By contrast
with typical Interior Gateway Protocol = (IGP) routing metrics using
hop counts or link metrics, this document = specifies a set of link and
node routing metrics and constraints = suitable to LLNs to be used by
the Routing for Low Power and lossy = networks (RPL) routing protocol.

A URL for this Internet-Draft = is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-routing-metr= ics-19.txt

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

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-1004-701777175 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: message/external-body; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2011-03-01041250.I-D@ietf.org>

--Apple-Mail-1004-701777175 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-1004-701777175-- --Apple-Mail-1003-701777174-- From phoebus@ieee.org Tue Mar 1 09:46:40 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 38DE83A6A01 for ; Tue, 1 Mar 2011 09:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YtLrM07+nwaQ for ; Tue, 1 Mar 2011 09:46:39 -0800 (PST) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id 0D7383A68CC for ; Tue, 1 Mar 2011 09:46:39 -0800 (PST) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 9D513156FFC for ; Tue, 1 Mar 2011 18:47:11 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id QEcoZCIheWlM for ; Tue, 1 Mar 2011 18:47:09 +0100 (CET) X-KTH-Auth: phoebus [2001:6b0:1:12b0:223:dfff:fe92:5e5c] X-KTH-mail-from: phoebus@ieee.org X-KTH-rcpt-to: roll@ietf.org Received: from dhcp-50-10.s3.kth.se (unknown [IPv6:2001:6b0:1:12b0:223:dfff:fe92:5e5c]) by smtp-1.sys.kth.se (Postfix) with ESMTP id EB8EE156FEF for ; Tue, 1 Mar 2011 18:47:09 +0100 (CET) Message-ID: <4D6D311C.8020001@ieee.org> Date: Tue, 01 Mar 2011 18:47:08 +0100 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: roll@ietf.org References: <20110301003318.9EA863A6CBA@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Fwd: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 17:46:40 -0000 On 3/1/11 1:41 AM, Omprakash Gnawali wrote: > - Parent set - only the preferred parent in the parent set. From the > perspective of this OF, the nodes do not narrow down the list of > candidates to a smaller set and pick a node from that smaller set. I > am open to suggestion on a different way to explain and think about > the parent set. > Omprakash, Just trying to understand this more clearly. Is the reason for limiting the parent set to only the preferred parent, and not all the neighbors in the neighbor table that have rank less than the current node, to make sure data packets are routed along a tree? I always interpreted the parent set as the set of neighbors that you can route packets to, upward towards the root. Is this to limit the variability in end-to-end latency, etc. that comes from multipath hop-by-hop routing, at the cost of path diversity? -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus From gnawali@cs.stanford.edu Tue Mar 1 12:17:40 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 012F03A6A8B for ; Tue, 1 Mar 2011 12:17:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwEunYe-FsC0 for ; Tue, 1 Mar 2011 12:17:39 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 487CC3A693A for ; Tue, 1 Mar 2011 12:17:39 -0800 (PST) Received: from mail-iw0-f172.google.com ([209.85.214.172]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1PuW1r-0007ry-2Q for roll@ietf.org; Tue, 01 Mar 2011 12:18:43 -0800 Received: by iwl42 with SMTP id 42so5025462iwl.31 for ; Tue, 01 Mar 2011 12:18:42 -0800 (PST) Received: by 10.42.179.132 with SMTP id bq4mr6838718icb.199.1299010722242; Tue, 01 Mar 2011 12:18:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.59.15 with HTTP; Tue, 1 Mar 2011 12:18:21 -0800 (PST) In-Reply-To: <4D6D311C.8020001@ieee.org> References: <20110301003318.9EA863A6CBA@core3.amsl.com> <4D6D311C.8020001@ieee.org> From: Omprakash Gnawali Date: Tue, 1 Mar 2011 12:18:21 -0800 Message-ID: To: phoebus@ieee.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 993826b9125cbf1b907f71dc54053338 Cc: roll@ietf.org Subject: Re: [Roll] Fwd: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2011 20:17:40 -0000 On Tue, Mar 1, 2011 at 9:47 AM, Phoebus Chen wrote: > On 3/1/11 1:41 AM, Omprakash Gnawali wrote: >> >> - Parent set - only the preferred parent in the parent set. From the >> perspective of this OF, the nodes do not narrow down the list of >> candidates to a smaller set and pick a node from that smaller set. I >> am open to suggestion on a different way to explain and think about >> the parent set. >> > > > Omprakash, > > =A0Just trying to understand this more clearly. =A0Is the reason for limi= ting > the parent set to only the preferred parent, and not all the neighbors in > the neighbor table that have rank less than the current node, to make sur= e > data packets are routed along a tree? =A0I always interpreted the parent = set > as the set of neighbors that you can route packets to, upward towards the > root. =A0Is this to limit the variability in end-to-end latency, etc. tha= t > comes from multipath hop-by-hop routing, at the cost of path diversity? This OF does not give you access to those nodes with lower rank nor treats them differently from nodes with rank lower than itself. The only thing the OF gives you is the preferred parent. So, I changed the language to make it very clear. In an alternate version, yes, you could have multiple candidate parents and route through any of them. Then there would be concerns such as the ones you expressed. Despite the concerns, it is possible it will turn out to be a system that performs well. If there is substantial interest in "alternate" parents, we can incorporate that in this OF or write a different one. If we do that, the output of the OF would be an ordered parent set, not the preferred parent. - om_p From phoebus@ieee.org Wed Mar 2 12:53:34 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8532C3A67FD for ; Wed, 2 Mar 2011 12:53:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeToWJZfolKa for ; Wed, 2 Mar 2011 12:53:33 -0800 (PST) Received: from smtp-1.sys.kth.se (smtp-1.sys.kth.se [130.237.32.175]) by core3.amsl.com (Postfix) with ESMTP id BE7F33A6835 for ; Wed, 2 Mar 2011 12:53:29 -0800 (PST) Received: from mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) by smtp-1.sys.kth.se (Postfix) with ESMTP id 5F8BD15700C; Wed, 2 Mar 2011 21:54:05 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-1.sys.kth.se ([130.237.32.175]) by mailscan-1.sys.kth.se (mailscan-1.sys.kth.se [130.237.32.91]) (amavisd-new, port 10024) with LMTP id AJ0-J6tfsHvS; Wed, 2 Mar 2011 21:54:03 +0100 (CET) X-KTH-Auth: phoebus [83.145.36.89] X-KTH-mail-from: phoebus@ieee.org Received: from catch-all.priv (unknown [83.145.36.89]) by smtp-1.sys.kth.se (Postfix) with ESMTP id EBEDE157925; Wed, 2 Mar 2011 21:54:00 +0100 (CET) Message-ID: <4D6EAE68.4050104@ieee.org> Date: Wed, 02 Mar 2011 21:54:00 +0100 From: Phoebus Chen Organization: KTH, Royal Institute of Technology User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Thunderbird/3.1.8 MIME-Version: 1.0 To: Omprakash Gnawali References: <20110301003318.9EA863A6CBA@core3.amsl.com> <4D6D311C.8020001@ieee.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] Fwd: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: phoebus@ieee.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 20:53:34 -0000 On 3/1/11 9:18 PM, Omprakash Gnawali wrote: > On Tue, Mar 1, 2011 at 9:47 AM, Phoebus Chen wrote: >> On 3/1/11 1:41 AM, Omprakash Gnawali wrote: >>> >>> - Parent set - only the preferred parent in the parent set. From the >>> perspective of this OF, the nodes do not narrow down the list of >>> candidates to a smaller set and pick a node from that smaller set. I >>> am open to suggestion on a different way to explain and think about >>> the parent set. >>> >> >> >> Omprakash, >> >> Just trying to understand this more clearly. Is the reason for limiting >> the parent set to only the preferred parent, and not all the neighbors in >> the neighbor table that have rank less than the current node, to make sure >> data packets are routed along a tree? I always interpreted the parent set >> as the set of neighbors that you can route packets to, upward towards the >> root. Is this to limit the variability in end-to-end latency, etc. that >> comes from multipath hop-by-hop routing, at the cost of path diversity? > > This OF does not give you access to those nodes with lower rank nor > treats them differently from nodes with rank lower than itself. The > only thing the OF gives you is the preferred parent. So, I changed the > language to make it very clear. > > In an alternate version, yes, you could have multiple candidate > parents and route through any of them. Then there would be concerns > such as the ones you expressed. Despite the concerns, it is possible > it will turn out to be a system that performs well. If there is > substantial interest in "alternate" parents, we can incorporate that > in this OF or write a different one. If we do that, the output of the > OF would be an ordered parent set, not the preferred parent. > > - om_p I would be interested in having alternate parents, but maybe it's better to hear from people in industry. There may be some subtleties to having alternate parents since the advertised metric is only with respect to the path through the preferred parent. Nonetheless, it should be easy to add a configurable constant specifying the size of the parent set and just order the alternate parents by link ETX + remaining ETX. I've been discussing with others to understand the issues that need to be handled if we write an OF specifically for multipath, but we're not ready to make recommendations yet. -- Phoebus Chen Postdoctoral Researcher Automatic Control Lab, KTH (Royal Institute of Technology) http://www.ee.kth.se/~phoebus From pal@cs.stanford.edu Wed Mar 2 14:58:46 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 461853A68FB for ; Wed, 2 Mar 2011 14:58:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QB2AQ5xxAeSJ for ; Wed, 2 Mar 2011 14:58:45 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 9CA883A690E for ; Wed, 2 Mar 2011 14:58:43 -0800 (PST) Received: from c-24-7-84-162.hsd1.ca.comcast.net ([24.7.84.162] helo=[192.168.1.147]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Puv1K-0001mq-56; Wed, 02 Mar 2011 14:59:50 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4D6EAE68.4050104@ieee.org> Date: Wed, 2 Mar 2011 14:59:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu> References: <20110301003318.9EA863A6CBA@core3.amsl.com> <4D6D311C.8020001@ieee.org> <4D6EAE68.4050104@ieee.org> To: phoebus@ieee.org X-Mailer: Apple Mail (2.1082) X-Scan-Signature: cb5916722246bf80bd9488153e8e2604 Cc: roll@ietf.org Subject: Re: [Roll] Fwd: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 22:58:46 -0000 On Mar 2, 2011, at 12:54 PM, Phoebus Chen wrote: > On 3/1/11 9:18 PM, Omprakash Gnawali wrote: >> On Tue, Mar 1, 2011 at 9:47 AM, Phoebus Chen = wrote: >>> On 3/1/11 1:41 AM, Omprakash Gnawali wrote: >>>>=20 >>>> - Parent set - only the preferred parent in the parent set. =46rom = the >>>> perspective of this OF, the nodes do not narrow down the list of >>>> candidates to a smaller set and pick a node from that smaller set. = I >>>> am open to suggestion on a different way to explain and think about >>>> the parent set. >>>>=20 >>>=20 >>>=20 >>> Omprakash, >>>=20 >>> Just trying to understand this more clearly. Is the reason for = limiting >>> the parent set to only the preferred parent, and not all the = neighbors in >>> the neighbor table that have rank less than the current node, to = make sure >>> data packets are routed along a tree? I always interpreted the = parent set >>> as the set of neighbors that you can route packets to, upward = towards the >>> root. Is this to limit the variability in end-to-end latency, etc. = that >>> comes from multipath hop-by-hop routing, at the cost of path = diversity? >>=20 >> This OF does not give you access to those nodes with lower rank nor >> treats them differently from nodes with rank lower than itself. The >> only thing the OF gives you is the preferred parent. So, I changed = the >> language to make it very clear. >>=20 >> In an alternate version, yes, you could have multiple candidate >> parents and route through any of them. Then there would be concerns >> such as the ones you expressed. Despite the concerns, it is possible >> it will turn out to be a system that performs well. If there is >> substantial interest in "alternate" parents, we can incorporate that >> in this OF or write a different one. If we do that, the output of the >> OF would be an ordered parent set, not the preferred parent. >>=20 >> - om_p >=20 > I would be interested in having alternate parents, but maybe it's = better to hear from people in industry. There may be some subtleties to = having alternate parents since the advertised metric is only with = respect to the path through the preferred parent. Nonetheless, it = should be easy to add a configurable constant specifying the size of the = parent set and just order the alternate parents by link ETX + remaining = ETX. I've been discussing with others to understand the issues that = need to be handled if we write an OF specifically for multipath, but = we're not ready to make recommendations yet. Hm -- I think it makes sense to allow multiple elements in the parent = set, if only because I know of at least one solid implementation that = has done so (Arch Rock/Cisco). It would be a mistake to preclude this = approach for such a basic OF. Phil= From gnawali@cs.stanford.edu Wed Mar 2 16:51:07 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 323803A691A for ; Wed, 2 Mar 2011 16:51:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tjjVH9eckqcV for ; Wed, 2 Mar 2011 16:51:06 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 5872D3A6919 for ; Wed, 2 Mar 2011 16:51:06 -0800 (PST) Received: from mail-iw0-f172.google.com ([209.85.214.172]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Puwm4-0005Xz-UO for roll@ietf.org; Wed, 02 Mar 2011 16:52:13 -0800 Received: by iwl42 with SMTP id 42so573524iwl.31 for ; Wed, 02 Mar 2011 16:52:12 -0800 (PST) Received: by 10.231.207.9 with SMTP id fw9mr475888ibb.8.1299113532141; Wed, 02 Mar 2011 16:52:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.59.15 with HTTP; Wed, 2 Mar 2011 16:51:52 -0800 (PST) In-Reply-To: <7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu> References: <20110301003318.9EA863A6CBA@core3.amsl.com> <4D6D311C.8020001@ieee.org> <4D6EAE68.4050104@ieee.org> <7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu> From: Omprakash Gnawali Date: Wed, 2 Mar 2011 16:51:52 -0800 Message-ID: To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: fb418a055a615a79fddacbea7bf2a8e8 Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 00:51:07 -0000 On Wed, Mar 2, 2011 at 2:59 PM, Philip Levis wrote: > > On Mar 2, 2011, at 12:54 PM, Phoebus Chen wrote: > >> On 3/1/11 9:18 PM, Omprakash Gnawali wrote: >>> On Tue, Mar 1, 2011 at 9:47 AM, Phoebus Chen =A0wrote= : >>>> On 3/1/11 1:41 AM, Omprakash Gnawali wrote: >>>>> >>>>> - Parent set - only the preferred parent in the parent set. From the >>>>> perspective of this OF, the nodes do not narrow down the list of >>>>> candidates to a smaller set and pick a node from that smaller set. I >>>>> am open to suggestion on a different way to explain and think about >>>>> the parent set. >>>>> >>>> >>>> >>>> Omprakash, >>>> >>>> =A0Just trying to understand this more clearly. =A0Is the reason for l= imiting >>>> the parent set to only the preferred parent, and not all the neighbors= in >>>> the neighbor table that have rank less than the current node, to make = sure >>>> data packets are routed along a tree? =A0I always interpreted the pare= nt set >>>> as the set of neighbors that you can route packets to, upward towards = the >>>> root. =A0Is this to limit the variability in end-to-end latency, etc. = that >>>> comes from multipath hop-by-hop routing, at the cost of path diversity= ? >>> >>> This OF does not give you access to those nodes with lower rank nor >>> treats them differently from nodes with rank lower than itself. The >>> only thing the OF gives you is the preferred parent. So, I changed the >>> language to make it very clear. >>> >>> In an alternate version, yes, you could have multiple candidate >>> parents and route through any of them. Then there would be concerns >>> such as the ones you expressed. Despite the concerns, it is possible >>> it will turn out to be a system that performs well. If there is >>> substantial interest in "alternate" parents, we can incorporate that >>> in this OF or write a different one. If we do that, the output of the >>> OF would be an ordered parent set, not the preferred parent. >>> >>> - om_p >> >> I would be interested in having alternate parents, but maybe it's better= to hear from people in industry. =A0There may be some subtleties to having= alternate parents since the advertised metric is only with respect to the = path through the preferred parent. =A0Nonetheless, it should be easy to add= a configurable constant specifying the size of the parent set and just ord= er the alternate parents by link ETX + remaining ETX. =A0I've been discussi= ng with others to understand the issues that need to be handled if we write= an OF specifically for multipath, but we're not ready to make recommendati= ons yet. > > Hm -- I think it makes sense to allow multiple elements in the parent set= , if only because I know of at least one solid implementation that has done= so (Arch Rock/Cisco). It would be a mistake to preclude this approach for = such a basic OF. My goal was it make the language clear that this OF in this version has a single parent in the set. Two specific questions regarding multiple parents - What rank do you advertise? How do you use multiple parents? For example, do you go to the 2nd best parent when the best parent is unreachable? Do you use multiple parents simultaneously or using different policies? The first scenario is covered by this OF although implicitly. The second scenario is not covered. - om_p From pal@cs.stanford.edu Wed Mar 2 17:11:38 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F29C3A690B for ; Wed, 2 Mar 2011 17:11:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gjS3DV4DMGjS for ; Wed, 2 Mar 2011 17:11:37 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 3D9153A67EB for ; Wed, 2 Mar 2011 17:11:37 -0800 (PST) Received: from [50.12.161.7] (helo=50-12-161-7.sfo.clearwire-wmx.net) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Pux5v-00069J-U5; Wed, 02 Mar 2011 17:12:44 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Wed, 2 Mar 2011 17:12:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu> References: <20110301003318.9EA863A6CBA@core3.amsl.com> <4D6D311C.8020001@ieee.org> <4D6EAE68.4050104@ieee.org> <7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1082) X-Scan-Signature: a11a15d02c0ec4233875b3872b0caebb Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 01:11:38 -0000 On Mar 2, 2011, at 4:51 PM, Omprakash Gnawali wrote: > My goal was it make the language clear that this OF in this version > has a single parent in the set. >=20 > Two specific questions regarding multiple parents - >=20 > What rank do you advertise? Well, take a look at the RPL spec. It says exactly what you have to = advertise. > How do you use multiple parents? For example, do you go to the 2nd > best parent when the best parent is unreachable? Do you use multiple > parents simultaneously or using different policies? The first scenario > is covered by this OF although implicitly. The second scenario is not > covered. Implementation-specific decision. E.g., Jonathan's layer would alternate = between the parents after a small number of link-layer losses. = Basically, adapt in response to bursts of losses. Phil= From gnawali@cs.stanford.edu Wed Mar 2 17:42:38 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06CB13A6359 for ; Wed, 2 Mar 2011 17:42:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CNUkxdtydP4V for ; Wed, 2 Mar 2011 17:42:37 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 48D393A691B for ; Wed, 2 Mar 2011 17:42:37 -0800 (PST) Received: from mail-gw0-f54.google.com ([74.125.83.54]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1PuxZw-0007cg-66 for roll@ietf.org; Wed, 02 Mar 2011 17:43:44 -0800 Received: by gwj22 with SMTP id 22so277665gwj.27 for ; Wed, 02 Mar 2011 17:43:43 -0800 (PST) Received: by 10.150.144.14 with SMTP id r14mr1059699ybd.28.1299116623110; Wed, 02 Mar 2011 17:43:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.150.192.3 with HTTP; Wed, 2 Mar 2011 17:43:23 -0800 (PST) In-Reply-To: <8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu> References: <20110301003318.9EA863A6CBA@core3.amsl.com> <4D6D311C.8020001@ieee.org> <4D6EAE68.4050104@ieee.org> <7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu> <8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu> From: Omprakash Gnawali Date: Wed, 2 Mar 2011 17:43:23 -0800 Message-ID: To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 127ff6e1eac6b45a32dc112250ed777d Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 01:42:38 -0000 On Wed, Mar 2, 2011 at 5:12 PM, Philip Levis wrote: > > On Mar 2, 2011, at 4:51 PM, Omprakash Gnawali wrote: > >> My goal was it make the language clear that this OF in this version >> has a single parent in the set. >> >> Two specific questions regarding multiple parents - >> >> What rank do you advertise? > > Well, take a look at the RPL spec. It says exactly what you have to advertise. >From rpl-18: "... o When the scan is complete, the preferred parent is elected and the node's rank is computed as the preferred parent rank plus the step in rank with that parent. .." >> How do you use multiple parents? For example, do you go to the 2nd >> best parent when the best parent is unreachable? Do you use multiple >> parents simultaneously or using different policies? The first scenario >> is covered by this OF although implicitly. The second scenario is not >> covered. > > Implementation-specific decision. E.g., Jonathan's layer would alternate between the parents after a small number of link-layer losses. Basically, adapt in response to bursts of losses. Sure. I think Boomerang also had some experience with multiple parents. >From rpl-18: " The OF is used to compute an ordered list of parents." So, I can indicate that an order list of parents is available. I believe those two routing systems picked the neighbor with the smallest path metric as the parent and the 2nd and 3rd shortest as the alternate parents. Some questions for WG - How large should this ordered list be? How do we decide which nodes to put in this list? When we perform parent selection, we pick a node as a parent that allows us to minimize our estimated path cost and rank. So, path through any other neighbor has higher estimated cost. How much higher is ok? - om_p From pal@cs.stanford.edu Wed Mar 2 17:50:17 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E99F3A6927 for ; Wed, 2 Mar 2011 17:50:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lmrYsMsC8JQV for ; Wed, 2 Mar 2011 17:50:16 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id A0F2E3A68DF for ; Wed, 2 Mar 2011 17:50:16 -0800 (PST) Received: from [50.12.161.7] (helo=50-12-161-7.sfo.clearwire-wmx.net) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PuxhK-0007sz-L2; Wed, 02 Mar 2011 17:51:23 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Wed, 2 Mar 2011 17:51:21 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110301003318.9EA863A6CBA@core3.amsl.com> <4D6D311C.8020001@ieee.org> <4D6EAE68.4050104@ieee.org> <7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu> <8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 10362da83454c0a30f3f1339bddfed40 Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification for draft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 01:50:17 -0000 On Mar 2, 2011, at 5:43 PM, Omprakash Gnawali wrote: > On Wed, Mar 2, 2011 at 5:12 PM, Philip Levis = wrote: >>=20 >> On Mar 2, 2011, at 4:51 PM, Omprakash Gnawali wrote: >>=20 >>> My goal was it make the language clear that this OF in this version >>> has a single parent in the set. >>>=20 >>> Two specific questions regarding multiple parents - >>>=20 >>> What rank do you advertise? >>=20 >> Well, take a look at the RPL spec. It says exactly what you have to = advertise. >=20 >=20 > =46rom rpl-18: > "... > o When the scan is complete, the preferred parent is elected and = the > node's rank is computed as the preferred parent rank plus the = step > in rank with that parent. > .." Ugh. This text in 14.1 is misleading/incorrect. The important point is = in 3.5.2 and 8.2.1. 8.2.1 says: 5. A node's rank MUST be greater than all elements of its DODAG parent set. This wording in 14.1 means that your parent set must be of size 1 unless = each results in the same rank computation. Clearly a problem. Note that = 14.1 is not a requirement for following the specification. It probably = deserves a read-through to clean up these kinds of inconsistencies, just = to make people's lives easier. Phil= From pthubert@cisco.com Thu Mar 3 00:46:02 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F27AA3A695D for ; Thu, 3 Mar 2011 00:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rxQMJFR8UpjZ for ; Thu, 3 Mar 2011 00:46:00 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8FCC13A68AF for ; Thu, 3 Mar 2011 00:46:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1528; q=dns/txt; s=iport; t=1299142028; x=1300351628; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=F0mM7q4XjvwJGo1nB+aOGYs6cEwwy3+/sf+4nIJVS6I=; b=KVIPGe5ugY4tWQXZ2c83hfDHENgBfhbgSDZpWqg6w+mLlatSVR9mxXyZ ZDAdFUAqryXXBgVbs+brH8bz4sBV/iGeYoHGgoAWk6xkYJdm07Wyao7dP lO/LZprzHqhPklQUAao8NDNoR/iWbQtpzD1ZKyCHORobazkrxyrJefQFr w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtUEAJ7kbk2Q/khNgWdsb2JhbACmdRUBARYiJaJmnAaFYQSPdIhS X-IronPort-AV: E=Sophos;i="4.62,257,1297036800"; d="scan'208";a="77887778" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 03 Mar 2011 08:47:07 +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 p238l70q030455; Thu, 3 Mar 2011 08:47:07 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Mar 2011 09:47:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Mar 2011 09:47:02 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0405FD39@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 Thread-Index: AcvZRZsONnEGGdNjQ5qKwdGPL2Wq4wAOQYQg References: <20110301003318.9EA863A6CBA@core3.amsl.com><4D6D311C.8020001@ieee.org><4D6EAE68.4050104@ieee.org><7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu><8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "Omprakash Gnawali" X-OriginalArrivalTime: 03 Mar 2011 08:47:07.0128 (UTC) FILETIME=[93A43F80:01CBD97F] Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Mar 2011 08:46:02 -0000 Hi Phil: > > From rpl-18: > > "... > > o When the scan is complete, the preferred parent is elected and the > > node's rank is computed as the preferred parent rank plus the step > > in rank with that parent. > > .." >=20 > Ugh. This text in 14.1 is misleading/incorrect. The important point is in 3.5.2 > and 8.2.1. 8.2.1 says: >=20 > 5. A node's rank MUST be greater than all elements of its DODAG > parent set. >=20 > This wording in 14.1 means that your parent set must be of size 1 unless each > results in the same rank computation. Clearly a problem. Note that 14.1 is not > a requirement for following the specification. It probably deserves a read- > through to clean up these kinds of inconsistencies, just to make people's > lives easier. [Pascal] This wording in 14.1 was expected to mean that a node computes its Rank based on the preferred parent, and then, any neighbor that has a lower Rank is an acceptable parent. So the parent set can be a lot more than 1. Those neighbors can have ranks that are between that of the node and that of its preferred parent, or even ranks that are smaller than that of the preferred parent but for some reasons those neighbors are not preferred, which I expect is very typical of avoiding Worst Path First. The concept of preferred is supposed to help the node being honest about the real metrics to the root. This somewhat means that the preferred parent is also preferred for forwarding up. Cheers, Pascal From pal@cs.stanford.edu Fri Mar 4 09:04:14 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62B523A6946 for ; Fri, 4 Mar 2011 09:04:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jetj9TjCeGMB for ; Fri, 4 Mar 2011 09:04:13 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 436763A6A41 for ; Fri, 4 Mar 2011 09:04:12 -0800 (PST) Received: from [184.193.38.235] (helo=184-193-38-235.pools.spcsdns.net) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PvYRJ-0001Rm-6s; Fri, 04 Mar 2011 09:05:21 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0405FD39@XMB-AMS-107.cisco.com> Date: Fri, 4 Mar 2011 10:04:04 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <0A9CCA13-35C3-4F14-96D6-B522E3DD858A@cs.stanford.edu> References: <20110301003318.9EA863A6CBA@core3.amsl.com><4D6D311C.8020001@ieee.org><4D6EAE68.4050104@ieee.org><7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu><8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0405FD39@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 993826b9125cbf1b907f71dc54053338 Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 17:04:14 -0000 On Mar 3, 2011, at 1:47 AM, Pascal Thubert (pthubert) wrote: > Hi Phil: >=20 > [Pascal] This wording in 14.1 was expected to mean that a node = computes > its Rank based on the preferred parent, and then, any neighbor that = has > a lower Rank is an acceptable parent. So the parent set can be a lot > more than 1. Those neighbors can have ranks that are between that of = the > node and that of its preferred parent, or even ranks that are smaller > than that of the preferred parent but for some reasons those neighbors > are not preferred, which I expect is very typical of avoiding Worst = Path > First. The concept of preferred is supposed to help the node being > honest about the real metrics to the root. This somewhat means that = the > preferred parent is also preferred for forwarding up. This seems backwards, and I think is contrary to how the text in upward = routes was written. The approach described in upward routes is that a = node can have a parent set where the parents differ in Rank. If the = route using element 1...n from the parent set has Rank R1...Rn, then the = node must advertise a Rank >=3D max(R1...Rn). It seems the text in 14.1 has restricted this significantly, as you = state above: if you follow 14.1, then the preferred parent is equal to = max(R1...Rn): it is the worst path. This seems problematic, don't you think? Advertising a Rank >=3D = max(R1...Rn) is honest; the node might pick an element of its parent set = to forward, and so needs to inform other nodes what its worst case Rank = is. Does this make sense? Phil= From pthubert@cisco.com Fri Mar 4 11:03:40 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD3A3A69F0 for ; Fri, 4 Mar 2011 11:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bqnplEO-SG5M for ; Fri, 4 Mar 2011 11:03:39 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id DECFF3A69C7 for ; Fri, 4 Mar 2011 11:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2430; q=dns/txt; s=iport; t=1299265488; x=1300475088; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=coiY1T00wqkNytVviLY3MZkeleTrQ9sR0Jf/QoTkDOE=; b=A8pFcGzvD49lJ9G/mLa3snciiQVTCNt07uCAQBPy1/WR2a5yLoLt2j+Z GlkHCf34sMCQKCj38ZvmXvDuZigW2urr7P0dwy2hJH+kOcfgSD5L1t/F5 8DPJ3+uCZjVVweM5XEPP7GBB82ArWMloZ+rKZZJJNenetMd9t/NEmEwpy c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAHDGcE2Q/khLgWdsb2JhbACmYxUBARYiJaNem2SFYQSPeIhU X-IronPort-AV: E=Sophos;i="4.62,265,1297036800"; d="scan'208";a="20723459" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 04 Mar 2011 19:04:47 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p24J4lrO021866; Fri, 4 Mar 2011 19:04:47 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 4 Mar 2011 20:04:47 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Fri, 4 Mar 2011 20:04:45 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0406047F@XMB-AMS-107.cisco.com> In-Reply-To: <0A9CCA13-35C3-4F14-96D6-B522E3DD858A@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 Thread-Index: AcvajnptBIbhywMRRzWr8FP7Xy5TugADm8Qw References: <20110301003318.9EA863A6CBA@core3.amsl.com><4D6D311C.8020001@ieee.org><4D6EAE68.4050104@ieee.org><7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu><8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0405FD39@XMB-AMS-107.cisco.com> <0A9CCA13-35C3-4F14-96D6-B522E3DD858A@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 04 Mar 2011 19:04:47.0746 (UTC) FILETIME=[07E78620:01CBDA9F] Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 19:03:40 -0000 Hi Phil: > > > > [Pascal] This wording in 14.1 was expected to mean that a node > > computes its Rank based on the preferred parent, and then, any > > neighbor that has a lower Rank is an acceptable parent. So the parent > > set can be a lot more than 1. Those neighbors can have ranks that are > > between that of the node and that of its preferred parent, or even > > ranks that are smaller than that of the preferred parent but for some > > reasons those neighbors are not preferred, which I expect is very > > typical of avoiding Worst Path First. The concept of preferred is > > supposed to help the node being honest about the real metrics to the > > root. This somewhat means that the preferred parent is also preferred for > forwarding up. >=20 > This seems backwards, and I think is contrary to how the text in upward > routes was written. The approach described in upward routes is that a node > can have a parent set where the parents differ in Rank. If the route using > element 1...n from the parent set has Rank R1...Rn, then the node must > advertise a Rank >=3D max(R1...Rn). [Pascal] This is correct. >=20 > It seems the text in 14.1 has restricted this significantly, as you state above: if > you follow 14.1, then the preferred parent is equal to max(R1...Rn): it is the > worst path. [Pascal] I still fail to see how you can read this in 14.1 but if the text leads to such understanding, then I agree it must be amended. The best parent is selected from the metrics properties, not rank. This gives us a reference path against which we can compare other paths. > This seems problematic, don't you think? Advertising a Rank >=3D max(R1...Rn) > is honest; the node might pick an element of its parent set to forward, and so > needs to inform other nodes what its worst case Rank is. >=20 > Does this make sense? [Pascal] Unsure what you really mean. I hope you can spare time at the next IETF to discuss that? If the node uses a rank that is based on a given parent and then uses another parent then it is somewhat lying about the cost. The spec contains the lie within borders by forcing all the other parents to have a rank that is more than self.=20 We decided not to advertise all the metrics of all the parents because if we start that way, then we also need to advertise the ratio that you're using etc... Cheers, Pascal >=20 > Phil From pal@cs.stanford.edu Fri Mar 4 11:55:58 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C685A3A6830 for ; Fri, 4 Mar 2011 11:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NlhM2+pcZPhy for ; Fri, 4 Mar 2011 11:55:57 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id D388A3A6818 for ; Fri, 4 Mar 2011 11:55:57 -0800 (PST) Received: from dn0a21011b.sunet ([10.33.1.27]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Pvb7b-0001Bw-54; Fri, 04 Mar 2011 11:57:07 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0406047F@XMB-AMS-107.cisco.com> Date: Fri, 4 Mar 2011 11:57:06 -0800 Content-Transfer-Encoding: 7bit Message-Id: References: <20110301003318.9EA863A6CBA@core3.amsl.com><4D6D311C.8020001@ieee.org><4D6EAE68.4050104@ieee.org><7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu><8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0405FD39@XMB-AMS-107.cisco.com> <0A9CCA13-35C3-4F14-96D6-B522E3DD858A@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0406047F@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 143d975f4418483bad6282b216f6b212 Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Mar 2011 19:55:58 -0000 On Mar 4, 2011, at 11:04 AM, Pascal Thubert (pthubert) wrote: > Hi Phil: > >>> >>> [Pascal] This wording in 14.1 was expected to mean that a node >>> computes its Rank based on the preferred parent, and then, any >>> neighbor that has a lower Rank is an acceptable parent. So the > parent >>> set can be a lot more than 1. Those neighbors can have ranks that > are >>> between that of the node and that of its preferred parent, or even >>> ranks that are smaller than that of the preferred parent but for > some >>> reasons those neighbors are not preferred, which I expect is very >>> typical of avoiding Worst Path First. The concept of preferred is >>> supposed to help the node being honest about the real metrics to the >>> root. This somewhat means that the preferred parent is also > preferred for >> forwarding up. >> >> This seems backwards, and I think is contrary to how the text in > upward >> routes was written. The approach described in upward routes is that a > node >> can have a parent set where the parents differ in Rank. If the route > using >> element 1...n from the parent set has Rank R1...Rn, then the node must >> advertise a Rank >= max(R1...Rn). > > [Pascal] This is correct. > >> >> It seems the text in 14.1 has restricted this significantly, as you > state above: if >> you follow 14.1, then the preferred parent is equal to max(R1...Rn): > it is the >> worst path. > > [Pascal] I still fail to see how you can read this in 14.1 but if the > text leads to such understanding, then I agree it must be amended. > The best parent is selected from the metrics properties, not rank. This > gives us a reference path against which we can compare other paths. o When the scan is complete, the preferred parent is elected and the node's rank is computed as the preferred parent rank plus the step in rank with that parent. > >> This seems problematic, don't you think? Advertising a Rank >= > max(R1...Rn) >> is honest; the node might pick an element of its parent set to > forward, and so >> needs to inform other nodes what its worst case Rank is. >> >> Does this make sense? > > [Pascal] Unsure what you really mean. I hope you can spare time at the > next IETF to discuss that? > If the node uses a rank that is based on a given parent and then uses > another parent then it is somewhat lying about the cost. > The spec contains the lie within borders by forcing all the other > parents to have a rank that is more than self. > We decided not to advertise all the metrics of all the parents because > if we start that way, then we also need to advertise the ratio that > you're using etc... Sure -- does the above bullet point from 14.1 explain the issue? Phil From gnawali@cs.stanford.edu Fri Mar 4 19:07:17 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 345693A69FC for ; Fri, 4 Mar 2011 19:07:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tx-kQ97FyAXd for ; Fri, 4 Mar 2011 19:07:16 -0800 (PST) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 601FC3A68EA for ; Fri, 4 Mar 2011 19:07:16 -0800 (PST) Received: from mail-iy0-f172.google.com ([209.85.210.172]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Pvhr0-0006h6-3X for roll@ietf.org; Fri, 04 Mar 2011 19:08:26 -0800 Received: by iyj8 with SMTP id 8so2827067iyj.31 for ; Fri, 04 Mar 2011 19:08:25 -0800 (PST) Received: by 10.231.142.21 with SMTP id o21mr1000531ibu.59.1299294505215; Fri, 04 Mar 2011 19:08:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.59.197 with HTTP; Fri, 4 Mar 2011 19:08:05 -0800 (PST) In-Reply-To: References: <20110301003318.9EA863A6CBA@core3.amsl.com> <4D6D311C.8020001@ieee.org> <4D6EAE68.4050104@ieee.org> <7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu> <8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0405FD39@XMB-AMS-107.cisco.com> <0A9CCA13-35C3-4F14-96D6-B522E3DD858A@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0406047F@XMB-AMS-107.cisco.com> From: Omprakash Gnawali Date: Fri, 4 Mar 2011 19:08:05 -0800 Message-ID: To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 0858a923cc4ba3562bb802375c61c59b Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 03:07:17 -0000 On Fri, Mar 4, 2011 at 11:57 AM, Philip Levis wrote: > > On Mar 4, 2011, at 11:04 AM, Pascal Thubert (pthubert) wrote: > >> Hi Phil: >> >>>> >>>> [Pascal] This wording in 14.1 was expected to mean that a node >>>> computes its Rank based on the preferred parent, and then, any >>>> neighbor that has a lower Rank is an acceptable parent. So the >> parent >>>> set can be a lot more than 1. Those neighbors can have ranks that >> are >>>> between that of the node and that of its preferred parent, or even >>>> ranks that are smaller than that of the preferred parent but for >> some >>>> reasons those neighbors are not preferred, which I expect is very >>>> typical of avoiding Worst Path First. The concept of preferred is >>>> supposed to help the node being honest about the real metrics to the >>>> root. This somewhat means that the preferred parent is also >> preferred for >>> forwarding up. >>> >>> This seems backwards, and I think is contrary to how the text in >> upward >>> routes was written. The approach described in upward routes is that a >> node >>> can have a parent set where the parents differ in Rank. If the route >> using >>> element 1...n from the parent set has Rank R1...Rn, then the node must >>> advertise a Rank >=3D max(R1...Rn). >> >> [Pascal] This is correct. >> >>> >>> It seems the text in 14.1 has restricted this significantly, as you >> state above: if >>> you follow 14.1, then the preferred parent is equal to max(R1...Rn): >> it is the >>> worst path. >> >> [Pascal] I still fail to see how you can read this in 14.1 but if the >> text leads to such understanding, then I agree it must be amended. >> The best parent is selected from the metrics properties, not rank. This >> gives us a reference path against which we can compare other paths. > > > =A0o =A0When the scan is complete, the preferred parent is elected and th= e > =A0 =A0 =A0node's rank is computed as the preferred parent rank plus the = step > =A0 =A0 =A0in rank with that parent. > > >> >>> This seems problematic, don't you think? Advertising a Rank >=3D >> max(R1...Rn) >>> is honest; the node might pick an element of its parent set to >> forward, and so >>> needs to inform other nodes what its worst case Rank is. >>> >>> Does this make sense? >> >> [Pascal] Unsure what you really mean. I hope you can spare time at the >> next IETF to discuss that? >> If the node uses a rank that is based on a given parent and then uses >> another parent then it is somewhat lying about the cost. >> The spec contains the lie within borders by forcing all the other >> parents to have a rank that is more than self. >> We decided not to advertise all the metrics of all the parents because >> if we start that way, then we also need to advertise the ratio that >> you're using etc... > > Sure -- does the above bullet point from 14.1 explain the issue? Based on the text in the OF section, this is definitely an issue. In RPL draft, rather than prescribe how OF computes rank in such detail, I would prefer to describe the input and output and leave the details about how the rank is computed to the OF drafts. That way we would also eliminate the contradiction we are discussing here. - om_p From gnawali@cs.stanford.edu Fri Mar 4 19:15:06 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D86D63A69F3 for ; Fri, 4 Mar 2011 19:15:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a7mjMuqgS94Q for ; Fri, 4 Mar 2011 19:15:06 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 29C8A3A69E7 for ; Fri, 4 Mar 2011 19:15:06 -0800 (PST) Received: from mail-iw0-f172.google.com ([209.85.214.172]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Pvhya-0003jf-4a for roll@ietf.org; Fri, 04 Mar 2011 19:16:16 -0800 Received: by iwl42 with SMTP id 42so2875050iwl.31 for ; Fri, 04 Mar 2011 19:16:15 -0800 (PST) Received: by 10.231.3.142 with SMTP id 14mr988120ibn.84.1299294958219; Fri, 04 Mar 2011 19:15:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.59.197 with HTTP; Fri, 4 Mar 2011 19:15:38 -0800 (PST) In-Reply-To: References: <20110221221135.082AE3A7153@core3.amsl.com> From: Omprakash Gnawali Date: Fri, 4 Mar 2011 19:15:38 -0800 Message-ID: To: Ulrich Herberg Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: acf3039aa8d32d1ac60a71149e52b94c Cc: ROLL WG Subject: Re: [Roll] Fwd: New Version Notification for draft-gnawali-roll-rpl-recommendations-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2011 03:15:06 -0000 On Tue, Feb 22, 2011 at 1:16 AM, Ulrich Herberg wrote: ... > In item 5, it could be worth explaining why poisoning does not avoid loops, > maybe with an example. Moreover, one could add a section explaining how to > reduce the probability of loops when poisoning (e.g. by waiting some time > before processing any DIO messages). I think the simplest example is packet loss. Rather than complicate the discussion, I was thinking of just mentioning this simple example. Poisoning might be useful but it is important to be aware of its limitations and cost. > I also think it could be worth giving some recommendations on how (or better > *when*) to send DAO and DAOACK messages (see my previous emails on that > matter). I can make an educated guess but do not have personal experience with DAO intervals and their implications nor input from the WG so I hesitate to add anything to the draft regarding this issue at the moment. I am open to input from the WG. - om_p From pthubert@cisco.com Tue Mar 8 05:24:36 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F8F83A684F for ; Tue, 8 Mar 2011 05:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.449 X-Spam-Level: X-Spam-Status: No, score=-9.449 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, MANGLED_PILL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUe7KuoYz7Bk for ; Tue, 8 Mar 2011 05:24:30 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DF8053A67E4 for ; Tue, 8 Mar 2011 05:24:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=7514; q=dns/txt; s=iport; t=1299590745; x=1300800345; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=A0HmdABkDVVRcMGyOGE1mS8iNwMIxFpJUjQSSpLc68k=; b=XfRJ783ZMWu7b0zbBSV8Eeb8xD7l2QbMSKllX3hjNPRu0BN04emjYrd8 fdEAQTgaxTJdhA/jPbD3+ZUmaK9vTFLN8uD9XgznAlPh/SbOgF1/crvZX C+3zZLt43IRYeC78qRJZDlHQ8yM4VGf/iUEvm+Xhy3m5PLbD7yFRjKtXx E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAMm8dU2Q/khMgWdsb2JhbACYE44tFQEBFiIlolecSIVjBI9/iFY X-IronPort-AV: E=Sophos;i="4.62,284,1297036800"; d="scan'208";a="78309156" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 08 Mar 2011 13:25:44 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p28DPiE5032164; Tue, 8 Mar 2011 13:25:44 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Mar 2011 14:25:44 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Mar 2011 14:25:40 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D040FFC6E@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 Thread-Index: Acva4pobBpq54z9SQyuWX54NIjMaJQBBNVlQ References: <20110301003318.9EA863A6CBA@core3.amsl.com> <4D6D311C.8020001@ieee.org> <4D6EAE68.4050104@ieee.org> <7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu> <8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0405FD39@XMB-AMS-107.cisco.com> <0A9CCA13-35C3-4F14-96D6-B522E3DD858A@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0406047F@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Omprakash Gnawali" , "Philip Levis" X-OriginalArrivalTime: 08 Mar 2011 13:25:44.0006 (UTC) FILETIME=[53BE2660:01CBDD94] Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 13:24:37 -0000 Hi Om and Phil: Several things: In one hand I agree with Om that we must leave liberty to the OF to be = what they need to be. Earlier versions tried to implement what you're = asking now, that is specify an abstract interface to the OF and be done. = For some reasons, that text faced opposition and it was removed. My = suggestion here would be to start a separate draft to propose some APIs. = OTOH, though the main spec does not wish to be on the way of the OF, it = tries to make some design recommendations. And the most critical one is = probably to avoid the so-called "greediness" issue. To do this, the = draft recommends to compute a reference path through a preferred = parent, and define the rank and the advertised metrics based on that = path. This is no absolute (uppercase) must and we can make that more = clear without requiring a new last call, and I'm open to such editorial = change. But I fail to see any "contradiction" in the current text.=20 In my view, this text : " o When the scan is complete, the preferred parent is elected and the node's rank is computed as the preferred parent rank plus the step in rank with that parent. " Certainly does not mean that: " the preferred parent is equal to max(R1...Rn): " Let's take an example: | root | | | P1 | =20 | P2 | P3 | =20 | N =20 | =20 V Rank Node N sees a number of other nodes, including P1, P2, ... Pi of = respective ranks R1, R2, ... Ri Say that for the metrics at hand P1 is "close" and parented to the root = and far from N. The metrics from P1 to root is good but from N to P1, it = is real bad. P1 is typically the Worst path first next hop that we do = not wish to favor. Say that P2 is closer to N, P2 has both P1 and root as parents, root = preferred. The metrics P2 to root is not as good as P1 to root but the = overall metrics N-> root via P2 is better than via P1. Then comes P3. P3 is somewhere "between" P2 and N. It is parented at P1 = and P2, P1 preferred . The overall metrics N-> root via P2 is better = than via P3. Thus P2 is preferred parent. This N's Rank RN is computed = off P2. In terms of Rank, say we get for given OF: R1 =3D 5 R2 =3D R1 + step(P2->P1) =3D 5 + 3 =3D 8 R3 =3D R1 + step(P3->P1) =3D 5 + 5 =3D 10 RN =3D R2 + step(P2->P1) =3D 8 + 4 =3D 12 Because RN is more than R1, R2 and R3, P1 P2 and P3 can all be selected = as parents for node N. But the best balance between the first hop and = the rest of the way is N->P2->P1 and that's why P2 is preferred parent. And the rank of the preferred parent is certainly not ' equal to = max(R1...Rn)' - that would be P3. So: - I still do not see that we have a problem=20 - I'm fine with lowering the shield slightly in 14.1 to ensure that = people understand that this text is a generic recommendation but that = the OF may override it. - We must be clear we need to avoid a greedy behavior by which P3 would = increase its Rank to get N as an additional parent. What greedy P3 = gains, N loses, which is unfair. More, if N decides to be greedy and = also augment its Rank, we are in a loop and that creates instabilities. = It seems to me that the current text prevents greediness by forcing = nodes to be true to their metrics. I do not wish to add a lot of text to = discuss greediness and so it would be nice that a rewording still = maintains that property without writing a book. Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Omprakash Gnawali [mailto:gnawali@cs.stanford.edu] > Sent: Saturday, March 05, 2011 4:08 AM > To: Philip Levis > Cc: Pascal Thubert (pthubert); roll@ietf.org; phoebus@ieee.org > Subject: Re: [Roll] Fwd: New Version Notification = fordraft-ietf-roll-minrank- > hysteresis-of-01 >=20 > On Fri, Mar 4, 2011 at 11:57 AM, Philip Levis = wrote: > > > > On Mar 4, 2011, at 11:04 AM, Pascal Thubert (pthubert) wrote: > > > >> Hi Phil: > >> > >>>> > >>>> [Pascal] This wording in 14.1 was expected to mean that a node > >>>> computes its Rank based on the preferred parent, and then, any > >>>> neighbor that has a lower Rank is an acceptable parent. So the > >> parent > >>>> set can be a lot more than 1. Those neighbors can have ranks that > >> are > >>>> between that of the node and that of its preferred parent, or = even > >>>> ranks that are smaller than that of the preferred parent but for > >> some > >>>> reasons those neighbors are not preferred, which I expect is very > >>>> typical of avoiding Worst Path First. The concept of preferred is > >>>> supposed to help the node being honest about the real metrics to > >>>> the root. This somewhat means that the preferred parent is also > >> preferred for > >>> forwarding up. > >>> > >>> This seems backwards, and I think is contrary to how the text in > >> upward > >>> routes was written. The approach described in upward routes is = that > >>> a > >> node > >>> can have a parent set where the parents differ in Rank. If the = route > >> using > >>> element 1...n from the parent set has Rank R1...Rn, then the node > >>> must advertise a Rank >=3D max(R1...Rn). > >> > >> [Pascal] This is correct. > >> > >>> > >>> It seems the text in 14.1 has restricted this significantly, as = you > >> state above: if > >>> you follow 14.1, then the preferred parent is equal to = max(R1...Rn): > >> it is the > >>> worst path. > >> > >> [Pascal] I still fail to see how you can read this in 14.1 but if = the > >> text leads to such understanding, then I agree it must be amended. > >> The best parent is selected from the metrics properties, not rank. > >> This gives us a reference path against which we can compare other = paths. > > > > > > =A0o =A0When the scan is complete, the preferred parent is elected = and the > > =A0 =A0 =A0node's rank is computed as the preferred parent rank plus = the > > step > > =A0 =A0 =A0in rank with that parent. > > > > > >> > >>> This seems problematic, don't you think? Advertising a Rank >=3D > >> max(R1...Rn) > >>> is honest; the node might pick an element of its parent set to > >> forward, and so > >>> needs to inform other nodes what its worst case Rank is. > >>> > >>> Does this make sense? > >> > >> [Pascal] Unsure what you really mean. I hope you can spare time at > >> the next IETF to discuss that? > >> If the node uses a rank that is based on a given parent and then = uses > >> another parent then it is somewhat lying about the cost. > >> The spec contains the lie within borders by forcing all the other > >> parents to have a rank that is more than self. > >> We decided not to advertise all the metrics of all the parents > >> because if we start that way, then we also need to advertise the > >> ratio that you're using etc... > > > > Sure -- does the above bullet point from 14.1 explain the issue? >=20 > Based on the text in the OF section, this is definitely an issue. >=20 > In RPL draft, rather than prescribe how OF computes rank in such = detail, I > would prefer to describe the input and output and leave the details = about > how the rank is computed to the OF drafts. That way we would also = eliminate > the contradiction we are discussing here. >=20 > - om_p From c.chauvenet@watteco.com Tue Mar 8 06:04:11 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 069BE3A63CB for ; Tue, 8 Mar 2011 06:04:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.949 X-Spam-Level: X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[AWL=-2.650, BAYES_00=-2.599, MANGLED_PILL=2.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBHg5pqkoX6b for ; Tue, 8 Mar 2011 06:04:09 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1outboundpool.messaging.microsoft.com [216.32.181.182]) by core3.amsl.com (Postfix) with ESMTP id 6D9603A67BD for ; Tue, 8 Mar 2011 06:04:08 -0800 (PST) Received: from mail37-ch1-R.bigfish.com (216.32.181.169) by CH1EHSOBE011.bigfish.com (10.43.70.61) with Microsoft SMTP Server id 14.1.225.8; Tue, 8 Mar 2011 14:05:22 +0000 Received: from mail37-ch1 (localhost.localdomain [127.0.0.1]) by mail37-ch1-R.bigfish.com (Postfix) with ESMTP id 8F8947C0386; Tue, 8 Mar 2011 14:05:22 +0000 (UTC) X-SpamScore: -97 X-BigFish: VPS-97(zf7Iz542N1432N15caKJ98dN9371Pzz1202hzz8275bh8275dh1033ILz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB012.red002.local; RD:none; EFVD:NLI Received: from mail37-ch1 (localhost.localdomain [127.0.0.1]) by mail37-ch1 (MessageSwitch) id 1299593121620075_24706; Tue, 8 Mar 2011 14:05:21 +0000 (UTC) Received: from CH1EHSMHS006.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.250]) by mail37-ch1.bigfish.com (Postfix) with ESMTP id 94B021438051; Tue, 8 Mar 2011 14:05:21 +0000 (UTC) Received: from IE2RD2HUB012.red002.local (213.199.187.153) by CH1EHSMHS006.bigfish.com (10.43.70.6) with Microsoft SMTP Server (TLS) id 14.1.225.22; Tue, 8 Mar 2011 14:05:21 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB012.red002.local ([10.33.16.251]) with mapi; Tue, 8 Mar 2011 06:05:12 -0800 From: C Chauvenet To: "Pascal Thubert (pthubert)" , Omprakash Gnawali , Philip Levis Date: Tue, 8 Mar 2011 06:05:36 -0800 Thread-Topic: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 Thread-Index: Acva4pobBpq54z9SQyuWX54NIjMaJQBBNVlQAGwyroA= Message-ID: References: <20110301003318.9EA863A6CBA@core3.amsl.com> <4D6D311C.8020001@ieee.org> <4D6EAE68.4050104@ieee.org> <7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu> <8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0405FD39@XMB-AMS-107.cisco.com> <0A9CCA13-35C3-4F14-96D6-B522E3DD858A@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0406047F@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D040FFC6E@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D040FFC6E@XMB-AMS-107.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "roll@ietf.org" , "phoebus@ieee.org" Subject: Re: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 14:04:11 -0000 Hi Pascal, all,=20 In your example : R1 =3D 5 R2 =3D R1 + step(P2->P1) =3D 5 + 3 =3D 8 R3 =3D R1 + step(P3->P1) =3D 5 + 5 =3D 10 RN =3D R2 + step(P2->P1) =3D 8 + 4 =3D 12 I guess the last line should rather be : RN =3D R2 + step(N->P2) =3D 8 + 4 = =3D 12. Otherwise, I really like your example and agree that the section 14.1 your = are refering to is quite explicit and may not mean a " max(R1...Rn)" compu= tation. If people find it unclear, it may be reworded, but I find it unders= tandable as is. Furthermore, more guidelines may be added in a seperate doc= ument like the recommendation draft that is currently ongoing. Best, C=E9dric. -----Message d'origine----- De=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de P= ascal Thubert (pthubert) Envoy=E9=A0: mardi 8 mars 2011 14:26 =C0=A0: Omprakash Gnawali; Philip Levis Cc=A0: roll@ietf.org; phoebus@ieee.org Objet=A0: Re: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minra= nk-hysteresis-of-01 Hi Om and Phil: Several things: In one hand I agree with Om that we must leave liberty to the OF to be what= they need to be. Earlier versions tried to implement what you're asking no= w, that is specify an abstract interface to the OF and be done. For some re= asons, that text faced opposition and it was removed. My suggestion here wo= uld be to start a separate draft to propose some APIs.=20 OTOH, though the main spec does not wish to be on the way of the OF, it tri= es to make some design recommendations. And the most critical one is probab= ly to avoid the so-called "greediness" issue. To do this, the draft recomme= nds to compute a reference path through a preferred parent, and define the= rank and the advertised metrics based on that path. This is no absolute (u= ppercase) must and we can make that more clear without requiring a new last= call, and I'm open to such editorial change. But I fail to see any "contradiction" in the current text.=20 In my view, this text : " o When the scan is complete, the preferred parent is elected and the node's rank is computed as the preferred parent rank plus the step in rank with that parent. " Certainly does not mean that: " the preferred parent is equal to max(R1...Rn): " Let's take an example: | root | | | P1 | =20 | P2 | P3 | =20 | N =20 | =20 V Rank Node N sees a number of other nodes, including P1, P2, ... Pi of respectiv= e ranks R1, R2, ... Ri Say that for the metrics at hand P1 is "close" and parented to the root and= far from N. The metrics from P1 to root is good but from N to P1, it is re= al bad. P1 is typically the Worst path first next hop that we do not wish t= o favor. Say that P2 is closer to N, P2 has both P1 and root as parents, root prefe= rred. The metrics P2 to root is not as good as P1 to root but the overall m= etrics N-> root via P2 is better than via P1. Then comes P3. P3 is somewhere "between" P2 and N. It is parented at P1 and= P2, P1 preferred . The overall metrics N-> root via P2 is better than via = P3. Thus P2 is preferred parent. This N's Rank RN is computed off P2. In terms of Rank, say we get for given OF: R1 =3D 5 R2 =3D R1 + step(P2->P1) =3D 5 + 3 =3D 8 R3 =3D R1 + step(P3->P1) =3D 5 + 5 =3D 10 RN =3D R2 + step(P2->P1) =3D 8 + 4 =3D 12 Because RN is more than R1, R2 and R3, P1 P2 and P3 can all be selected as = parents for node N. But the best balance between the first hop and the rest= of the way is N->P2->P1 and that's why P2 is preferred parent. And the rank of the preferred parent is certainly not ' equal to max(R1...R= n)' - that would be P3. So: - I still do not see that we have a problem=20 - I'm fine with lowering the shield slightly in 14.1 to ensure that people = understand that this text is a generic recommendation but that the OF may o= verride it. - We must be clear we need to avoid a greedy behavior by which P3 would inc= rease its Rank to get N as an additional parent. What greedy P3 gains, N lo= ses, which is unfair. More, if N decides to be greedy and also augment its = Rank, we are in a loop and that creates instabilities. It seems to me that = the current text prevents greediness by forcing nodes to be true to their m= etrics. I do not wish to add a lot of text to discuss greediness and so it = would be nice that a rewording still maintains that property without writin= g a book. Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Omprakash Gnawali [mailto:gnawali@cs.stanford.edu] > Sent: Saturday, March 05, 2011 4:08 AM > To: Philip Levis > Cc: Pascal Thubert (pthubert); roll@ietf.org; phoebus@ieee.org > Subject: Re: [Roll] Fwd: New Version Notification=20 > fordraft-ietf-roll-minrank- > hysteresis-of-01 >=20 > On Fri, Mar 4, 2011 at 11:57 AM, Philip Levis wrote= : > > > > On Mar 4, 2011, at 11:04 AM, Pascal Thubert (pthubert) wrote: > > > >> Hi Phil: > >> > >>>> > >>>> [Pascal] This wording in 14.1 was expected to mean that a node=20 > >>>> computes its Rank based on the preferred parent, and then, any=20 > >>>> neighbor that has a lower Rank is an acceptable parent. So the > >> parent > >>>> set can be a lot more than 1. Those neighbors can have ranks that > >> are > >>>> between that of the node and that of its preferred parent, or=20 > >>>> even ranks that are smaller than that of the preferred parent but=20 > >>>> for > >> some > >>>> reasons those neighbors are not preferred, which I expect is very=20 > >>>> typical of avoiding Worst Path First. The concept of preferred is=20 > >>>> supposed to help the node being honest about the real metrics to=20 > >>>> the root. This somewhat means that the preferred parent is also > >> preferred for > >>> forwarding up. > >>> > >>> This seems backwards, and I think is contrary to how the text in > >> upward > >>> routes was written. The approach described in upward routes is=20 > >>> that a > >> node > >>> can have a parent set where the parents differ in Rank. If the=20 > >>> route > >> using > >>> element 1...n from the parent set has Rank R1...Rn, then the node=20 > >>> must advertise a Rank >=3D max(R1...Rn). > >> > >> [Pascal] This is correct. > >> > >>> > >>> It seems the text in 14.1 has restricted this significantly, as=20 > >>> you > >> state above: if > >>> you follow 14.1, then the preferred parent is equal to max(R1...Rn): > >> it is the > >>> worst path. > >> > >> [Pascal] I still fail to see how you can read this in 14.1 but if=20 > >> the text leads to such understanding, then I agree it must be amended. > >> The best parent is selected from the metrics properties, not rank. > >> This gives us a reference path against which we can compare other path= s. > > > > > > =A0o =A0When the scan is complete, the preferred parent is elected and= =20 > > the > > =A0 =A0 =A0node's rank is computed as the preferred parent rank plus th= e=20 > > step > > =A0 =A0 =A0in rank with that parent. > > > > > >> > >>> This seems problematic, don't you think? Advertising a Rank >=3D > >> max(R1...Rn) > >>> is honest; the node might pick an element of its parent set to > >> forward, and so > >>> needs to inform other nodes what its worst case Rank is. > >>> > >>> Does this make sense? > >> > >> [Pascal] Unsure what you really mean. I hope you can spare time at=20 > >> the next IETF to discuss that? > >> If the node uses a rank that is based on a given parent and then=20 > >> uses another parent then it is somewhat lying about the cost. > >> The spec contains the lie within borders by forcing all the other=20 > >> parents to have a rank that is more than self. > >> We decided not to advertise all the metrics of all the parents=20 > >> because if we start that way, then we also need to advertise the=20 > >> ratio that you're using etc... > > > > Sure -- does the above bullet point from 14.1 explain the issue? >=20 > Based on the text in the OF section, this is definitely an issue. >=20 > In RPL draft, rather than prescribe how OF computes rank in such=20 > detail, I would prefer to describe the input and output and leave the=20 > details about how the rank is computed to the OF drafts. That way we=20 > would also eliminate the contradiction we are discussing here. >=20 > - om_p _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Tue Mar 8 07:25:21 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 69A433A687A for ; Tue, 8 Mar 2011 07:25:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.344 X-Spam-Level: X-Spam-Status: No, score=-9.344 tagged_above=-999 required=5 tests=[AWL=-1.045, BAYES_00=-2.599, MANGLED_PILL=2.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnzlmeiLzfWp for ; Tue, 8 Mar 2011 07:25:19 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DB71D3A63CB for ; Tue, 8 Mar 2011 07:25:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=9832; q=dns/txt; s=iport; t=1299597994; x=1300807594; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=BvaKHUTiYtWIb2he/GWJnCBV2z7gasMGo3O5dBAw4aE=; b=jf8x42MOWeTEyYiQeyiqqzHQ2QjPC+4wtP74Gvqq3IZwnBichO1/fD/1 GMZZYf4jUJht4Y5gUIR0142kipu+0JPiRE1U1LG3y6Hn1xsh5tESOQyZH 9Xzy1KbLqUezaqmLUb5GlyVXVFZns0KqfaSVq+zxpwY9tScRQ+Xs5VTVu M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucAAAvadU2Q/khNgWdsb2JhbACYE44tFQEBFiIlonOcPIVjBI9/iFY X-IronPort-AV: E=Sophos;i="4.62,284,1297036800"; d="scan'208";a="78323868" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 08 Mar 2011 15:26:20 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p28FQKbL018175; Tue, 8 Mar 2011 15:26:20 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Mar 2011 16:26:20 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Mar 2011 16:26:13 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D040FFD2C@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: New Version Notificationfordraft-ietf-roll-minrank-hysteresis-of-01 Thread-Index: Acva4pobBpq54z9SQyuWX54NIjMaJQBBNVlQAGwyroAAAy6ggA== References: <20110301003318.9EA863A6CBA@core3.amsl.com><4D6D311C.8020001@ieee.org><4D6EAE68.4050104@ieee.org><7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu><8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu><6A2A459175DABE4BB11DE2026AA50A5D0405FD39@XMB-AMS-107.cisco.com><0A9CCA13-35C3-4F14-96D6-B522E3DD858A@cs.stanford.edu><6A2A459175DABE4BB11DE2026AA50A5D0406047F@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D040FFC6E@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "C Chauvenet" , "Omprakash Gnawali" , "Philip Levis" X-OriginalArrivalTime: 08 Mar 2011 15:26:20.0764 (UTC) FILETIME=[2D2FC9C0:01CBDDA5] Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notificationfordraft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 15:25:21 -0000 Good catch : )=20 In fact my mistake was:=20 Say that P2 is closer to N, P2 has both P1 and root as parents, root = preferred=20 ->=20 Say that P2 is closer to N, P2 has both P1 and root as parents, P1 = preferred. Same result though... Thanks for all : ) Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: C Chauvenet [mailto:c.chauvenet@watteco.com] > Sent: Tuesday, March 08, 2011 3:06 PM > To: Pascal Thubert (pthubert); Omprakash Gnawali; Philip Levis > Cc: roll@ietf.org; phoebus@ieee.org > Subject: RE: [Roll] Fwd: New Version = Notificationfordraft-ietf-roll-minrank- > hysteresis-of-01 >=20 > Hi Pascal, all, >=20 > In your example : >=20 > R1 =3D 5 > R2 =3D R1 + step(P2->P1) =3D 5 + 3 =3D 8 > R3 =3D R1 + step(P3->P1) =3D 5 + 5 =3D 10 > RN =3D R2 + step(P2->P1) =3D 8 + 4 =3D 12 >=20 > I guess the last line should rather be : RN =3D R2 + step(N->P2) =3D 8 = + 4 =3D 12. >=20 > Otherwise, I really like your example and agree that the section 14.1 = your are > refering to is quite explicit and may not mean a " max(R1...Rn)" = computation. > If people find it unclear, it may be reworded, but I find it = understandable as > is. Furthermore, more guidelines may be added in a seperate document = like > the recommendation draft that is currently ongoing. >=20 > Best, >=20 > C=E9dric. >=20 > -----Message d'origine----- > De=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part = de Pascal > Thubert (pthubert) Envoy=E9=A0: mardi 8 mars 2011 14:26 =C0=A0: = Omprakash Gnawali; > Philip Levis Cc=A0: roll@ietf.org; phoebus@ieee.org Objet=A0: Re: = [Roll] Fwd: New > Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 >=20 > Hi Om and Phil: >=20 > Several things: >=20 > In one hand I agree with Om that we must leave liberty to the OF to be = what > they need to be. Earlier versions tried to implement what you're = asking now, > that is specify an abstract interface to the OF and be done. For some = reasons, > that text faced opposition and it was removed. My suggestion here = would be > to start a separate draft to propose some APIs. >=20 > OTOH, though the main spec does not wish to be on the way of the OF, = it > tries to make some design recommendations. And the most critical one = is > probably to avoid the so-called "greediness" issue. To do this, the = draft > recommends to compute a reference path through a preferred parent, = and > define the rank and the advertised metrics based on that path. This is = no > absolute (uppercase) must and we can make that more clear without > requiring a new last call, and I'm open to such editorial change. >=20 > But I fail to see any "contradiction" in the current text. >=20 > In my view, this text : > " > o When the scan is complete, the preferred parent is elected and = the > node's rank is computed as the preferred parent rank plus the = step > in rank with that parent. > " >=20 > Certainly does not mean that: >=20 > " > the preferred parent is equal to max(R1...Rn): > " >=20 > Let's take an example: >=20 > | root > | > | > | P1 > | > | P2 > | P3 > | > | N > | > V Rank >=20 >=20 >=20 > Node N sees a number of other nodes, including P1, P2, ... Pi of = respective > ranks R1, R2, ... Ri >=20 > Say that for the metrics at hand P1 is "close" and parented to the = root and far > from N. The metrics from P1 to root is good but from N to P1, it is = real bad. P1 > is typically the Worst path first next hop that we do not wish to = favor. >=20 > Say that P2 is closer to N, P2 has both P1 and root as parents, root = preferred. > The metrics P2 to root is not as good as P1 to root but the overall = metrics N-> > root via P2 is better than via P1. >=20 > Then comes P3. P3 is somewhere "between" P2 and N. It is parented at = P1 > and P2, P1 preferred . The overall metrics N-> root via P2 is better = than via > P3. Thus P2 is preferred parent. This N's Rank RN is computed off P2. >=20 > In terms of Rank, say we get for given OF: >=20 > R1 =3D 5 > R2 =3D R1 + step(P2->P1) =3D 5 + 3 =3D 8 > R3 =3D R1 + step(P3->P1) =3D 5 + 5 =3D 10 > RN =3D R2 + step(P2->P1) =3D 8 + 4 =3D 12 >=20 > Because RN is more than R1, R2 and R3, P1 P2 and P3 can all be = selected as > parents for node N. But the best balance between the first hop and the = rest > of the way is N->P2->P1 and that's why P2 is preferred parent. > And the rank of the preferred parent is certainly not ' equal to = max(R1...Rn)' - > that would be P3. >=20 > So: >=20 > - I still do not see that we have a problem >=20 > - I'm fine with lowering the shield slightly in 14.1 to ensure that = people > understand that this text is a generic recommendation but that the OF = may > override it. >=20 > - We must be clear we need to avoid a greedy behavior by which P3 = would > increase its Rank to get N as an additional parent. What greedy P3 = gains, N > loses, which is unfair. More, if N decides to be greedy and also = augment its > Rank, we are in a loop and that creates instabilities. It seems to me = that the > current text prevents greediness by forcing nodes to be true to their = metrics. > I do not wish to add a lot of text to discuss greediness and so it = would be nice > that a rewording still maintains that property without writing a book. >=20 > Cheers, >=20 > Pascal > http://www.xtranormal.com/watch/7011357/ >=20 >=20 > > -----Original Message----- > > From: Omprakash Gnawali [mailto:gnawali@cs.stanford.edu] > > Sent: Saturday, March 05, 2011 4:08 AM > > To: Philip Levis > > Cc: Pascal Thubert (pthubert); roll@ietf.org; phoebus@ieee.org > > Subject: Re: [Roll] Fwd: New Version Notification > > fordraft-ietf-roll-minrank- > > hysteresis-of-01 > > > > On Fri, Mar 4, 2011 at 11:57 AM, Philip Levis = wrote: > > > > > > On Mar 4, 2011, at 11:04 AM, Pascal Thubert (pthubert) wrote: > > > > > >> Hi Phil: > > >> > > >>>> > > >>>> [Pascal] This wording in 14.1 was expected to mean that a node > > >>>> computes its Rank based on the preferred parent, and then, any > > >>>> neighbor that has a lower Rank is an acceptable parent. So the > > >> parent > > >>>> set can be a lot more than 1. Those neighbors can have ranks = that > > >> are > > >>>> between that of the node and that of its preferred parent, or > > >>>> even ranks that are smaller than that of the preferred parent = but > > >>>> for > > >> some > > >>>> reasons those neighbors are not preferred, which I expect is = very > > >>>> typical of avoiding Worst Path First. The concept of preferred = is > > >>>> supposed to help the node being honest about the real metrics = to > > >>>> the root. This somewhat means that the preferred parent is also > > >> preferred for > > >>> forwarding up. > > >>> > > >>> This seems backwards, and I think is contrary to how the text in > > >> upward > > >>> routes was written. The approach described in upward routes is > > >>> that a > > >> node > > >>> can have a parent set where the parents differ in Rank. If the > > >>> route > > >> using > > >>> element 1...n from the parent set has Rank R1...Rn, then the = node > > >>> must advertise a Rank >=3D max(R1...Rn). > > >> > > >> [Pascal] This is correct. > > >> > > >>> > > >>> It seems the text in 14.1 has restricted this significantly, as > > >>> you > > >> state above: if > > >>> you follow 14.1, then the preferred parent is equal to = max(R1...Rn): > > >> it is the > > >>> worst path. > > >> > > >> [Pascal] I still fail to see how you can read this in 14.1 but if > > >> the text leads to such understanding, then I agree it must be = amended. > > >> The best parent is selected from the metrics properties, not = rank. > > >> This gives us a reference path against which we can compare other > paths. > > > > > > > > > =A0o =A0When the scan is complete, the preferred parent is elected = and > > > the > > > =A0 =A0 =A0node's rank is computed as the preferred parent rank = plus the > > > step > > > =A0 =A0 =A0in rank with that parent. > > > > > > > > >> > > >>> This seems problematic, don't you think? Advertising a Rank >=3D > > >> max(R1...Rn) > > >>> is honest; the node might pick an element of its parent set to > > >> forward, and so > > >>> needs to inform other nodes what its worst case Rank is. > > >>> > > >>> Does this make sense? > > >> > > >> [Pascal] Unsure what you really mean. I hope you can spare time = at > > >> the next IETF to discuss that? > > >> If the node uses a rank that is based on a given parent and then > > >> uses another parent then it is somewhat lying about the cost. > > >> The spec contains the lie within borders by forcing all the other > > >> parents to have a rank that is more than self. > > >> We decided not to advertise all the metrics of all the parents > > >> because if we start that way, then we also need to advertise the > > >> ratio that you're using etc... > > > > > > Sure -- does the above bullet point from 14.1 explain the issue? > > > > Based on the text in the OF section, this is definitely an issue. > > > > In RPL draft, rather than prescribe how OF computes rank in such > > detail, I would prefer to describe the input and output and leave = the > > details about how the rank is computed to the OF drafts. That way we > > would also eliminate the contradiction we are discussing here. > > > > - om_p > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From c.chauvenet@watteco.com Tue Mar 8 08:06:36 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 999003A691D for ; Tue, 8 Mar 2011 08:06:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.064 X-Spam-Level: X-Spam-Status: No, score=-2.064 tagged_above=-999 required=5 tests=[AWL=-1.885, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIg4ftQgmu2Q for ; Tue, 8 Mar 2011 08:06:30 -0800 (PST) Received: from TX2EHSOBE001.bigfish.com (mail-tx2.bigfish.com [65.55.88.10]) by core3.amsl.com (Postfix) with ESMTP id C1B573A68D9 for ; Tue, 8 Mar 2011 08:06:29 -0800 (PST) Received: from mail180-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Tue, 8 Mar 2011 16:07:44 +0000 Received: from mail180-tx2 (localhost.localdomain [127.0.0.1]) by mail180-tx2-R.bigfish.com (Postfix) with ESMTP id 62314118010C for ; Tue, 8 Mar 2011 16:07:44 +0000 (UTC) X-SpamScore: -33 X-BigFish: VPS-33(zzbb2cK1dbaL14ffOzz1202hz31iz8275bh8275dh1033ILz2dh54h49h2a8h668h) X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB007.red002.local; RD:none; EFVD:NLI Received: from mail180-tx2 (localhost.localdomain [127.0.0.1]) by mail180-tx2 (MessageSwitch) id 1299600463333708_28687; Tue, 8 Mar 2011 16:07:43 +0000 (UTC) Received: from TX2EHSMHS042.bigfish.com (unknown [10.9.14.251]) by mail180-tx2.bigfish.com (Postfix) with ESMTP id 435781260051 for ; Tue, 8 Mar 2011 16:07:43 +0000 (UTC) Received: from IE2RD2HUB007.red002.local (213.199.187.153) by TX2EHSMHS042.bigfish.com (10.9.99.142) with Microsoft SMTP Server (TLS) id 14.1.225.8; Tue, 8 Mar 2011 16:07:39 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB007.red002.local ([10.33.16.155]) with mapi; Tue, 8 Mar 2011 08:07:31 -0800 From: C Chauvenet To: M Pouillot , "'roll@ietf.org'" Date: Tue, 8 Mar 2011 08:07:53 -0800 Thread-Topic: [Spam] [Roll] DAO No-Path in a storing mode Thread-Index: AQGj2sDIsLPcNG0ZDgzNsUbYrsXTDJRznLeQ Message-ID: References: <4D2ABEAD.7@watteco.com> In-Reply-To: <4D2ABEAD.7@watteco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/related; boundary="_005_BDF612E3788C4C4791A1A49AC3CB7C970B4E3DB7D0IE2RD2XVS211r_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Subject: Re: [Roll] [Spam] DAO No-Path in a storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 16:06:36 -0000 --_005_BDF612E3788C4C4791A1A49AC3CB7C970B4E3DB7D0IE2RD2XVS211r_ Content-Type: multipart/alternative; boundary="_000_BDF612E3788C4C4791A1A49AC3CB7C970B4E3DB7D0IE2RD2XVS211r_" --_000_BDF612E3788C4C4791A1A49AC3CB7C970B4E3DB7D0IE2RD2XVS211r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, As mentionned in the mail below, the no-path DAO message usage in not very = clear in the RPL specification. Though it is important to clarify this because it is an important feature f= or reliable and reactive downward routing. Section 9.1.4 clearly states that DAO massages MUST be sent on a link local= address, thus limiting the no-path DAO destination set to one hop neighbor= ing. But given that this message should advertise that a downward path is n= o longer usable, how do you propagate this information in the upward direct= ion to erase that path ? For instance how do you prevent the DAGroot (located several hop away) to u= se a broken downward path if you can send the no-path DAO to you link local= scope only ? Some papers says that the no-path DAO must be sent to the root, but this se= ems contradictory with the 9.1.4 section I pointed out (DAO are link local = only in storing mode). I would appreciate that people shed some light on this .. Thanks C=E9dric. De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de Mat= hieu Pouillot Envoy=E9 : lundi 10 janvier 2011 09:09 =C0 : roll@ietf.org Objet : [Spam] [Roll] DAO No-Path in a storing mode Hello , In the specification, for storing mode, it is specified that a device shoul= d send a DAO no-path to a node which is removed from the DAO parent set (9.= 8.4). For me a node is removed from the DAO parent set if it is unreachable= on link-local and so I can't send a DAO no-path to this node. A solution t= o inform the old DAO parent should be to send the No-path on the global add= ress but it is not allowed by the specification (9.1.4-in storing mode DAO= message MUST be link-local-). So only the lifetime will remove the route f= rom the old DAO parent, that can take few minutes depends of the DAO lifeti= me setting. What do you think about that? best regards, Mathieu -- [cid:image001.jpg@01CBDDB3.337CEA20] Mathieu POUILLOT R&D Engineer m.pouillot@watteco.com Direct line : +33(0)4 98 01 60 05 Tel : +33(0)4 98 01 60 05 Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE - France www.watteco.com [cid:image002.gif@01CBDDB3.337CEA20]Before printing think about environment= and costs This Message may contain confidential information intended only for the use= of the addressee named above. If you are not the intended recipient of thi= s message you are hereby notified that any use, dissemination, distribution= or reproduction of this message is prohibited. If you received this messag= e by mistake, please notify the sender by reply email immediately. Please c= onduct your own virus checks before opening any attachment as Watteco does = not guarantee the integrity of this email or attached files has been mainta= ined nor this communication is free of viruses, interceptions or interferen= ce. Any views expressed in this message are those of the individual sender = and may not necessarily reflect the views of Watteco. Watteco shall not be = responsible nor liable for the improper and incomplete transmission of the = information contained in this communication nor for any delay in its receip= t or damage to your system. --_000_BDF612E3788C4C4791A1A49AC3CB7C970B4E3DB7D0IE2RD2XVS211r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Signature 3

Hi all,

 

As mentionned in the mail below,= the no-path DAO message usage in not very clear in the RPL specification.<= o:p>

Though it is important to = clarify this because it is an important feature for reliable and reactive d= ownward routing.

&nbs= p;

Section 9.1.4 clearly states= that DAO massages MUST be sent on a link local address, thus limiting the = no-path DAO destination set to one hop neighboring. But given that this mes= sage should advertise that a downward path is no longer usable, how do you = propagate this information in the upward direction to erase that path ?

 

<= p class=3DMsoNormal>For instance how do you prevent the DAGroot (loc= ated several hop away) to use a broken downward path if you can send the no= -path DAO to you link local scope only ?

 

Some= papers says that the no-path DAO must be sent to the root, but this seems = contradictory with the 9.1.4 section I pointed out (DAO are link local only= in storing mode).

&n= bsp;

I would appreciate that pe= ople shed some light on this ..

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'> 

Thanks <= /o:p>

 

C=E9dric.

 

 = ;

De :<= /span> roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de Mathieu Pouillot
Envoy=E9 : lundi 10 janv= ier 2011 09:09
=C0 : roll@ietf.org
Objet : [S= pam] [Roll] DAO No-Path in a storing mode

=

 

Hello ,

In the specification, for storing mode, i= t is specified that a device should send a DAO no-path to a node which is r= emoved from the DAO parent set (9.8.4). For me a node is removed from the D= AO parent set if it is unreachable on link-local and so I can't send a DAO = no-path to this node. A solution to inform the old DAO parent should be to = send the No-path on the global address but it is not allowed by the specifi= cation  (9.1.4-in storing mode DAO message MUST be link-local-). So on= ly the lifetime will remove the route from the old DAO parent, that can tak= e few minutes depends of the DAO lifetime setting.
What do you think abo= ut that?

best regards,

Mathieu

--

Mathieu POUILLOT
R&D Engineer

m.pouillot@watteco.com

Direct line : +33(0)4 98 01 60 05 <= /o:p>

Tel : +33(0)4 98 0= 1 60 05
Fax : +33(0)4 94 14 10 80

1766 Chemin de la Planquette
8= 3130 LA GARDE – France
www.wat= teco.com

Before print= ing think about en= vironment and costs

This Message may contain confidential informatio= n intended only for the use of the addressee named above. If you are not th= e intended recipient of this message you are hereby notified that any use, = dissemination, distribution or reproduction of this message is prohibited. = If you received this message by mistake, please notify the sender by reply = email immediately. Please conduct your own virus checks before opening any = attachment as Watteco does not guarantee the integrity of this email or att= ached files has been maintained nor this communication is free of viruses, = interceptions or interference. Any views expressed in this message are thos= e of the individual sender and may not necessarily reflect the views of Wat= teco. Watteco shall not be responsible nor liable for the improper and inco= mplete transmission of the information contained in this communication nor = for any delay in its receipt or damage to your system.

 

= --_000_BDF612E3788C4C4791A1A49AC3CB7C970B4E3DB7D0IE2RD2XVS211r_-- --_005_BDF612E3788C4C4791A1A49AC3CB7C970B4E3DB7D0IE2RD2XVS211r_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=7606; creation-date="Tue, 08 Mar 2011 08:07:30 GMT"; modification-date="Tue, 08 Mar 2011 08:07:30 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAWgAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAIRwAADmgAABSuAAAdtP/bAIQAAQEBAQEBAQEBAQIBAQECAgIBAQICAgICAgICAgMC AwMDAwIDAwQEBAQEAwUFBQUFBQcHBwcHCAgICAgICAgICAEBAQECAgIFAwMFBwUEBQcICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI/8IAEQgAoAD8AwERAAIR AQMRAf/EAO0AAQACAgMBAQAAAAAAAAAAAAACAwEEBQYHCAkBAQABBQEBAAAAAAAAAAAAAAABAgME BgcFCBAAAQQCAQQDAAICAwAAAAAAAAERAgMEBQYQQBIVMCETIAdQFnCAMREAAgEBBQMIBQoEBgMA AAAAAQIDBAARIRIFMVETQEHRIjKTFDQQYXFCBiCBkaGxUpIjMzVygkNTcPCi0nMkg5QVEgABAwMD AwUAAAAAAAAAAAABABEyEECRICECMVESUHCQYXETAQACAQIEBQQDAQEBAQAAAAEAESExYRBBUXEg MECBkaGx0fHwweFQYHCA/9oADAMBAAIRAxEAAAH9QuIVAAAAAAD27rrnvZjoQhum4bSdymNk2obC NiF5ZCwuhIyfMvz5IAAAAAGD6G7jHLek83Jm4bJsTOxEbBaWlpMkCwA+auAyAMHmGwVcZ6E+javT zuPAAE630f3iFbzU2zbNg2Zm6I2i4sLCRIyTAPnHg8gdazJ+Ue53tXb7lNin27ULPsvCqOQoADnv ae4dejjzoxtm0bJsFxeXFhaTBIkAfPPDpHG3XUOtT8kdByPSMKn6K8i1y+o07XMVoAPRN5j0LeHX TrxtmyXpvReXFpYWEwTMgHgPFZHEbe+jN7j4TzK/qbGp4HDjieOTbUAEqntnW45DNdKNc2i82Jm2 I2C0uJkyQJmQDwvjgdI2SeX2R9De3HmuO6xr87eiQAB2nY3pfQGmdOLjaLi8sLi4sLCRIEzIB4py WQOt7M7DsceM6TOpYctjLTZPTrS+89Z6XG7lusGiWmwWpuRcWFpMmWAEzIB49y0NWp1O5OjecRbd dtuxY7hbiMvc7bv+6x2bYGkdZLS0uLU2IuLSZYSJAmZAB5RzaR1mt5/QkadTJydtuQxW939+O47U gdaIFhYWlpMsLCwkWAEzIAPMufAAAAOw+47XshLgzVLCZMmXEyRMmSJgFgAB55o4AACdTsvvub9d g4k0yZMmSJFpYSJEiRkAsAAOjaeAAzLk/Qc97K+8icYa5IkSJEiRItJEiQMzMogZAAOoauGZbF9v Zjks9ddCk48iZJEjJIySMkiZMAmZAAANawnUtuMyArNUpMmTJIyZMmTJkySJAFgAAAAMESsqIAyD JIGTJkGTJkyACwAAAGsYMAGQDIMgGTJkGQADJkkAAACgAyAAZAMgAAEjIBkAAAAFYAABkAAGTIMg AAAAAAAAAAAAAAAAAAAAAAA//9oACAEBAAEFAvW689brz1uvPW689brz1uvPW689brz1uvPW689b rz1uvPW689brzWaLSzwPQaIv0+oS9NRqSOo1RHU6sTV6wTWa4TXa8TAwRMLDExMUTHxz8aT86zwi MnRhhhhhhhhhhhhumDHwwyxXuQQTonVPgYYYYX6S7mHH65JzbVvrtlr9tQwwwwxGCylFPGKqyf8A oiCCdEE+JhhjbbTD0uFscvN3sn+v0tlfxvim0zqMS9MvEYYYY1lP65xlS8aEQRCPRBhPiYYzMqjB xd5wrL2nHY32ZScg4vteLXf1Vp44+n3PIv8AYqoVwrgwwwxo6OmfL6RBBBhPkYYx8b2nI4W1XH9S 8d/Hacw43Dlei5n46zhcKoVQYYYYSKquLSmPQZE/0uYQTonyMMfryHV7D+v8NNPkNj4lfE+Uw5Ph 8ks9jvmGGGGNVjfpcXz/ADrYRBOiDCfGwwxTP1/K+cZflhb/AGuFqNhqeQ4CXw5bVZhw5frrEyOU 4mII0khXKyWPTHHqMmfnNhBE6IJ0T4mGLbqMeO09bsMPBitmdutTxje2Yen4dZfRgaKOLZo9Hjl+ i0ObbGCRTX4n5IX2fnFhuiDfMwxttRibnFq4Lp6sjE4PrMLG/wBC1sYLwPXSWHEKIrPi1U7cTiOu wjCxPJRVSKTks5MMMJ87DDDDDDDDGNhv1ts81YbsmGGGGGGEgsloxIw622eQw38U+ZhhhhhivElI hXCtBVYnNZDDDdmwx4uJRYpHFI1wh1lNEFVZDDdr+VZ4QT+KyRBZqo3d+SHmKqr1buPs++jdGG71 hhhvkbu2/wAn/9oACAECAAEFAvYXnsLz2F57C89heewvPYXnsLz2F57C89heewvPYXnsLzX3TWn9 JH6SP0kfpI/RTzU81PJTyU8lHHH7PDi1XbU6q+ZLQ5KFlMoL/GMXVEbtaMeVktfp66ek5pE2FULy UWX+Gvq8reyYYhWslwcZKCdjJTkeS3zeWZsI1jDDDDGnq7NhjU0/ZZY6RVi6fjFEGGGGGMerwh2T DGHmpVDAuWcCu2M02lrQYYYYY12O8uzYYY1cmllXeEMWcqy+SyXx+/AjFxCMHWmrwj2bDHiR8orf fOxUSSE65i1TPGRGuRGDGFjePasMJ9C+RJ1V1HUYSJ9mJi9swwwwwwwwxj4vbsMMMMMMJFynGbuG GGGGGIYyqQgidywwwlKkcYjBE7v80PBP+P8A/9oACAEDAAEFAnHHHHHHHHHHHHHHHHHH/wAo3fIn VV75FF75V/7uf//aAAgBAgIGPwKRypHKkcqRypHKkcqRypHKkcqRypHKkcqRypHKDn0AflvtxXRN yvPHin68qsdQtWC+09WEtR5WvlQUJ1tasnPWmy8e+p+1uQnThHkU2hk1u4W9GT6HN+5v3N/vfb+/ X//aAAgBAwIGPwL4gP/aAAgBAQEGPwLyEPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFvIQ90nRby EPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFqZpNHpXdhixp4idvst+ y0n/AK0P+20oGlUwAOA4EXRb9rp+5j6LftlP3MfRb9tp+5j6Lft0HdR9Fv2+Huk6LeRh7tOi3k4u 7Tot5SP8C28tH+BbfoJ+EW/SX6BbsD6Bbsi2zkFKu5F+z0SHex+3khYm5VxZuYCzJDVtqTpgwpIp Khb/AONBk/1W/MoK+FP7nhc4+iFnP1W8VptYlZADldkOKt91gcVPqPylUbWN302VRsWxO61/I3rq wnICFhgQZpJpW7MaDnY2z6ww8Pth0VDfTR/x/wB1vWcNwsFGCr2V3WSmpqaavq3VpBSU8TTScJO0 5C7FF/8Ak2qfi6nqzopMDjTIjEL65FGYNUrIL+HeOoMG578brUlWFyCqijlCbuIge76/kwDmQ5j/ AC+iT14fTyOesqTlhpxe9wvY8wAHOScALVms6gXT4looZKjQqGORuFSMFz8IhcJGkAySM1+3q3Wo E02nNdWaw0aaTRg3cR5Vzi88yqvWY8wFtLFdWx6jT6sGQVEcJhENUi8Th4s16st5U7cLVPxLOt1X 8SNnhY7UoIb1gX2ML5P5rT6P8PMW0+ozRap8Rj9IRnqulMf6jnZnHVXeThZI41yRxgLGm4AXAfJm qDz9VftPoRN+J5Hp1GwzUmjr4+sHMZsxiplPzh39qi0gjkWXhsUluIOVhtBu57a5WVKXj4WmqdI0 y/mZJyZHH/j4Sg+21TpHifBTOUekrguYwyI1+YD2Xj57Vun0KCPxMUOm6fFu8Uy0S3ewPfZIolyR xgLGgwAUYAfJAGJOwWji+6Ot7fQx5hgOR6rLo9FTVQ1hIAlbPMyeFeFWTrRqhMi43gAjHdtt8S6L xmqX40FfJVSfqTPWw5ZZG9bSwsbTS3LTxDNJUPcFG9mNnlkon0uuiytLp0hDNwZuvDKCNqyLj6je Oa2k6YvWg0YGurv+V1aCnX63b5h8rjN2Idn8XoJ5z2eS6VWHCDWIZaCc83FX/tQfZIPntS/D0Lf9 v4mkMDXbVo0Gepf8HV9rC2nzRVjaTq9I1NFSTiLiwyQ1sjRcORAy5ogY72xGW68Wigzz6nq/xCst a1Tw0jEzKTGii9rkvSI8JSeyu22nVyaNVtDqswgpPK352JAv/Owvym1UUglZqep8JHCpgaWWo4rQ 5VRZLxipxe4XY2qPE0VQn/z4km1i7hMKSOQsAXyvjgpbq34WvGI32VFF7NsssS8207z6Mo2JyTPP MsCY9Z2CjAZjt9Vp6WTUUp3Q5o6lZEEkE0Dq6ut/OjZbT6vq2qQahqnDWnWWMCKKGFXHVVC73ZnN 7G/E3bhaKXUalGkanqKWFlnC/l1ShWuu977p5rUtfR1SGqppKPwVVxBnTw9OqRRqW90o2I57zbSt Pi1JWj06oD0K8ZCxmjJa47+3avp5tceE8bxeQzQI9LO0xmDoQgbtP71+26zU9RrzzzVsccGpwiph BrUViyLKEUffu6t2ButcLcZx+Y3ZG4ejDtHZyUUdYCYQ6uQpuvy8x9RGBtQ1OeaR6BYVUM94k4Wb F8MS94Lb7haupIaio4eoRCKpJcFrgrC8G7A3tffvAtDHDWVEMcMvFCZ1IJzxuO0vNwh9douJWTyi IKuVjEQUVY0u7HOIVxtDm1KokWJYoyh4VzQQOkkcZuQdkoMdpsZxqVQknF8RERwepUFQjPjH7wGw 4WiWCSUJD2FLA/1IZd2+AWE0g6vuLv8AQSdgtmPzDlgklHV91N/puHZHK7lF53WzSdZuYcw9OUdn ld79QfXa5Rd6Lza73eUYW7N1us3zC3VW707zbHk/Zt2R8rdy3Z/g5//aAAgBAQMBPyHzhQoUKFCh QoUKFChQq6IF6Zarw+F9tAAPjhT8HhcxNpGBqhiBoUgNDgBoP8+kAYD+HSC0L+fSBaF/LpAtDgDo XsSjk88ABU6+2ve3gqBywwOAIcBDygodEUNA1VdCOiBAIcpge6jZHVjy/RZI8owXoj4gaCSHuqDp AA9ipd+gX4hlbVb4BxwHEOXE4GvjDm+iwTZlnTkFqgLFmYWUJk5a+eG6WqIxAoMAOQcoE/WY09Ng W6qBaqY28UxOQ0FSXUQzESC65Bt4QYg+w1/euFm5in0cBOAghwDlwNeIc/B2TsiIMrWZRsrAtVCB 9bKzrJXYDIoy9A0bD1tQ08p2lqbsmfSuLCZb1Jjz49KHXohd9sYfTBLpNo73JRgUoIaVw2AnZOyd k7JUA5H7f4cMf5qO2DgCGHAIEDSGsOJp4jGAvNLsBJGKMjWo1aheRmQyeOYM6gDZzinVehsLBd2d lLbgD0R0f5BCoDkAtANADHhAE7FdRYL9czqsv14cwvjSECCBwBCHKVDiaeI1QGk+FBF4mwoYzLSI QtRi1wwXRiOFsZYVdlZxasqquyLqUwOjAuVDT9QZczeqfK7meIGDPuFp8a8KX6Xcw6uAMQIIcA5c TiaeMXdzIUHsfY+4irwJr6IemznVeTZZngMiDa3yDGWES7rQza1J0QWHUZwLJtnlNdyrq7C9VFTK oTkog7TKZoXhtlQtmg0lhY0ZlM+cavDPnK9+cIExQIIIHAHl+sFGIHyM0Cu0oFS7jSSD1krQcMVX sx9jNkU8DAEsD6+lCzQd0tazCinGsWD37XZZQjrk7MdWncl0KNaLGBwAjWCmWeuSLkdhYW3LEgoK CchTk/lbw1VyfzhBAQwgIQOIeUWoq4cl4nOR5jNEWhe2HVGebpywmw/Avvol8CCyULTLUlDArkjn EW/lhu+4RnDVXLY+vNqJgWq6lryMi68wNxrwGwW0GKBqx5CZq/gb9tEJlubq7cHDrUjv8AQgg4FS oQh6MAactX9jhpljdot94QQECBAxAgcT0H89d9BKWrignzT14gQJUrgCVwCVXk9s7Z2ztnbC7QWu hKLsMd4M83gAsoJjWOjrxOyVKJUqEOFeCvJBaF+0++jiDrdDSDdz44H2I5a7E7OCpUqVKgVwIeCv I28NJ8RADQrwak56TFGHBUqVKlSuFSuJ56HOPRHMpUrgqVKZUqUcaZXnX1zulcFcSpXhqVK8dSvJ qVK8IVK8muCvR0ymUymUymVwUSj/AKP/2gAIAQIDAT8h/bvzP278z9u/M/bvzP278z9u/M/bvzP2 78z9u/M/bvzP278z9u/M/bvzP278xZRa6zeZvM3mbjN1m/N2b03uBeXlpcvjUqVKlSpUqVKlSpUq UfZ6KpUqVKhdpW+PvALo+5KiUypUqVKmE6ytXoqlSoHC1gNu5+OGrQKrTnzlgdJUqVKnYWfj0oA1 GZg7n+coEzUPAiHJ9nf8eIH2T0oC1yxwqnQiqybKkx+EBrRK7p9KJEK3c6vTwuDvlKAa/YeIGb6f d6cbo5l3zcu8e1DNnb++k5fOO3657xIrGO/4iiu1+0DQ66byjHqasMj6YEys1SAqUGhCMdb+IM6M /WWHqILT7d4AutNMadpQqVOc+nG6IkJ1lIvLh/z/AJ3ioNV7e013/Of5lnS9eALej64A6og56vXA 9IQXHqwvG8oHOaB6vbgHKV/8+//aAAgBAwMBPyG0tLS0tLS0tLS0tLS0tLS0tLS0tly5cuXL/wCZ TL+trirXrYYsvjt9eD/3z/8ATn//2gAMAwEAAhEDEQAAECSSSSSSZWyQojzwhEkkkkklqFAIABII AP8A9xL/AP8AVMBxAIIAANtPvnttAlI2AIAAAG7GFu23xgAgIBAAANkOCNthBhIYIJAAAG5lU222 BoG4BBAAAAAqTyQAMAMJAAAIAPztE74QtIMBAABAAJI3RDSIpI3JJABAALbbbadEAAwIIAAAACSS S+JpIOABJAIAAP8A/kgRASBgAQCiAABt8AAAQSOCSATgAACZAATSSAiSQAQAAAACBAQSCkACQAQA AAAASAQQCQCAAcgAAACSAAQSAAAQCQAAAAAASSAASAQAAAAAAAAAAAAAAAAAAAAAAAD/2gAIAQED AT8Q87Dhw4cOHDhw4cOHDhU3lwqwprjq8GRxgjgNUAhD1QZkAUG/sQEwEwRS7dafihHzm4wWlHLR 7YX2i6wWlFIT2QZO+CGPodH9oaPZi/qfQgL+oaYOwSiqrHSWlpaWlpaWlpaWlpaWjUXpHWKTG4v7 8A5Gu/dDpuwlYwOn8uHjeGw2/M16YESiic00E0+/A1O/gttLbS20ttKw9lEbpgBlVoiz8lyUpJTm aOc+ytXYCGzdorNSFEoNRtK9JbaW2ltpbaW2gJWL7gfvDioP2IfaHgCjsLmbkUndzNKnSPTnRMaJ y9py9pzT+qGpw0+/DS8FZWVgpqsKFTRDRQAyMNRr6NEdK7oESp0IBBVAMA5BHCaYlIDJU5SYE+Rp G2mGQA2AiRc9NgIqF6V86lZWVlZYVmWFgUb+DhnOu7Vf1YOKxAb0QYTcgyQEtIxpmc0/qhqd5ocd K3t4qRLV1VHMdhBjLC4L616GyQAQkB0BJbK0Lj0VNQTH2HSl0fThMuIjYN2DZXAJql6KLNc9S1dX lL0gyREUaLEcgA2PDVYsbbFRPlHtwyNltsPuL8Q3AxsPXNwlBNZoVyhaCu852XUPIicmCZCa+Ol4 uyNYRaxRMFDkuDkdg2ASpDhIJZmLVfBJR568iAJpQkQ7lEC84LJEDnsOq1C86K8oQn3oc3AMAKDB 4fUCMLKigO6ykNJTu/3TwIHIu5aNndtj4QvaYgTkBcpbNIxeJq9pdsHKHFw6PmAMhNLx0vBfaX2l E10hzq5lXjAKKUuAySUHAlQASzfMreBQoWWatZW0Q+opgUGiLzAQosAscLqVZURfaX2l9pfaX2ip ZpbmCfY+VcL6UH0q/bWaVO6xCkyay8dTnFKxLguYLMXOaZU7Q1O/DTx0vB2v1na/Wdr9YVh44Y2X GeoDGWpR5Ukddho3vFE5xc2mBgslKPJaQNmXtTPOYy3VIwjoH8+wVE4vgNmqVKDMXo+5WAsZbT3T F1cAyRYKI5bZaHIiajHJm7167GrtMAoXTTlJ3fpwbMrx0ed7aQnCSnFY6zAr4iYsiaddJ1OU0XQ6 QasSxrHhNDwdk7JiOGadCgrNWArgmOGNblCMLWQtKj4kZYqNvanpb+EkLDXsWLOtJZ2atGzEYDxZ DGO7VZIZlVshdI6W6WNa+XiVO3HUl/8AKNP7gKVGEnKKICg7BoTQRSNlc/k6GOvCxKL+qdfZLc83 Xmyzv0l+E95QprLPfSVOSq0hujTEJtYBoc4Gge0QRTiaHj7DWBCwrJzXUWXcGBKDoa3IyLajFLGr PJ6NhiKhsQhym8VuPSiEuNQtTCBXKtaECok5YRxSCxVAK4GQhBNwH+0vVkx0Gsc8SnFi4LnUeYxr n4FoZC6ORz4VtBamBccWaGh+YB2lFdOcCh0uDPeFIHF6w4uafeafeGp38BoeG8vLy8vLy8vLxnSF J16EuhtzgAAFBoRQKUGVdAly0XDr6v6mCtJg6R6x8yjv1iaxEUSgrmxLtKrgFFfMFp4Dw9s7Z2zt nbO2dsYpoRb/AIbxwwadVPfV34KAq0GVeUUbQfy7QyhV0reZcazLnO0L8oHnDZX80lG6wS6VvKOk BLYDRz4haHi/hmfwzP4Zn8Mz+GYpP0QKvsS1FnevbQ9/iUpB3+4uXgn5gMufuzu/EO5howENEX5u JtQ9sCbw5sMTneFd+NbQHSUdPF3zvj1K+gn7SjqjZ/19IeldQUfL+IDTHOtruueNuOx5d2Zkq0ND twjAzW0DjEvzZWHQQbridwwF0IUu5r4mpAHkBf7P3Zp2kBQDoFeDnp0MsBRV6avvDLSt2X6yu8C6 Fwfad8Cbyqg0uBrOWAGkp6Qoq44mp38tQytE6lehn7TrTu/5MM0Ohj7QfSped0DzzAGhNiXnfNqa YJrgm1K9YFFeA1O/k7z5jfVPvFupcttLzczulesCbyjpxp6S8OtgTeUGh4aYNgxHyby8vO6d07p3 SvWBN5R0lHTxVekt0ndAmuZR0lHTzqekp6Mp6M2JsTam1Nqe1L9Z3TamxKrT/of/2gAIAQIDAT8Q 879+/fv379+/fv379+drLKpXLqrc/fMf9Zn7Jn7ph/rMeq+Wbz5Zvvlm6+ZvPzN9+Zus3JeWl+f/ AP2Ns/sXweJH0Px1o50H2T2YgzHzT5JT4voR1QfLUIToAfHB4kfMvLy8+0AXVegc2DROcjTs5G+s qGC6uCLBoGA7PTZwxdRsnw1Ly8vLxj8lb6vvXAjxPPAKtqDeHmV1ubHT7tWXZpy3iMweVS2eRgiF nSNN245autEtz18IVi88Pu/1wPAeebY13dX4x78H7qd/1BeoQnOc/Bj6yjd4QMBa4IA2oz3cv14c vBfn908hVU2GFvFV0cRgli7oXkDYGjtAuKKgVdxp/wA6mZzwOfkflo+fF/F3S35PjX44EeJ6H2Bo QdzD9H6SptWO5g+NfaYBoWHWg+2XdkjpAIpnCjTFokt1R7XG3Z+xHLIXkpooNrVOpgtvEp6ck1Fi tMY1DNZxKtkP5UonKo1erzeB4D0G5guIC0kxh1w7JcXOXi3PNvnjToe8ogcDRz0e3U5xCrEWKw2V XcTDyojna1OOT9tJRgOORQBVOa0OVZLlGEEqtlotna83SXAraTC2LGx+XgEfSaV4tV/NzU3lpKLe 11p0qsdLesakW7Ppvpiuyy1VRUrn0Trzv7QEaovvra3ru2i7wF289URdeY6aHIgrASurNrDXl116 stXP8of2+kvh4aHXd26dfIv0/wDr4Ww699toFcDHqwFMbZXZ+jkfl416r41o1mWwfX/JTjX34nif RS6C50d3nMfiH415T5N+RtpoQ+IA08V+sr/o1/6v/9oACAEDAwE/ENybk3JuTcm5Nybk3JuTcm5N ybkepNybk3JuQ60XLy0tLS0tly/BiYmJiYmJiYmJiYmJiYj4SPmXLly+A0YOJcuXLly/ER88SwTg OqAvifEEfPrYYXLVcMDxPiPPeFwEobh5t+geCQ8T4j0LpwVKlSvKI+iuXwvySaeguXLly5cuXHx1 L9dXqL/5D5FenfJv/wA7UT0l+Xf/AIv/2Q== --_005_BDF612E3788C4C4791A1A49AC3CB7C970B4E3DB7D0IE2RD2XVS211r_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=490; creation-date="Tue, 08 Mar 2011 08:07:30 GMT"; modification-date="Tue, 08 Mar 2011 08:07:30 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAXANUiADamKSuhHonKgla0TG29ZEmuPiGbEyliIC+HJBp9DZ+inEGqNYLGel22Ury/ uWW5W3+DfODW4NDK0sS7xU2wQmSPXaTVnZDNiN3v2pzSlpTPjbfespjQkXnCcMLjvlKxRsnmxbLc rAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAACIALAAAAAAYABcAAAb/QM9g SCwajwNMwxBoOgOA6BPwDBgYBGh0a0gkDNvwNiDIig+QyQRy0IqpZTfgIBHZRZLDWxrnKu53Dl9v ZGYBXg6AdhgKCghyhVAHEw51incHFFR8WQZ/l4AQBgMMD1AGcQGfoCIRCVQBBA1NqRWsdwpgAFdw ZgiJtxF6VA8UqGYACROKDhF2wlIEBccBCwmrdhKrEK9UDLS+l6vCCwIMs3CmAAi2dwwHFhJs1RYF GwK7fbvsFQgJbf52NbiQAUDBSFEWwEJwAEFCAxc0yBIwC6EYhggURqHA4UEfi2EONAwToIOFD1pA hnkkxskYAQ/AQJk5ZpNNLVdCFNjJs+dOBwo+eS4AEQQAOw== --_005_BDF612E3788C4C4791A1A49AC3CB7C970B4E3DB7D0IE2RD2XVS211r_-- From pal@cs.stanford.edu Thu Mar 10 08:33:57 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D99CD3A6915 for ; Thu, 10 Mar 2011 08:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkDPnXeOt4x3 for ; Thu, 10 Mar 2011 08:33:57 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 0EADE3A6A3A for ; Thu, 10 Mar 2011 08:33:57 -0800 (PST) Received: from [108.112.76.252] (helo=108-112-76-252.pools.spcsdns.net) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PxipW-0001Lg-5P; Thu, 10 Mar 2011 08:35:15 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D040FFC6E@XMB-AMS-107.cisco.com> Date: Thu, 10 Mar 2011 08:34:19 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <652D128E-0FDE-41FD-A7A3-634936C4E25B@cs.stanford.edu> References: <20110301003318.9EA863A6CBA@core3.amsl.com> <4D6D311C.8020001@ieee.org> <4D6EAE68.4050104@ieee.org> <7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu> <8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0405FD39@XMB-AMS-107.cisco.com> <0A9CCA13-35C3-4F14-96D6-B522E3DD858A@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0406047F@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D040FFC6E@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 67f4a389e065da33eb5969ecb4726704 Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 16:33:58 -0000 On Mar 8, 2011, at 5:25 AM, Pascal Thubert (pthubert) wrote: > Hi Om and Phil: >=20 > Several things: >=20 > In one hand I agree with Om that we must leave liberty to the OF to be = what they need to be. Earlier versions tried to implement what you're = asking now, that is specify an abstract interface to the OF and be done. = For some reasons, that text faced opposition and it was removed. My = suggestion here would be to start a separate draft to propose some APIs.=20= >=20 > OTOH, though the main spec does not wish to be on the way of the OF, = it tries to make some design recommendations. And the most critical one = is probably to avoid the so-called "greediness" issue. To do this, the = draft recommends to compute a reference path through a preferred = parent, and define the rank and the advertised metrics based on that = path. This is no absolute (uppercase) must and we can make that more = clear without requiring a new last call, and I'm open to such editorial = change. >=20 > But I fail to see any "contradiction" in the current text.=20 >=20 > In my view, this text : > " > o When the scan is complete, the preferred parent is elected and the > node's rank is computed as the preferred parent rank plus the = step > in rank with that parent. > " The issue is when minHopRankIncrease is 1, e.g., in your last resort OF. Phil= From jpv@cisco.com Thu Mar 10 09:07:30 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 226F03A6920 for ; Thu, 10 Mar 2011 09:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhWaIRCDrQsv for ; Thu, 10 Mar 2011 09:07:28 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id EEC283A68AF for ; Thu, 10 Mar 2011 09:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=2811; q=dns/txt; s=iport; t=1299776926; x=1300986526; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=QPlm330XA1YGEAm4sOgt3fHsF2BTtqXk+HO+33uLqv8=; b=a9/8RK2Jyf3rADZcJW9kO+6mXxNHQ2ocluMbrVgx0lnPExkOy0r9/LID 2+/pTvK9LpDWmDZxauWoGO0JRLnx98iaDUYFf2x4aoeZWWLitzqE78uxh KqLZoCgWw3dfN4O0ZGf4leGJQ+Hq/DSQiKR6EwMPnkvsiPlzmplYZCSw/ A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqgEAIWUeE2Q/khNgWdsb2JhbACmKRQBAQsLJiWkQJxChWIEjEODSgY X-IronPort-AV: E=Sophos;i="4.62,297,1297036800"; d="scan'208,217";a="78635876" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 10 Mar 2011 17:08:45 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2AH8iII015080 for ; Thu, 10 Mar 2011 17:08:45 GMT Received: from xfe-bgl-411.cisco.com ([72.163.129.199]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 22:38:44 +0530 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 22:38:43 +0530 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-104--652824761 From: JP Vasseur In-Reply-To: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> Date: Thu, 10 Mar 2011 18:08:42 +0100 Message-Id: <9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 10 Mar 2011 17:08:43.0952 (UTC) FILETIME=[CFA36300:01CBDF45] Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 17:07:30 -0000 --Apple-Mail-104--652824761 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear all, This terminates the WG LC. Pascal, I think that you answered one of the = comments and asked for clarification on the second one. Could you get in touch = with Phil who commented, make sure that you addressed his point (I think that there = still one unresolved issue) and post the new revision ? Thanks. JP. On Feb 22, 2011, at 9:03 AM, JP Vasseur wrote: > Dear all, >=20 > This document has been stable for quite some time and the latest = revision has addressed all comments received so far. This starts a = 2-week Working Group Last call on draft-ietf-roll-of0-05, that will end = on March 8 at noon ET. >=20 > Please send your comments to the authors and copy the mailing list. >=20 > Thanks. >=20 > JP. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-104--652824761 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = all,

This terminates the WG LC. Pascal, I think that = you answered one of the comments
and asked for clarification = on the second one. Could you get in touch with Phil = who
commented, make sure that you addressed his point (I think = that there still one
unresolved issue) and post the new = revision = ?

Thanks.

JP.
=
On Feb 22, 2011, at 9:03 AM, JP Vasseur wrote:

Dear = all,

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

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

Thanks.

JP.
<= div>
______________________________________= _________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/ma= ilman/listinfo/roll

= --Apple-Mail-104--652824761-- From pthubert@cisco.com Thu Mar 10 09:08:00 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B1BA3A6920 for ; Thu, 10 Mar 2011 09:08:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.422 X-Spam-Level: X-Spam-Status: No, score=-10.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 987Rg+ZgMDC1 for ; Thu, 10 Mar 2011 09:07:59 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id B83053A68AF for ; Thu, 10 Mar 2011 09:07:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=2150; q=dns/txt; s=iport; t=1299776957; x=1300986557; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=xra2eb4V8wh3I4shp7kxg+oMi3cb4fb4LHbJ3qHooVY=; b=Aej9Uo0NATAUvay1qFM/o/vb8EA1pXH1ocBd4lo0rgBLLtS7MlY/wV+t T2rRo/5SwQtyKPl/yO0WF3vglI42fK/kVoHYLpnZhA0HI2tZrmuiWW2W/ bh/25arv+zFlMuPybPk1jOPbMzNAHOONjf1CqGc57rHkb6RY2KsGLAVRA 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvYAAIWUeE2Q/khNgWdsb2JhbACYWI1RFAEBCwsmJaRAnEKFYgSQE4hc X-IronPort-AV: E=Sophos;i="4.62,297,1297036800"; d="scan'208";a="78635969" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 10 Mar 2011 17:09:16 +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 p2AH9Gw3015208; Thu, 10 Mar 2011 17:09:16 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 18:09:16 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Mar 2011 18:09:10 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0410065E@XMB-AMS-107.cisco.com> In-Reply-To: <652D128E-0FDE-41FD-A7A3-634936C4E25B@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 Thread-Index: AcvfQTC1Vf3Veaq/QaiO+dAVJsJG8gABEXkw References: <20110301003318.9EA863A6CBA@core3.amsl.com> <4D6D311C.8020001@ieee.org> <4D6EAE68.4050104@ieee.org> <7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu> <8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0405FD39@XMB-AMS-107.cisco.com> <0A9CCA13-35C3-4F14-96D6-B522E3DD858A@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0406047F@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D040FFC6E@XMB-AMS-107.cisco.com> <652D128E-0FDE-41FD-A7A3-634936C4E25B@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 10 Mar 2011 17:09:16.0085 (UTC) FILETIME=[E2CA7E50:01CBDF45] Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 17:08:00 -0000 Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Thursday, March 10, 2011 5:34 PM > To: Pascal Thubert (pthubert) > Cc: Omprakash Gnawali; roll@ietf.org; phoebus@ieee.org > Subject: Re: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank- > hysteresis-of-01 >=20 > On Mar 8, 2011, at 5:25 AM, Pascal Thubert (pthubert) wrote: >=20 > > Hi Om and Phil: > > > > Several things: > > > > In one hand I agree with Om that we must leave liberty to the OF to be > what they need to be. Earlier versions tried to implement what you're asking > now, that is specify an abstract interface to the OF and be done. For some > reasons, that text faced opposition and it was removed. My suggestion here > would be to start a separate draft to propose some APIs. > > > > OTOH, though the main spec does not wish to be on the way of the OF, it > tries to make some design recommendations. And the most critical one is > probably to avoid the so-called "greediness" issue. To do this, the draft > recommends to compute a reference path through a preferred parent, and > define the rank and the advertised metrics based on that path. This is no > absolute (uppercase) must and we can make that more clear without > requiring a new last call, and I'm open to such editorial change. > > > > But I fail to see any "contradiction" in the current text. > > > > In my view, this text : > > " > > o When the scan is complete, the preferred parent is elected and the > > node's rank is computed as the preferred parent rank plus the step > > in rank with that parent. > > " >=20 > The issue is when minHopRankIncrease is 1, e.g., in your last resort OF. >=20 [Pascal]=20 Hum: minHopRankIncrease is a min. In the case of OF0, the default increase is 4 times that min. Which leaves room. Also, some alternate parents like P1 in my example might have a lower Rank than the preferred parent. All in all, a node can have multiple parents, at a lower, same or higher parent than the preferred. Pascal From pal@cs.stanford.edu Thu Mar 10 10:08:18 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A54213A6930 for ; Thu, 10 Mar 2011 10:08:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-H82BfoJfG1 for ; Thu, 10 Mar 2011 10:08:17 -0800 (PST) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id BD27C3A6A50 for ; Thu, 10 Mar 2011 10:08:17 -0800 (PST) Received: from [50.12.161.7] (helo=50-12-161-7.sfo.clearwire-wmx.net) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PxkIp-00008T-F5; Thu, 10 Mar 2011 10:09:36 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0410065E@XMB-AMS-107.cisco.com> Date: Thu, 10 Mar 2011 10:09:33 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110301003318.9EA863A6CBA@core3.amsl.com> <4D6D311C.8020001@ieee.org> <4D6EAE68.4050104@ieee.org> <7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu> <8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0405FD39@XMB-AMS-107.cisco.com> <0A9CCA13-35C3-4F14-96D6-B522E3DD858A@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0406047F@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D040FFC6E@XMB-AMS-107.cisco.com> <652D128E-0FDE-41FD-A7A3-634936C4E25B@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D04100 65E@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: e1c7b331cb521454e7d22df558880a52 Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 18:08:18 -0000 On Mar 10, 2011, at 9:09 AM, Pascal Thubert (pthubert) wrote: >>=20 >> The issue is when minHopRankIncrease is 1, e.g., in your last resort > OF. >>=20 > [Pascal]=20 > Hum: minHopRankIncrease is a min. In the case of OF0, the default > increase is 4 times that min. Which leaves room. > Also, some alternate parents like P1 in my example might have a lower > Rank than the preferred parent. > All in all, a node can have multiple parents, at a lower, same or = higher > parent than the preferred. Please combine these different specifications together: 8.2.2.4. Rank and Movement within a DODAG Version 1. A node MUST NOT advertise a Rank less than or equal to any member of its parent set within the DODAG Version. and o When the scan is complete, the preferred parent is elected and the node's rank is computed as the preferred parent rank plus the step in rank with that parent. The failure case is simple. Consider an OF which has a node maintain = three elements in its parent set. The Cisco/ARC implementation does = this. The MinHopRankIncrease is 10. There are three elements of the = parent set, which advertise Ranks of A=3D20, B=3D30, and C=3D35. If the = node computes its Rank with respect to each element of the parent set, = it obtains a=3D30, b=3D40, and c=3D45 (upper case is the parent's Rank, = lower case is the Rank computed from that route).=20 There are two options: Option 1: The node chooses A as the preferred parent. It advertises a = Rank of a=3D30. Following 8.2.2.4, it cannot include B or C in its = parent set. If the MaxRankIncrease is less than 10, the node cannot fall = back to B or C in this DODAG Iteration. Option 2: The node chooses B or C as the preferred parent. It advertises = a Rank of b=3D40 or c=3D45. Please note that 8.2.1 says "Finally, the = preferred parent is a member of the parent set that is the preferred = next hop in upward routes." This means that if the node wishes to have = routing flexibility in the face of link failure, it must use suboptimal = routes. It cannot select B as its preferred parent then route mostly = through A. The basic issue is that the flexibility afforded in parent selection is = constrained to approximately MinHopRankIncrease, or, if the OF is very = pessimistic, closer to its per-hop Rank increase. If you remove the requirement from 14.1, then the node could have A as = its preferred parent and advertise a Rank of 36 (max(parent set) + 1). = This Rank is higher than that computed for its preferred parent, but the = understanding is that it may need to very quickly fall over to another = element of its parent set: 30 is not a guarantee under any stretch of = the imagination. This is, as far as I understand it, much closer to what = existing implementations do. I know you're always concerned with this idea of "greedy" nodes gobbling = up a big parent set and advertising a high Rank, but I don't think that = can really happen given the current DIO processing rules. Once a node = sends a DIO, it constrains how much deeper (how "greedy") it can move in = the DODAG. Phil From jpv@cisco.com Fri Mar 11 02:51:54 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58C5E3A689A for ; Fri, 11 Mar 2011 02:51:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PB1ClZOhLoF2 for ; Fri, 11 Mar 2011 02:51:52 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 293783A68AA for ; Fri, 11 Mar 2011 02:51:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=86; q=dns/txt; s=iport; t=1299840791; x=1301050391; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=mg5xiW/GRLPG4XUXicbilT98CDYLKmsDw1ClJZRnXd8=; b=CPSRYlnYLDjYdteNLsrCs3XxgcpIkw13Kh9pf5QBC6MXSrSoZi8oGgF8 HQZ+jKbIl0bcqmdVWbyBo35NPJ96yYTqCULV3tnugyPH3ybuALg/DD7cI ZHeA/AqX827EXkJeg9oR+1zMOfFsEJCTimnMntk0VZCvyA5qLD/sNFV3e E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ6NeU2tJV2Y/2dsb2JhbACmLneIQQGcK5wqhWIEjE+DSgY X-IronPort-AV: E=Sophos;i="4.62,302,1297036800"; d="scan'208";a="666504749" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by sj-iport-6.cisco.com with ESMTP; 11 Mar 2011 10:53:11 +0000 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2BArAIU027456 for ; Fri, 11 Mar 2011 10:53:10 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Mar 2011 02:53:10 -0800 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Mar 2011 02:53:09 -0800 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 11 Mar 2011 11:53:06 +0100 Message-Id: <26CF8545-555D-4759-BC91-1270F9465E75@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 11 Mar 2011 10:53:09.0757 (UTC) FILETIME=[829FDAD0:01CBDFDA] Subject: [Roll] When you contact a WG chair ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 10:51:54 -0000 Please send your email to both co-chairs and please copy Dan King. Thanks. JP. From jpv@cisco.com Fri Mar 11 05:27:28 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D911F3A6BFD for ; Fri, 11 Mar 2011 05:27:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.444 X-Spam-Level: X-Spam-Status: No, score=-110.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id atE+FaSGraLS for ; Fri, 11 Mar 2011 05:27:27 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 9A71C3A69AE for ; Fri, 11 Mar 2011 05:27:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=367; q=dns/txt; s=iport; t=1299850127; x=1301059727; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=LxK4Xqppd+txoGQDZ1AQ9MtXPSFaI2MmvPg5t7vyLlk=; b=mqAd96Wa75HqW3k8dLAyvLCmD4gbWqffGAG+5M+EYnrGocVKToDDpH+J /XRNmsSfasnY3T9HTnFuaDn4jHZhzTr18WWxTMd/Rma9E83p7McHUHqWc K3xVyK4h6RnaojgoMMdmhkIXDfMQLqibQ7kNZM5620MBkv0dkHyxhgJLB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIDALexeU2Q/khLgWdsb2JhbACmLxQBARYmJaUanDKFYgSMT4NKBg X-IronPort-AV: E=Sophos;i="4.62,303,1297036800"; d="scan'208";a="21342242" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 11 Mar 2011 13:28:45 +0000 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2BDSFPr002148 for ; Fri, 11 Mar 2011 13:28:45 GMT Received: from xfe-bgl-411.cisco.com ([72.163.129.199]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Mar 2011 18:58:39 +0530 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Mar 2011 18:58:39 +0530 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: JP Vasseur In-Reply-To: <26CF8545-555D-4759-BC91-1270F9465E75@cisco.com> Date: Fri, 11 Mar 2011 14:28:38 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <26CF8545-555D-4759-BC91-1270F9465E75@cisco.com> To: ROLL WG X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 11 Mar 2011 13:28:39.0870 (UTC) FILETIME=[3BCE1DE0:01CBDFF0] Subject: Re: [Roll] When you contact a WG chair ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 13:27:29 -0000 Please ignore, this email was for ANOTHER WG. Sorry about that. Thanks. JP. On Mar 11, 2011, at 11:53 AM, JP Vasseur wrote: > Please send your email to both co-chairs and please copy Dan King. > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Fri Mar 11 06:00:36 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1153A6BE6 for ; Fri, 11 Mar 2011 06:00:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.482 X-Spam-Level: X-Spam-Status: No, score=-110.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1G-V8bbr4tYV for ; Fri, 11 Mar 2011 06:00:35 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9A3683A6BA0 for ; Fri, 11 Mar 2011 06:00:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=104; q=dns/txt; s=iport; t=1299852114; x=1301061714; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=PdrajYC2Q/A9OqDqzYLk9gBdxWFaFojRg2xar2Nh/FQ=; b=nFV0NcnOtm2qmrHa/V+q5mmhHfxIkBG+sbbbu+96VTWPvy/kXruaj3s9 Xzbm+EhsFjWYUx2t1aeJZWNzp3MMyF8S6Oh2/PtPEYCZyh0ixQFn+V7su A2LyhWROztsjYa5BZ8aOfyb5oamC4suFBV2Aw+jmOUXiDrgYrRKjGlGXq 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIDAJ+6eU2Q/khMgWdsb2JhbACmMBQBARYmJYhBAZ0EnDWFYgSMT4NKBg X-IronPort-AV: E=Sophos;i="4.62,303,1297036800"; d="scan'208";a="78779537" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 11 Mar 2011 14:01:43 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2BE1gBx020061 for ; Fri, 11 Mar 2011 14:01:43 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Mar 2011 22:01:41 +0800 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Mar 2011 22:01:41 +0800 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Mar 2011 15:01:39 +0100 Message-Id: <680885E2-D67E-424E-9EE0-D287C407A5B2@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 11 Mar 2011 14:01:41.0684 (UTC) FILETIME=[D90EEF40:01CBDFF4] Subject: [Roll] Final Agenda - IETF-80 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 14:00:36 -0000 Please find the final agenda: = http://www.ietf.org/proceedings/80/agenda/roll.txt Thanks. JP.= From c.chauvenet@watteco.com Fri Mar 11 08:07:47 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CE2D3A69E6 for ; Fri, 11 Mar 2011 08:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.435 X-Spam-Level: X-Spam-Status: No, score=-3.435 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqB0rJlNO6Z2 for ; Fri, 11 Mar 2011 08:07:40 -0800 (PST) Received: from TX2EHSOBE007.bigfish.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by core3.amsl.com (Postfix) with ESMTP id 6CC6D3A6A3F for ; Fri, 11 Mar 2011 08:07:30 -0800 (PST) Received: from mail197-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.8; Fri, 11 Mar 2011 16:08:49 +0000 Received: from mail197-tx2 (localhost.localdomain [127.0.0.1]) by mail197-tx2-R.bigfish.com (Postfix) with ESMTP id 9E97434864C for ; Fri, 11 Mar 2011 16:08:49 +0000 (UTC) X-SpamScore: -34 X-BigFish: VPS-34(zzbb2cK1dbaL14ffOzz1202hzz8275bh8275dh1033ILz2dh54h49h2a8h668h) X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB024.red002.local; RD:none; EFVD:NLI Received: from mail197-tx2 (localhost.localdomain [127.0.0.1]) by mail197-tx2 (MessageSwitch) id 1299859728438541_29564; Fri, 11 Mar 2011 16:08:48 +0000 (UTC) Received: from TX2EHSMHS026.bigfish.com (unknown [10.9.14.244]) by mail197-tx2.bigfish.com (Postfix) with ESMTP id 68E6812F8052 for ; Fri, 11 Mar 2011 16:08:48 +0000 (UTC) Received: from IE2RD2HUB024.red002.local (213.199.187.153) by TX2EHSMHS026.bigfish.com (10.9.99.126) with Microsoft SMTP Server (TLS) id 14.1.225.8; Fri, 11 Mar 2011 16:08:46 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB024.red002.local ([10.43.198.102]) with mapi; Fri, 11 Mar 2011 08:08:19 -0800 From: C Chauvenet To: M Pouillot Date: Fri, 11 Mar 2011 08:08:09 -0800 Thread-Topic: [Roll] [Spam] DAO No-Path in a storing mode Thread-Index: AQGj2sDIsLPcNG0ZDgzNsUbYrsXTDJRznLeQgAS6bLA= Message-ID: References: <4D2ABEAD.7@watteco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/related; boundary="_005_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A6878IE2RD2XVS211r_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: "'roll@ietf.org'" Subject: Re: [Roll] [Spam] DAO No-Path in a storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 16:07:47 -0000 --_005_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A6878IE2RD2XVS211r_ Content-Type: multipart/alternative; boundary="_000_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A6878IE2RD2XVS211r_" --_000_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A6878IE2RD2XVS211r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Any Guidelines on this ? C=E9dric. De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de C C= hauvenet Envoy=E9 : mardi 8 mars 2011 17:08 =C0 : M Pouillot; 'roll@ietf.org' Objet : Re: [Roll] [Spam] DAO No-Path in a storing mode Hi all, As mentionned in the mail below, the no-path DAO message usage in not very = clear in the RPL specification. Though it is important to clarify this because it is an important feature f= or reliable and reactive downward routing. Section 9.1.4 clearly states that DAO massages MUST be sent on a link local= address, thus limiting the no-path DAO destination set to one hop neighbor= ing. But given that this message should advertise that a downward path is n= o longer usable, how do you propagate this information in the upward direct= ion to erase that path ? For instance how do you prevent the DAGroot (located several hop away) to u= se a broken downward path if you can send the no-path DAO to you link local= scope only ? Some papers says that the no-path DAO must be sent to the root, but this se= ems contradictory with the 9.1.4 section I pointed out (DAO are link local = only in storing mode). I would appreciate that people shed some light on this .. Thanks C=E9dric. De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de Mat= hieu Pouillot Envoy=E9 : lundi 10 janvier 2011 09:09 =C0 : roll@ietf.org Objet : [Spam] [Roll] DAO No-Path in a storing mode Hello , In the specification, for storing mode, it is specified that a device shoul= d send a DAO no-path to a node which is removed from the DAO parent set (9.= 8.4). For me a node is removed from the DAO parent set if it is unreachable= on link-local and so I can't send a DAO no-path to this node. A solution t= o inform the old DAO parent should be to send the No-path on the global add= ress but it is not allowed by the specification (9.1.4-in storing mode DAO= message MUST be link-local-). So only the lifetime will remove the route f= rom the old DAO parent, that can take few minutes depends of the DAO lifeti= me setting. What do you think about that? best regards, Mathieu -- [cid:image001.jpg@01CBE00E.E4233E30] Mathieu POUILLOT R&D Engineer m.pouillot@watteco.com Direct line : +33(0)4 98 01 60 05 Tel : +33(0)4 98 01 60 05 Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE - France www.watteco.com [cid:image002.gif@01CBE00E.E4233E30]Before printing think about environment= and costs This Message may contain confidential information intended only for the use= of the addressee named above. If you are not the intended recipient of thi= s message you are hereby notified that any use, dissemination, distribution= or reproduction of this message is prohibited. If you received this messag= e by mistake, please notify the sender by reply email immediately. Please c= onduct your own virus checks before opening any attachment as Watteco does = not guarantee the integrity of this email or attached files has been mainta= ined nor this communication is free of viruses, interceptions or interferen= ce. Any views expressed in this message are those of the individual sender = and may not necessarily reflect the views of Watteco. Watteco shall not be = responsible nor liable for the improper and incomplete transmission of the = information contained in this communication nor for any delay in its receip= t or damage to your system. --_000_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A6878IE2RD2XVS211r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Signature 3

Any Guidelines on this ?

 

C=E9dric.

 

De : r= oll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de C = Chauvenet
Envoy=E9 : mardi 8 mars 2011 17:08
=C0 = : M Pouillot; 'roll@ietf.org'
Objet : Re: [Roll] [Spam] = DAO No-Path in a storing mode

 

Hi all,

 

As mentionned in the mail below, the no-path DAO mess= age usage in not very clear in the RPL specification.

=

Though it is important to clarify this because = it is an important feature for reliable and reactive downward routing.=

 

Section 9.1.4 clearly states that DAO massages MU= ST be sent on a link local address, thus limiting the no-path DAO destinati= on set to one hop neighboring. But given that this message should advertise= that a downward path is no longer usable, how do you propagate this inform= ation in the upward direction to erase that path ?

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>For instance how do you prevent the DAGroot (located several hop away= ) to use a broken downward path if you can send the no-path DAO to you link= local scope only ?

 

Some papers says that t= he no-path DAO must be sent to the root, but this seems contradictory with = the 9.1.4 section I pointed out (DAO are link local only in storing mode).<= o:p>

 

I would appreciate that people shed some ligh= t on this ..

 

Thanks

 

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>C=E9dric.

 = ;

 

<= div>

De := roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = Mathieu Pouillot
Envoy=E9 : lundi 10 janvier 2011 09:09
<= b>=C0 : roll@ietf.org
Objet : [Spam] [Roll] DAO No-= Path in a storing mode

 

= Hello ,

In the specification, for storing mode, it is specified that= a device should send a DAO no-path to a node which is removed from the DAO= parent set (9.8.4). For me a node is removed from the DAO parent set if it= is unreachable on link-local and so I can't send a DAO no-path to this nod= e. A solution to inform the old DAO parent should be to send the No-path on= the global address but it is not allowed by the specification  (9.1.4= -in storing mode DAO message MUST be link-local-). So only the lifetime wil= l remove the route from the old DAO parent, that can take few minutes depen= ds of the DAO lifetime setting.
What do you think about that?

bes= t regards,

Mathieu

-- <= /o:p>

Mathieu POUILLOT
R&D E= ngineer

m.pouillot@wattec= o.com

= Direct line : +33(0)4 98 01 60 05

Tel : +33(0)4 98 01 60 05
= Fax : +33(= 0)4 94 14 10 80

1766 Chemin de la Planquette
83130 LA GARDE ̵= 1; France
www.watteco.com

Before printing think about environment and costs

This Message may contain confidential information intended only for= the use of the addressee named above. If you are not the intended recipien= t of this message you are hereby notified that any use, dissemination, dist= ribution or reproduction of this message is prohibited. If you received thi= s message by mistake, please notify the sender by reply email immediately. = Please conduct your own virus checks before opening any attachment as Watte= co does not guarantee the integrity of this email or attached files has bee= n maintained nor this communication is free of viruses, interceptions or in= terference. Any views expressed in this message are those of the individual= sender and may not necessarily reflect the views of Watteco. Watteco shall= not be responsible nor liable for the improper and incomplete transmission= of the information contained in this communication nor for any delay in it= s receipt or damage to your system.

 

= --_000_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A6878IE2RD2XVS211r_-- --_005_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A6878IE2RD2XVS211r_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=7606; creation-date="Fri, 11 Mar 2011 08:08:18 GMT"; modification-date="Fri, 11 Mar 2011 08:08:18 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAWgAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAIRwAADmgAABSuAAAdtP/bAIQAAQEBAQEBAQEBAQIBAQECAgIBAQICAgICAgICAgMC AwMDAwIDAwQEBAQEAwUFBQUFBQcHBwcHCAgICAgICAgICAEBAQECAgIFAwMFBwUEBQcICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI/8IAEQgAoAD8AwERAAIR AQMRAf/EAO0AAQACAgMBAQAAAAAAAAAAAAACAwEEBQYHCAkBAQABBQEBAAAAAAAAAAAAAAABAgME BgcFCBAAAQQCAQQDAAICAwAAAAAAAAERAgMEBQYQQBIVMCETIAdQFnCAMREAAgEBBQMIBQoEBgMA AAAAAQIDBAARIRIFMVETQEHRIjKTFDQQYXFCBiCBkaGxUpIjMzVygkNTcPCi0nMkg5QVEgABAwMD AwUAAAAAAAAAAAABABEyEECRICECMVESUHCQYXETAQACAQIEBQQDAQEBAQAAAAEAESExYRBBUXEg MECBkaGx0fHwweFQYHCA/9oADAMBAAIRAxEAAAH9QuIVAAAAAAD27rrnvZjoQhum4bSdymNk2obC NiF5ZCwuhIyfMvz5IAAAAAGD6G7jHLek83Jm4bJsTOxEbBaWlpMkCwA+auAyAMHmGwVcZ6E+javT zuPAAE630f3iFbzU2zbNg2Zm6I2i4sLCRIyTAPnHg8gdazJ+Ue53tXb7lNin27ULPsvCqOQoADnv ae4dejjzoxtm0bJsFxeXFhaTBIkAfPPDpHG3XUOtT8kdByPSMKn6K8i1y+o07XMVoAPRN5j0LeHX TrxtmyXpvReXFpYWEwTMgHgPFZHEbe+jN7j4TzK/qbGp4HDjieOTbUAEqntnW45DNdKNc2i82Jm2 I2C0uJkyQJmQDwvjgdI2SeX2R9De3HmuO6xr87eiQAB2nY3pfQGmdOLjaLi8sLi4sLCRIEzIB4py WQOt7M7DsceM6TOpYctjLTZPTrS+89Z6XG7lusGiWmwWpuRcWFpMmWAEzIB49y0NWp1O5OjecRbd dtuxY7hbiMvc7bv+6x2bYGkdZLS0uLU2IuLSZYSJAmZAB5RzaR1mt5/QkadTJydtuQxW939+O47U gdaIFhYWlpMsLCwkWAEzIAPMufAAAAOw+47XshLgzVLCZMmXEyRMmSJgFgAB55o4AACdTsvvub9d g4k0yZMmSJFpYSJEiRkAsAAOjaeAAzLk/Qc97K+8icYa5IkSJEiRItJEiQMzMogZAAOoauGZbF9v Zjks9ddCk48iZJEjJIySMkiZMAmZAAANawnUtuMyArNUpMmTJIyZMmTJkySJAFgAAAAMESsqIAyD JIGTJkGTJkyACwAAAGsYMAGQDIMgGTJkGQADJkkAAACgAyAAZAMgAAEjIBkAAAAFYAABkAAGTIMg AAAAAAAAAAAAAAAAAAAAAAA//9oACAEBAAEFAvW689brz1uvPW689brz1uvPW689brz1uvPW689b rz1uvPW689brzWaLSzwPQaIv0+oS9NRqSOo1RHU6sTV6wTWa4TXa8TAwRMLDExMUTHxz8aT86zwi MnRhhhhhhhhhhhhumDHwwyxXuQQTonVPgYYYYX6S7mHH65JzbVvrtlr9tQwwwwxGCylFPGKqyf8A oiCCdEE+JhhjbbTD0uFscvN3sn+v0tlfxvim0zqMS9MvEYYYY1lP65xlS8aEQRCPRBhPiYYzMqjB xd5wrL2nHY32ZScg4vteLXf1Vp44+n3PIv8AYqoVwrgwwwxo6OmfL6RBBBhPkYYx8b2nI4W1XH9S 8d/Hacw43Dlei5n46zhcKoVQYYYYSKquLSmPQZE/0uYQTonyMMfryHV7D+v8NNPkNj4lfE+Uw5Ph 8ks9jvmGGGGNVjfpcXz/ADrYRBOiDCfGwwxTP1/K+cZflhb/AGuFqNhqeQ4CXw5bVZhw5frrEyOU 4mII0khXKyWPTHHqMmfnNhBE6IJ0T4mGLbqMeO09bsMPBitmdutTxje2Yen4dZfRgaKOLZo9Hjl+ i0ObbGCRTX4n5IX2fnFhuiDfMwxttRibnFq4Lp6sjE4PrMLG/wBC1sYLwPXSWHEKIrPi1U7cTiOu wjCxPJRVSKTks5MMMJ87DDDDDDDDGNhv1ts81YbsmGGGGGGEgsloxIw622eQw38U+ZhhhhhivElI hXCtBVYnNZDDDdmwx4uJRYpHFI1wh1lNEFVZDDdr+VZ4QT+KyRBZqo3d+SHmKqr1buPs++jdGG71 hhhvkbu2/wAn/9oACAECAAEFAvYXnsLz2F57C89heewvPYXnsLz2F57C89heewvPYXnsLzX3TWn9 JH6SP0kfpI/RTzU81PJTyU8lHHH7PDi1XbU6q+ZLQ5KFlMoL/GMXVEbtaMeVktfp66ek5pE2FULy UWX+Gvq8reyYYhWslwcZKCdjJTkeS3zeWZsI1jDDDDGnq7NhjU0/ZZY6RVi6fjFEGGGGGMerwh2T DGHmpVDAuWcCu2M02lrQYYYYY12O8uzYYY1cmllXeEMWcqy+SyXx+/AjFxCMHWmrwj2bDHiR8orf fOxUSSE65i1TPGRGuRGDGFjePasMJ9C+RJ1V1HUYSJ9mJi9swwwwwwwwxj4vbsMMMMMMJFynGbuG GGGGGIYyqQgidywwwlKkcYjBE7v80PBP+P8A/9oACAEDAAEFAnHHHHHHHHHHHHHHHHHH/wAo3fIn VV75FF75V/7uf//aAAgBAgIGPwKRypHKkcqRypHKkcqRypHKkcqRypHKkcqRypHKDn0AflvtxXRN yvPHin68qsdQtWC+09WEtR5WvlQUJ1tasnPWmy8e+p+1uQnThHkU2hk1u4W9GT6HN+5v3N/vfb+/ X//aAAgBAwIGPwL4gP/aAAgBAQEGPwLyEPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFvIQ90nRby EPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFqZpNHpXdhixp4idvst+ y0n/AK0P+20oGlUwAOA4EXRb9rp+5j6LftlP3MfRb9tp+5j6Lft0HdR9Fv2+Huk6LeRh7tOi3k4u 7Tot5SP8C28tH+BbfoJ+EW/SX6BbsD6Bbsi2zkFKu5F+z0SHex+3khYm5VxZuYCzJDVtqTpgwpIp Khb/AONBk/1W/MoK+FP7nhc4+iFnP1W8VptYlZADldkOKt91gcVPqPylUbWN302VRsWxO61/I3rq wnICFhgQZpJpW7MaDnY2z6ww8Pth0VDfTR/x/wB1vWcNwsFGCr2V3WSmpqaavq3VpBSU8TTScJO0 5C7FF/8Ak2qfi6nqzopMDjTIjEL65FGYNUrIL+HeOoMG578brUlWFyCqijlCbuIge76/kwDmQ5j/ AC+iT14fTyOesqTlhpxe9wvY8wAHOScALVms6gXT4looZKjQqGORuFSMFz8IhcJGkAySM1+3q3Wo E02nNdWaw0aaTRg3cR5Vzi88yqvWY8wFtLFdWx6jT6sGQVEcJhENUi8Th4s16st5U7cLVPxLOt1X 8SNnhY7UoIb1gX2ML5P5rT6P8PMW0+ozRap8Rj9IRnqulMf6jnZnHVXeThZI41yRxgLGm4AXAfJm qDz9VftPoRN+J5Hp1GwzUmjr4+sHMZsxiplPzh39qi0gjkWXhsUluIOVhtBu57a5WVKXj4WmqdI0 y/mZJyZHH/j4Sg+21TpHifBTOUekrguYwyI1+YD2Xj57Vun0KCPxMUOm6fFu8Uy0S3ewPfZIolyR xgLGgwAUYAfJAGJOwWji+6Ot7fQx5hgOR6rLo9FTVQ1hIAlbPMyeFeFWTrRqhMi43gAjHdtt8S6L xmqX40FfJVSfqTPWw5ZZG9bSwsbTS3LTxDNJUPcFG9mNnlkon0uuiytLp0hDNwZuvDKCNqyLj6je Oa2k6YvWg0YGurv+V1aCnX63b5h8rjN2Idn8XoJ5z2eS6VWHCDWIZaCc83FX/tQfZIPntS/D0Lf9 v4mkMDXbVo0Gepf8HV9rC2nzRVjaTq9I1NFSTiLiwyQ1sjRcORAy5ogY72xGW68Wigzz6nq/xCst a1Tw0jEzKTGii9rkvSI8JSeyu22nVyaNVtDqswgpPK352JAv/Owvym1UUglZqep8JHCpgaWWo4rQ 5VRZLxipxe4XY2qPE0VQn/z4km1i7hMKSOQsAXyvjgpbq34WvGI32VFF7NsssS8207z6Mo2JyTPP MsCY9Z2CjAZjt9Vp6WTUUp3Q5o6lZEEkE0Dq6ut/OjZbT6vq2qQahqnDWnWWMCKKGFXHVVC73ZnN 7G/E3bhaKXUalGkanqKWFlnC/l1ShWuu977p5rUtfR1SGqppKPwVVxBnTw9OqRRqW90o2I57zbSt Pi1JWj06oD0K8ZCxmjJa47+3avp5tceE8bxeQzQI9LO0xmDoQgbtP71+26zU9RrzzzVsccGpwiph BrUViyLKEUffu6t2ButcLcZx+Y3ZG4ejDtHZyUUdYCYQ6uQpuvy8x9RGBtQ1OeaR6BYVUM94k4Wb F8MS94Lb7haupIaio4eoRCKpJcFrgrC8G7A3tffvAtDHDWVEMcMvFCZ1IJzxuO0vNwh9douJWTyi IKuVjEQUVY0u7HOIVxtDm1KokWJYoyh4VzQQOkkcZuQdkoMdpsZxqVQknF8RERwepUFQjPjH7wGw 4WiWCSUJD2FLA/1IZd2+AWE0g6vuLv8AQSdgtmPzDlgklHV91N/puHZHK7lF53WzSdZuYcw9OUdn ld79QfXa5Rd6Lza73eUYW7N1us3zC3VW707zbHk/Zt2R8rdy3Z/g5//aAAgBAQMBPyHzhQoUKFCh QoUKFChQq6IF6Zarw+F9tAAPjhT8HhcxNpGBqhiBoUgNDgBoP8+kAYD+HSC0L+fSBaF/LpAtDgDo XsSjk88ABU6+2ve3gqBywwOAIcBDygodEUNA1VdCOiBAIcpge6jZHVjy/RZI8owXoj4gaCSHuqDp AA9ipd+gX4hlbVb4BxwHEOXE4GvjDm+iwTZlnTkFqgLFmYWUJk5a+eG6WqIxAoMAOQcoE/WY09Ng W6qBaqY28UxOQ0FSXUQzESC65Bt4QYg+w1/euFm5in0cBOAghwDlwNeIc/B2TsiIMrWZRsrAtVCB 9bKzrJXYDIoy9A0bD1tQ08p2lqbsmfSuLCZb1Jjz49KHXohd9sYfTBLpNo73JRgUoIaVw2AnZOyd k7JUA5H7f4cMf5qO2DgCGHAIEDSGsOJp4jGAvNLsBJGKMjWo1aheRmQyeOYM6gDZzinVehsLBd2d lLbgD0R0f5BCoDkAtANADHhAE7FdRYL9czqsv14cwvjSECCBwBCHKVDiaeI1QGk+FBF4mwoYzLSI QtRi1wwXRiOFsZYVdlZxasqquyLqUwOjAuVDT9QZczeqfK7meIGDPuFp8a8KX6Xcw6uAMQIIcA5c TiaeMXdzIUHsfY+4irwJr6IemznVeTZZngMiDa3yDGWES7rQza1J0QWHUZwLJtnlNdyrq7C9VFTK oTkog7TKZoXhtlQtmg0lhY0ZlM+cavDPnK9+cIExQIIIHAHl+sFGIHyM0Cu0oFS7jSSD1krQcMVX sx9jNkU8DAEsD6+lCzQd0tazCinGsWD37XZZQjrk7MdWncl0KNaLGBwAjWCmWeuSLkdhYW3LEgoK CchTk/lbw1VyfzhBAQwgIQOIeUWoq4cl4nOR5jNEWhe2HVGebpywmw/Avvol8CCyULTLUlDArkjn EW/lhu+4RnDVXLY+vNqJgWq6lryMi68wNxrwGwW0GKBqx5CZq/gb9tEJlubq7cHDrUjv8AQgg4FS oQh6MAactX9jhpljdot94QQECBAxAgcT0H89d9BKWrignzT14gQJUrgCVwCVXk9s7Z2ztnbC7QWu hKLsMd4M83gAsoJjWOjrxOyVKJUqEOFeCvJBaF+0++jiDrdDSDdz44H2I5a7E7OCpUqVKgVwIeCv I28NJ8RADQrwak56TFGHBUqVKlSuFSuJ56HOPRHMpUrgqVKZUqUcaZXnX1zulcFcSpXhqVK8dSvJ qVK8IVK8muCvR0ymUymUymVwUSj/AKP/2gAIAQIDAT8h/bvzP278z9u/M/bvzP278z9u/M/bvzP2 78z9u/M/bvzP278z9u/M/bvzP278xZRa6zeZvM3mbjN1m/N2b03uBeXlpcvjUqVKlSpUqVKlSpUq UfZ6KpUqVKhdpW+PvALo+5KiUypUqVKmE6ytXoqlSoHC1gNu5+OGrQKrTnzlgdJUqVKnYWfj0oA1 GZg7n+coEzUPAiHJ9nf8eIH2T0oC1yxwqnQiqybKkx+EBrRK7p9KJEK3c6vTwuDvlKAa/YeIGb6f d6cbo5l3zcu8e1DNnb++k5fOO3657xIrGO/4iiu1+0DQ66byjHqasMj6YEys1SAqUGhCMdb+IM6M /WWHqILT7d4AutNMadpQqVOc+nG6IkJ1lIvLh/z/AJ3ioNV7e013/Of5lnS9eALej64A6og56vXA 9IQXHqwvG8oHOaB6vbgHKV/8+//aAAgBAwMBPyG0tLS0tLS0tLS0tLS0tLS0tLS0tly5cuXL/wCZ TL+trirXrYYsvjt9eD/3z/8ATn//2gAMAwEAAhEDEQAAECSSSSSSZWyQojzwhEkkkkklqFAIABII AP8A9xL/AP8AVMBxAIIAANtPvnttAlI2AIAAAG7GFu23xgAgIBAAANkOCNthBhIYIJAAAG5lU222 BoG4BBAAAAAqTyQAMAMJAAAIAPztE74QtIMBAABAAJI3RDSIpI3JJABAALbbbadEAAwIIAAAACSS S+JpIOABJAIAAP8A/kgRASBgAQCiAABt8AAAQSOCSATgAACZAATSSAiSQAQAAAACBAQSCkACQAQA AAAASAQQCQCAAcgAAACSAAQSAAAQCQAAAAAASSAASAQAAAAAAAAAAAAAAAAAAAAAAAD/2gAIAQED AT8Q87Dhw4cOHDhw4cOHDhU3lwqwprjq8GRxgjgNUAhD1QZkAUG/sQEwEwRS7dafihHzm4wWlHLR 7YX2i6wWlFIT2QZO+CGPodH9oaPZi/qfQgL+oaYOwSiqrHSWlpaWlpaWlpaWlpaWjUXpHWKTG4v7 8A5Gu/dDpuwlYwOn8uHjeGw2/M16YESiic00E0+/A1O/gttLbS20ttKw9lEbpgBlVoiz8lyUpJTm aOc+ytXYCGzdorNSFEoNRtK9JbaW2ltpbaW2gJWL7gfvDioP2IfaHgCjsLmbkUndzNKnSPTnRMaJ y9py9pzT+qGpw0+/DS8FZWVgpqsKFTRDRQAyMNRr6NEdK7oESp0IBBVAMA5BHCaYlIDJU5SYE+Rp G2mGQA2AiRc9NgIqF6V86lZWVlZYVmWFgUb+DhnOu7Vf1YOKxAb0QYTcgyQEtIxpmc0/qhqd5ocd K3t4qRLV1VHMdhBjLC4L616GyQAQkB0BJbK0Lj0VNQTH2HSl0fThMuIjYN2DZXAJql6KLNc9S1dX lL0gyREUaLEcgA2PDVYsbbFRPlHtwyNltsPuL8Q3AxsPXNwlBNZoVyhaCu852XUPIicmCZCa+Ol4 uyNYRaxRMFDkuDkdg2ASpDhIJZmLVfBJR568iAJpQkQ7lEC84LJEDnsOq1C86K8oQn3oc3AMAKDB 4fUCMLKigO6ykNJTu/3TwIHIu5aNndtj4QvaYgTkBcpbNIxeJq9pdsHKHFw6PmAMhNLx0vBfaX2l E10hzq5lXjAKKUuAySUHAlQASzfMreBQoWWatZW0Q+opgUGiLzAQosAscLqVZURfaX2l9pfaX2ip ZpbmCfY+VcL6UH0q/bWaVO6xCkyay8dTnFKxLguYLMXOaZU7Q1O/DTx0vB2v1na/Wdr9YVh44Y2X GeoDGWpR5Ukddho3vFE5xc2mBgslKPJaQNmXtTPOYy3VIwjoH8+wVE4vgNmqVKDMXo+5WAsZbT3T F1cAyRYKI5bZaHIiajHJm7167GrtMAoXTTlJ3fpwbMrx0ed7aQnCSnFY6zAr4iYsiaddJ1OU0XQ6 QasSxrHhNDwdk7JiOGadCgrNWArgmOGNblCMLWQtKj4kZYqNvanpb+EkLDXsWLOtJZ2atGzEYDxZ DGO7VZIZlVshdI6W6WNa+XiVO3HUl/8AKNP7gKVGEnKKICg7BoTQRSNlc/k6GOvCxKL+qdfZLc83 Xmyzv0l+E95QprLPfSVOSq0hujTEJtYBoc4Gge0QRTiaHj7DWBCwrJzXUWXcGBKDoa3IyLajFLGr PJ6NhiKhsQhym8VuPSiEuNQtTCBXKtaECok5YRxSCxVAK4GQhBNwH+0vVkx0Gsc8SnFi4LnUeYxr n4FoZC6ORz4VtBamBccWaGh+YB2lFdOcCh0uDPeFIHF6w4uafeafeGp38BoeG8vLy8vLy8vLxnSF J16EuhtzgAAFBoRQKUGVdAly0XDr6v6mCtJg6R6x8yjv1iaxEUSgrmxLtKrgFFfMFp4Dw9s7Z2zt nbO2dsYpoRb/AIbxwwadVPfV34KAq0GVeUUbQfy7QyhV0reZcazLnO0L8oHnDZX80lG6wS6VvKOk BLYDRz4haHi/hmfwzP4Zn8Mz+GYpP0QKvsS1FnevbQ9/iUpB3+4uXgn5gMufuzu/EO5howENEX5u JtQ9sCbw5sMTneFd+NbQHSUdPF3zvj1K+gn7SjqjZ/19IeldQUfL+IDTHOtruueNuOx5d2Zkq0ND twjAzW0DjEvzZWHQQbridwwF0IUu5r4mpAHkBf7P3Zp2kBQDoFeDnp0MsBRV6avvDLSt2X6yu8C6 Fwfad8Cbyqg0uBrOWAGkp6Qoq44mp38tQytE6lehn7TrTu/5MM0Ohj7QfSped0DzzAGhNiXnfNqa YJrgm1K9YFFeA1O/k7z5jfVPvFupcttLzczulesCbyjpxp6S8OtgTeUGh4aYNgxHyby8vO6d07p3 SvWBN5R0lHTxVekt0ndAmuZR0lHTzqekp6Mp6M2JsTam1Nqe1L9Z3TamxKrT/of/2gAIAQIDAT8Q 879+/fv379+/fv379+drLKpXLqrc/fMf9Zn7Jn7ph/rMeq+Wbz5Zvvlm6+ZvPzN9+Zus3JeWl+f/ AP2Ns/sXweJH0Px1o50H2T2YgzHzT5JT4voR1QfLUIToAfHB4kfMvLy8+0AXVegc2DROcjTs5G+s qGC6uCLBoGA7PTZwxdRsnw1Ly8vLxj8lb6vvXAjxPPAKtqDeHmV1ubHT7tWXZpy3iMweVS2eRgiF nSNN245autEtz18IVi88Pu/1wPAeebY13dX4x78H7qd/1BeoQnOc/Bj6yjd4QMBa4IA2oz3cv14c vBfn908hVU2GFvFV0cRgli7oXkDYGjtAuKKgVdxp/wA6mZzwOfkflo+fF/F3S35PjX44EeJ6H2Bo QdzD9H6SptWO5g+NfaYBoWHWg+2XdkjpAIpnCjTFokt1R7XG3Z+xHLIXkpooNrVOpgtvEp6ck1Fi tMY1DNZxKtkP5UonKo1erzeB4D0G5guIC0kxh1w7JcXOXi3PNvnjToe8ogcDRz0e3U5xCrEWKw2V XcTDyojna1OOT9tJRgOORQBVOa0OVZLlGEEqtlotna83SXAraTC2LGx+XgEfSaV4tV/NzU3lpKLe 11p0qsdLesakW7Ppvpiuyy1VRUrn0Trzv7QEaovvra3ru2i7wF289URdeY6aHIgrASurNrDXl116 stXP8of2+kvh4aHXd26dfIv0/wDr4Ww699toFcDHqwFMbZXZ+jkfl416r41o1mWwfX/JTjX34nif RS6C50d3nMfiH415T5N+RtpoQ+IA08V+sr/o1/6v/9oACAEDAwE/ENybk3JuTcm5Nybk3JuTcm5N ybkepNybk3JuQ60XLy0tLS0tly/BiYmJiYmJiYmJiYmJiYj4SPmXLly+A0YOJcuXLly/ER88SwTg OqAvifEEfPrYYXLVcMDxPiPPeFwEobh5t+geCQ8T4j0LpwVKlSvKI+iuXwvySaeguXLly5cuXHx1 L9dXqL/5D5FenfJv/wA7UT0l+Xf/AIv/2Q== --_005_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A6878IE2RD2XVS211r_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=490; creation-date="Fri, 11 Mar 2011 08:08:18 GMT"; modification-date="Fri, 11 Mar 2011 08:08:18 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAXANUiADamKSuhHonKgla0TG29ZEmuPiGbEyliIC+HJBp9DZ+inEGqNYLGel22Ury/ uWW5W3+DfODW4NDK0sS7xU2wQmSPXaTVnZDNiN3v2pzSlpTPjbfespjQkXnCcMLjvlKxRsnmxbLc rAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAACIALAAAAAAYABcAAAb/QM9g SCwajwNMwxBoOgOA6BPwDBgYBGh0a0gkDNvwNiDIig+QyQRy0IqpZTfgIBHZRZLDWxrnKu53Dl9v ZGYBXg6AdhgKCghyhVAHEw51incHFFR8WQZ/l4AQBgMMD1AGcQGfoCIRCVQBBA1NqRWsdwpgAFdw ZgiJtxF6VA8UqGYACROKDhF2wlIEBccBCwmrdhKrEK9UDLS+l6vCCwIMs3CmAAi2dwwHFhJs1RYF GwK7fbvsFQgJbf52NbiQAUDBSFEWwEJwAEFCAxc0yBIwC6EYhggURqHA4UEfi2EONAwToIOFD1pA hnkkxskYAQ/AQJk5ZpNNLVdCFNjJs+dOBwo+eS4AEQQAOw== --_005_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A6878IE2RD2XVS211r_-- From d.sturek@att.net Fri Mar 11 08:24:46 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57E783A69DF for ; Fri, 11 Mar 2011 08:24:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[AWL=0.583, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xHmd9jmmBJgZ for ; Fri, 11 Mar 2011 08:24:45 -0800 (PST) Received: from nm7.bullet.mail.bf1.yahoo.com (nm7.bullet.mail.bf1.yahoo.com [98.139.212.166]) by core3.amsl.com (Postfix) with SMTP id 1AD0D3A6863 for ; Fri, 11 Mar 2011 08:24:45 -0800 (PST) Received: from [98.139.212.144] by nm7.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2011 16:26:00 -0000 Received: from [98.139.212.240] by tm1.bullet.mail.bf1.yahoo.com with NNFMP; 11 Mar 2011 16:26:00 -0000 Received: from [127.0.0.1] by omp1049.mail.bf1.yahoo.com with NNFMP; 11 Mar 2011 16:26:00 -0000 X-Yahoo-Newman-Id: 773536.88138.bm@omp1049.mail.bf1.yahoo.com Received: (qmail 99046 invoked from network); 11 Mar 2011 16:26:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1299860760; bh=ODmbit2KNcSYgfut+wI1oB6hcKtymNuERykyMaX2U6U=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=4XMY9Qu8Pgsz7fcYAy7BZZLAtvh+S3/vOV2R1hkNRCUNi7gomFyP90eariIKKUiikqpSslU+GwXu4qA6hPCFCOkgC2ElUStLax5OjXTwUq3Zqh6qP4oHcYMTysYqkVr3DI7T9WUG29SvF+Y/U10ADh3MZ5IHOPQBRaCCheZkT1o= Received: from Studio (d.sturek@69.105.138.3 with login) by smtp105.sbc.mail.bf1.yahoo.com with SMTP; 11 Mar 2011 08:26:00 -0800 PST X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: M2bpti8VM1mgJ.BugFB8QNRqFZxMO_nnqKFJVRRlYHt3l3d wTscb0AfvqPhvm_utU.921p6aYNQXKN0dwMkM.my_JR3Xbku2JQvK6YXDvz3 MhXVG5tPxo_UXRu4XD9Y5OPOCP3sVKC30GI5u0txwbuVCBrW1lMHarB64yDn JhDHur1n.gJ6i4Nw0Yu0QDrfahc4AppdyxNLct8a8i5jUZ5Fx5zyLrGmmOMN 3J_RTG9kPqtsJu28K6FN3DMHHtEuAb7XFq71zRbbC X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: Date: Fri, 11 Mar 2011 08:25:57 -0800 Message-ID: <01a601cbe009$0159c920$040d5b60$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcvgB+WAjp8ESRgwQ0a1EmHlyn9YMAAAI+vQ Content-Language: en-us Subject: [Roll] FW: Status of ROLL RPL related drafts in 6man (please note point on trickle multicast draft) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Mar 2011 16:24:46 -0000 In checking on the status of 6MAN drafts related to ROLL RPL, I asked about the trickle multicast draft currently in 6MAN. Here is a link to the draft: http://datatracker.ietf.org/doc/draft-hui-6man-trickle-mcast/ Have a look below at the response from Brian Haberman. What does the group think about adopting this draft into ROLL RPL? Don -----Original Message----- From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of Brian Haberman Sent: Friday, March 11, 2011 8:18 AM To: ipv6@ietf.org Subject: Re: Status of ROLL RPL related drafts in 6man On 3/11/11 11:03 AM, Don Sturek wrote: > Can I ask about the current WG status of the following drafts: > > http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-routing-header/ > > http://datatracker.ietf.org/doc/draft-ietf-6man-rpl-option/ > The WG Last Call completed for these documents. There were some comments that, according to the authors, have been resolved but not incorporated into the document(s). > > > Also, the following draft has not been adopted by WG (can it?): > > http://datatracker.ietf.org/doc/draft-hui-6man-trickle-mcast/ > No one has made a request for the WG to adopt it. > > We would also like to see the trickle multicast draft adopted by the group. > >From my brief read of the draft, I am not sure it belongs in 6MAN. It describes a multicast forwarding paradigm specific to low-power networks. It would seem like ROLL is a better fit for this draft. Regards, Brian -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 -------------------------------------------------------------------- From pthubert@cisco.com Sat Mar 12 06:42:18 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1256A3A69B1 for ; Sat, 12 Mar 2011 06:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.435 X-Spam-Level: X-Spam-Status: No, score=-10.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AzUzLc-jJ9nI for ; Sat, 12 Mar 2011 06:42:16 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 0B4AB3A6868 for ; Sat, 12 Mar 2011 06:42:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4528; q=dns/txt; s=iport; t=1299941017; x=1301150617; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=sk8uPgBgb/6S0SP2/UqybfyACRokGcaixwYzmuy+E9I=; b=ertdNZOPukw8ugWKO8Impc9mS1N/5pijcjTlWpbqK4VqyMCAM9135xtR RBY85wn4LYoev3e0J8xeC4nm//OGb2JjmwrdNfHYbIk+venr/5JUe9Fic wLj4G7oX8WWMnUVOGeJTy98RrfnGCUXHsdd+2kGx/kmPZRtole403TJps 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AtMEAMoUe02Q/khLgWdsb2JhbACmQRQBARYmJaRDm1yFYgSQJohr X-IronPort-AV: E=Sophos;i="4.62,307,1297036800"; d="scan'208";a="21441669" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 12 Mar 2011 14:43:36 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2CEhah3022282; Sat, 12 Mar 2011 14:43:36 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 Mar 2011 15:43:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sat, 12 Mar 2011 15:43:32 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D04100B2C@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 Thread-Index: AcvfTlNHw0OH8cOPSGCcJLXH1xEL/ABdDrvA References: <20110301003318.9EA863A6CBA@core3.amsl.com> <4D6D311C.8020001@ieee.org> <4D6EAE68.4050104@ieee.org> <7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu> <8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0405FD39@XMB-AMS-107.cisco.com> <0A9CCA13-35C3-4F14-96D6-B522E3DD858A@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0406047F@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D040FFC6E@XMB-AMS-107.cisco.com> <652D128E-0FDE-41FD-A7A3-634936C4E25B@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D04100 65E@XMB- AMS-107.cisc o.com> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 12 Mar 2011 14:43:36.0179 (UTC) FILETIME=[DE3A2C30:01CBE0C3] Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Mar 2011 14:42:18 -0000 >=20 >=20 > On Mar 10, 2011, at 9:09 AM, Pascal Thubert (pthubert) wrote: >=20 > >> > >> The issue is when minHopRankIncrease is 1, e.g., in your last resort > > OF. > >> > > [Pascal] > > Hum: minHopRankIncrease is a min. In the case of OF0, the default > > increase is 4 times that min. Which leaves room. > > Also, some alternate parents like P1 in my example might have a lower > > Rank than the preferred parent. > > All in all, a node can have multiple parents, at a lower, same or > > higher parent than the preferred. >=20 > Please combine these different specifications together: >=20 > 8.2.2.4. Rank and Movement within a DODAG Version >=20 > 1. A node MUST NOT advertise a Rank less than or equal to any member > of its parent set within the DODAG Version. >=20 > and >=20 > o When the scan is complete, the preferred parent is elected and the > node's rank is computed as the preferred parent rank plus the step > in rank with that parent. >=20 > The failure case is simple. Consider an OF which has a node maintain three > elements in its parent set. The Cisco/ARC implementation does this. The > MinHopRankIncrease is 10. There are three elements of the parent set, > which advertise Ranks of A=3D20, B=3D30, and C=3D35. If the node = computes its > Rank with respect to each element of the parent set, it obtains = a=3D30, b=3D40, > and c=3D45 (upper case is the parent's Rank, lower case is the Rank computed > from that route). >=20 > There are two options: >=20 > Option 1: The node chooses A as the preferred parent. It advertises a Rank of > a=3D30. Following 8.2.2.4, it cannot include B or C in its parent set. If the > MaxRankIncrease is less than 10, the node cannot fall back to B or C in this > DODAG Iteration. [Pascal] You made the hypothesis that the step to A B and C is the min increase. That looks surprising but let's assume it is true. If A is the preferred parent for the actual metrics at hand, the node has to live with it. Assuming a lower Rank than the true one to be below B would in turn prevent B from using A. From the selfish position of the node that's probably fine, but B might think otherwise. The text does what it intends to do, that is prevent greediness. We are trying to build a society of nodes, not to optimize for one given node. =20 > Option 2: The node chooses B or C as the preferred parent. It advertises a > Rank of b=3D40 or c=3D45. Please note that 8.2.1 says "Finally, the preferred > parent is a member of the parent set that is the preferred next hop in > upward routes." This means that if the node wishes to have routing flexibility > in the face of link failure, it must use suboptimal routes. It cannot select B as > its preferred parent then route mostly through A. [Pascal] Agreed. If in turn the path through B as better or equal metrics than through A then the node might pick B and be true to the metric, thus obey RPL's greediness avoidance.=20 >=20 > The basic issue is that the flexibility afforded in parent selection is > constrained to approximately MinHopRankIncrease, or, if the OF is very > pessimistic, closer to its per-hop Rank increase. >=20 [Pascal] We can allow more flexibility as long as the OF has its own anti-greediness strategy. I do not mind adding text around the sentence saying that it is a recommended strategy but that a given OF might have an alternate strategy. > If you remove the requirement from 14.1, then the node could have A as its > preferred parent and advertise a Rank of 36 (max(parent set) + 1). This Rank > is higher than that computed for its preferred parent, but the understanding > is that it may need to very quickly fall over to another element of its parent > set: 30 is not a guarantee under any stretch of the imagination. This is, as far > as I understand it, much closer to what existing implementations do. >=20 > I know you're always concerned with this idea of "greedy" nodes gobbling up > a big parent set and advertising a high Rank, but I don't think that can really > happen given the current DIO processing rules. Once a node sends a DIO, it > constrains how much deeper (how "greedy") it can move in the DODAG. >=20 [Pascal] Yes, that basically stops a count to infinity that we would create in the first place. The best way to get a good graph is probably not to let the CTI limits decide but to be true to the metrics.=20 Pascal=20 From gnawali@cs.stanford.edu Sat Mar 12 23:56:32 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 966843A6AFA for ; Sat, 12 Mar 2011 23:56:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qP4rUKA6FdW for ; Sat, 12 Mar 2011 23:56:31 -0800 (PST) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 902373A6AEE for ; Sat, 12 Mar 2011 23:56:31 -0800 (PST) Received: from mail-iy0-f172.google.com ([209.85.210.172]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1PygBU-0008Cs-VA for roll@ietf.org; Sat, 12 Mar 2011 23:57:53 -0800 Received: by iyi12 with SMTP id 12so1019956iyi.31 for ; Sat, 12 Mar 2011 23:57:52 -0800 (PST) Received: by 10.231.142.21 with SMTP id o21mr8767685ibu.59.1300003072103; Sat, 12 Mar 2011 23:57:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.59.197 with HTTP; Sat, 12 Mar 2011 23:57:32 -0800 (PST) In-Reply-To: <9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> <9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> From: Omprakash Gnawali Date: Sat, 12 Mar 2011 23:57:32 -0800 Message-ID: To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: 078eb853d78558c6c655f7b6c94b391a Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 07:56:32 -0000 Did we decide to stick with the OF0 name? I think there were suggestions to change it so it reflects better what it is about. - om_p On Thu, Mar 10, 2011 at 9:08 AM, JP Vasseur wrote: > Dear all, > This terminates the WG LC. Pascal, I think that you answered one of the > comments > and asked for clarification on the second one. Could you get in touch with > Phil who > commented, make sure that you addressed his point (I think that there still > one > unresolved issue) and post the new revision ? > Thanks. > JP. > On Feb 22, 2011, at 9:03 AM, JP Vasseur wrote: > > Dear all, > This document has been stable for quite some time and the latest revision > has addressed all comments received so far. This starts a 2-week Working > Group Last call on draft-ietf-roll-of0-05, that will end on March 8 at noon > ET. > Please send your comments to the authors and copy the mailing list. > Thanks. > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From pthubert@cisco.com Sun Mar 13 01:30:51 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DD3DF3A6B26 for ; Sun, 13 Mar 2011 01:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.446 X-Spam-Level: X-Spam-Status: No, score=-10.446 tagged_above=-999 required=5 tests=[AWL=0.153, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xywibUACQGPY for ; Sun, 13 Mar 2011 01:30:50 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 832D73A6B2B for ; Sun, 13 Mar 2011 01:30:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1767; q=dns/txt; s=iport; t=1300008732; x=1301218332; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=LkDikj0ubM5SzkotuoNRJaBDyQTkHU7n63/zaYsaKjA=; b=I6KoalOTyBza9UePpmPikFdcNZCHL6LQIV5BxdhK/Z14Lz2bByz2UmZc ryyqyMs1zbQyvjaBV3u0ijI2euSFjcKfpHYfKkRnZ2AvD2AucmrvaKmSG JCWh6ZU2fTxaGY2UqTBtMbUL1+3Zejscu7l6+UvflFojj1EbLjwJ0h6HR 4=; X-IronPort-AV: E=Sophos;i="4.62,310,1297036800"; d="scan'208";a="78928148" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 13 Mar 2011 09:32:08 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2D9W8Tc009712; Sun, 13 Mar 2011 09:32:08 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Mar 2011 10:32:09 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Mar 2011 10:32:05 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D041A1421@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working Last Call on draft-ietf-roll-of0-05 Thread-Index: AcvhVF5O82xu6JZWR4+1L0AgE95lEAADPOZg References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> <9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> From: "Pascal Thubert (pthubert)" To: "Omprakash Gnawali" , "JP Vasseur" X-OriginalArrivalTime: 13 Mar 2011 09:32:09.0292 (UTC) FILETIME=[866340C0:01CBE161] Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 09:30:52 -0000 Hi Om: There was and nothing really came out of it. After a discussion with Phil and Dave, even the term last resort will go away. Cheers, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Omprakash Gnawali [mailto:gnawali@cs.stanford.edu] > Sent: Sunday, March 13, 2011 8:58 AM > To: JP Vasseur > Cc: Pascal Thubert (pthubert); ROLL WG > Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 >=20 > Did we decide to stick with the OF0 name? I think there were suggestions to > change it so it reflects better what it is about. >=20 > - om_p >=20 > On Thu, Mar 10, 2011 at 9:08 AM, JP Vasseur wrote: > > Dear all, > > This terminates the WG LC. Pascal, I think that you answered one of > > the comments and asked for clarification on the second one. Could you > > get in touch with Phil who commented, make sure that you addressed his > > point (I think that there still one unresolved issue) and post the new > > revision ? > > Thanks. > > JP. > > On Feb 22, 2011, at 9:03 AM, JP Vasseur wrote: > > > > Dear all, > > This document has been stable for quite some time and the latest > > revision has addressed all comments received so far. This starts a > > 2-week Working Group Last call on draft-ietf-roll-of0-05, that will > > end on March 8 at noon ET. > > Please send your comments to the authors and copy the mailing list. > > Thanks. > > JP. > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > From jpv@cisco.com Sun Mar 13 01:33:01 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A8BA63A6AF5 for ; Sun, 13 Mar 2011 01:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2qISRT4yVubH for ; Sun, 13 Mar 2011 01:33:00 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 28F963A694C for ; Sun, 13 Mar 2011 01:33:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=1946; q=dns/txt; s=iport; t=1300008862; x=1301218462; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=fKMW3l1BiyczcirNS+/VmtD95sKo5ptcRO0PeXu8yH8=; b=arklDlXKf1xfbHBNtQPRTPzFXEEWm2xlNAvM+/0+MOuBPIC4nJL+lwos jgjDvZeMboMq5wAq6kkn3SMgc7YO99HwKGKo6kG4axpwd2uVSz9SQN14R OhAKnoJDzXPk94Y0L3QhF9JC7+A3Db2jW3SjbfYzH6QdZ5L/1UTo8uGse c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgABAN4dfE2tJV2c/2dsb2JhbACYco1Nd6Q1mnCFYgSMUoNOBg X-IronPort-AV: E=Sophos;i="4.62,310,1297036800"; d="scan'208";a="275561269" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by sj-iport-4.cisco.com with ESMTP; 13 Mar 2011 09:34:21 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by rcdn-core-5.cisco.com (8.14.3/8.14.3) with ESMTP id p2D9YLs5003350; Sun, 13 Mar 2011 09:34:21 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Mar 2011 01:34:21 -0800 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Mar 2011 01:34:20 -0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D041A1421@XMB-AMS-107.cisco.com> Date: Sun, 13 Mar 2011 10:34:18 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> <9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D041A1421@XMB-AMS-107.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 13 Mar 2011 09:34:20.0524 (UTC) FILETIME=[D49BAAC0:01CBE161] Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 09:33:01 -0000 Hi, On Mar 13, 2011, at 10:32 AM, Pascal Thubert (pthubert) wrote: > Hi Om: > > There was and nothing really came out of it. After a discussion with > Phil and Dave, even the term last resort will go away. > As a reminder, changes must be discussed with the WG. JP. > Cheers, > > Pascal > http://www.xtranormal.com/watch/7011357/ > > >> -----Original Message----- >> From: Omprakash Gnawali [mailto:gnawali@cs.stanford.edu] >> Sent: Sunday, March 13, 2011 8:58 AM >> To: JP Vasseur >> Cc: Pascal Thubert (pthubert); ROLL WG >> Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 >> >> Did we decide to stick with the OF0 name? I think there were > suggestions to >> change it so it reflects better what it is about. >> >> - om_p >> >> On Thu, Mar 10, 2011 at 9:08 AM, JP Vasseur wrote: >>> Dear all, >>> This terminates the WG LC. Pascal, I think that you answered one of >>> the comments and asked for clarification on the second one. Could > you >>> get in touch with Phil who commented, make sure that you addressed > his >>> point (I think that there still one unresolved issue) and post the > new >>> revision ? >>> Thanks. >>> JP. >>> On Feb 22, 2011, at 9:03 AM, JP Vasseur wrote: >>> >>> Dear all, >>> This document has been stable for quite some time and the latest >>> revision has addressed all comments received so far. This starts a >>> 2-week Working Group Last call on draft-ietf-roll-of0-05, that will >>> end on March 8 at noon ET. >>> Please send your comments to the authors and copy the mailing list. >>> Thanks. >>> JP. >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >>> From pthubert@cisco.com Sun Mar 13 01:49:37 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B6E43A6953 for ; Sun, 13 Mar 2011 01:49:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.455 X-Spam-Level: X-Spam-Status: No, score=-10.455 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2iRA7uQU9Kie for ; Sun, 13 Mar 2011 01:49:31 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 855543A68BF for ; Sun, 13 Mar 2011 01:49:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=17927; q=dns/txt; s=iport; t=1300009852; x=1301219452; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=OYvJen6Gd//JHAuzjK1xcH8HiHkQgDHfP5VEQMwQ/hM=; b=FC5tWLY8Lx8r1GwUcvs25w2xZkAHwL9WlJKne3PxJk+EPxdiZYiRMGYU 5kJ3B4ESW/VpbFaLd30/Or6QE1JJgsB1r0gIyvsG/KEfpL92dWhxkzFFg PeS+dwNORg4mPTs6jAj9zPPp2rMUtY3+peW50qSbbwmwb7p3VbdhR/TlZ o=; X-IronPort-AV: E=Sophos;i="4.62,310,1297036800"; d="scan'208,217";a="21479914" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 13 Mar 2011 09:50:51 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2D9opGg013367; Sun, 13 Mar 2011 09:50:51 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Mar 2011 10:50:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE164.23812FE7" Date: Sun, 13 Mar 2011 10:50:42 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D041A1425@XMB-AMS-107.cisco.com> In-Reply-To: <9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working Last Call on draft-ietf-roll-of0-05 Thread-Index: AcvfRdEXV13qFGwwR7qz9v9RM4HFzwCG8qTQ References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> <9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur" , "Philip Levis" X-OriginalArrivalTime: 13 Mar 2011 09:50:51.0952 (UTC) FILETIME=[238B9300:01CBE164] Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 09:49:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE164.23812FE7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi JP and Phil: =20 The open issue was Phil's comment on the values that in particular MAXIMUM_RANK_STRETCH would not allow more than 16 worst quality hops, which could be problematic in certain cases =20 It has to be noted that: * Getting 16 hops in a row of the worst possible quality seems, like, extreme * the large gap between MINIMUM_RANK_INCREMENT and MAXIMUM_RANK_STRETCH (a factor of 16) allowed to actually making a distinction between links of different types or categories in order to strongly favor say powered over battery or wire over wireless within a same DAG. A reduced range will lower that capability. To compensate that loss, I'm proposing a new multiplication factor that can be applied by configuration to distinguish such cases. =20 =20 =20 So to address the comment, I'll publish with the new proposed value: =20 MinHopRankIncrease: 256 =20 DEFAULT_RANK_INCREMENT: 3 * MinHopRankIncrease =20 MINIMUM_RANK_INCREMENT: 1 * MinHopRankIncrease =20 MAXIMUM_RANK_INCREMENT: 9 * MinHopRankIncrease =20 MAXIMUM_RANK_STRETCH: 5 * MinHopRankIncrease =20 =20 (NEW) MAXIMUM_RANK_FACTOR: 4 =20 What do you think? =20 =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: JP Vasseur [mailto:jpv@cisco.com]=20 Sent: Thursday, March 10, 2011 6:09 PM To: Pascal Thubert (pthubert) Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 =20 Dear all, =20 This terminates the WG LC. Pascal, I think that you answered one of the comments and asked for clarification on the second one. Could you get in touch with Phil who commented, make sure that you addressed his point (I think that there still one unresolved issue) and post the new revision ? =20 Thanks. =20 JP. =20 On Feb 22, 2011, at 9:03 AM, JP Vasseur wrote: Dear all, =20 This document has been stable for quite some time and the latest revision has addressed all comments received so far. This starts a 2-week Working Group Last call on draft-ietf-roll-of0-05, that will end on March 8 at noon ET. =20 Please send your comments to the authors and copy the mailing list. =20 Thanks. =20 JP. =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CBE164.23812FE7 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi JP and Phil:

 

The open issue was Phil’s comment on the values that in = particular MAXIMUM_RANK_STRETCH would not allow more than 16 worst = quality hops, which could be problematic in certain = cases

 

It has to be noted that:

·         = Getting 16 hops in a row of the worst possible quality seems, like, = extreme

·         = the large gap between MINIMUM_RANK_INCREMENT and MAXIMUM_RANK_STRETCH = (a factor of 16) allowed to actually making a distinction between links = of different types or categories in order to strongly favor say powered = over battery or wire over wireless within a same DAG. A reduced range = will lower that capability. To compensate that loss, I’m proposing = a new multiplication factor that can be applied by configuration to = distinguish such cases.

 

 

 

So to address the comment, I’ll publish with the new proposed = value:

 

   MinHopRankIncrease:  256

 

   DEFAULT_RANK_INCREMENT:  3 * = MinHopRankIncrease

 

   MINIMUM_RANK_INCREMENT:  1 * = MinHopRankIncrease

 

   MAXIMUM_RANK_INCREMENT:  9 * = MinHopRankIncrease

 

   MAXIMUM_RANK_STRETCH:  5 * = MinHopRankIncrease

 

 

(NEW) MAXIMUM_RANK_FACTOR: 4

 

What do you think?

 

 

 

From:= = JP Vasseur [mailto:jpv@cisco.com]
Sent: Thursday, March 10, = 2011 6:09 PM
To: Pascal Thubert (pthubert)
Cc: ROLL = WG
Subject: Re: [Roll] Working Last Call on = draft-ietf-roll-of0-05

 

Dear = all,

 

This terminates the WG LC. Pascal, I think that you = answered one of the comments

and asked for clarification on the second one. Could = you get in touch with Phil who

commented, make sure that you addressed his point (I = think that there still one

unresolved issue) and post the new revision = ?

 

Thanks.

 

JP.

 

On = Feb 22, 2011, at 9:03 AM, JP Vasseur wrote:



Dear = all,

 

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

 

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

 

Thanks.

 

JP.

 

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

 

------_=_NextPart_001_01CBE164.23812FE7-- From pthubert@cisco.com Sun Mar 13 03:10:17 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E5B3A6AB8 for ; Sun, 13 Mar 2011 03:10:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.464 X-Spam-Level: X-Spam-Status: No, score=-10.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2g1A0wxJmrx7 for ; Sun, 13 Mar 2011 03:10:16 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id C65DE3A695C for ; Sun, 13 Mar 2011 03:10:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4350; q=dns/txt; s=iport; t=1300011098; x=1301220698; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6VUKzmx24BEQBCE00lLxEW7J77ZmmccYQINd2htXx4w=; b=I2ss6NSiyr4RqAHlgn8K52FrqAVC4h4Y3iQzlsYpTersAcpF3hLMQiR0 NL2d7t9OaAeabg38W2nCtEVPTH2ZYwU01Ebz63OzW5xPjdJpkWKQFNq2S gWUIun9m7AFjo38twGgeub3fWkfCkUvDiLXda5aydjPiTpve7XeTSy+2A U=; X-IronPort-AV: E=Sophos;i="4.62,310,1297036800"; d="scan'208";a="78930039" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 13 Mar 2011 10:11:37 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2DABbtR032251; Sun, 13 Mar 2011 10:11:37 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Mar 2011 11:11:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Mar 2011 11:11:34 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D041A1431@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working Last Call on draft-ietf-roll-of0-05 Thread-Index: AcvhYdaKtTbzdt6gR3aydu7B9TUVQgAAngOQ References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> <9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D041A1421@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur" X-OriginalArrivalTime: 13 Mar 2011 10:11:36.0925 (UTC) FILETIME=[099B60D0:01CBE167] Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 10:10:17 -0000 Hi JP: The discussion about OF0 and wireless appeared on the ML, and you're right the latest developments should have had continued there. Basically we (seem to) have a consensus that hop count is not wireless friendly. We have text about that in OF0. We also have text in OF0 that says that the step of Rank is/can be strongly related to hop count, which makes it unfriendly to wireless. Yet, the step of Rank but can also derive from link metrics, in which cases depending on how this is done in an implementation, it can be wireless friendly.=20 So the recent addition that OF0 is not wireless friendly was actually partially my mistake. This assertion is really about hop count and classical static metrics that directly derive from hop count. This will be fixed in OF6 as part of that existing discussion. In that same discussion, I proposed to qualify OF0 of a 'last resort' OF. What I meant by that is that OF0 is not expected to be the best possible for a given situation but something that can at least allow connectivity regardless of about everything. In particular, OF0 is not specific about how the Rank is computed when it is derived from a link property, this is fully left to implementation or further guidance. Rather, OF0 normalizes an additive metric to a 'normal' step of Rank giving a range from best to worst -note: this range is what the last open issue is about - . Because OF0 is not specific, it will permit connectivity but not necessarily the expected optimum by a given implementation when multiple implementations that compute the step of Rank differently share a network. I got comments outside the list that last resort is not appropriate. The proposal here is to reword without the term, better explain the above while conserving the spirit.=20 My proposal is to post 18 before cutoff to the diffs will be visible to the group before the last issue is solved. What do you think? Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: JP Vasseur [mailto:jpv@cisco.com] > Sent: Sunday, March 13, 2011 10:34 AM > To: Pascal Thubert (pthubert) > Cc: Omprakash Gnawali; ROLL WG > Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 >=20 > Hi, >=20 > On Mar 13, 2011, at 10:32 AM, Pascal Thubert (pthubert) wrote: >=20 > > Hi Om: > > > > There was and nothing really came out of it. After a discussion with > > Phil and Dave, even the term last resort will go away. > > >=20 > As a reminder, changes must be discussed with the WG. > JP. >=20 > > Cheers, > > > > Pascal > > http://www.xtranormal.com/watch/7011357/ > > > > > >> -----Original Message----- > >> From: Omprakash Gnawali [mailto:gnawali@cs.stanford.edu] > >> Sent: Sunday, March 13, 2011 8:58 AM > >> To: JP Vasseur > >> Cc: Pascal Thubert (pthubert); ROLL WG > >> Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 > >> > >> Did we decide to stick with the OF0 name? I think there were > > suggestions to > >> change it so it reflects better what it is about. > >> > >> - om_p > >> > >> On Thu, Mar 10, 2011 at 9:08 AM, JP Vasseur wrote: > >>> Dear all, > >>> This terminates the WG LC. Pascal, I think that you answered one of > >>> the comments and asked for clarification on the second one. Could > > you > >>> get in touch with Phil who commented, make sure that you addressed > > his > >>> point (I think that there still one unresolved issue) and post the > > new > >>> revision ? > >>> Thanks. > >>> JP. > >>> On Feb 22, 2011, at 9:03 AM, JP Vasseur wrote: > >>> > >>> Dear all, > >>> This document has been stable for quite some time and the latest > >>> revision has addressed all comments received so far. This starts a > >>> 2-week Working Group Last call on draft-ietf-roll-of0-05, that will > >>> end on March 8 at noon ET. > >>> Please send your comments to the authors and copy the mailing list. > >>> Thanks. > >>> JP. > >>> _______________________________________________ > >>> Roll mailing list > >>> Roll@ietf.org > >>> https://www.ietf.org/mailman/listinfo/roll > >>> > >>> > >>> _______________________________________________ > >>> Roll mailing list > >>> Roll@ietf.org > >>> https://www.ietf.org/mailman/listinfo/roll > >>> > >>> From pthubert@cisco.com Sun Mar 13 03:56:46 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CA8CE3A6AF6 for ; Sun, 13 Mar 2011 03:56:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.471 X-Spam-Level: X-Spam-Status: No, score=-10.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dKNbriZXnDLH for ; Sun, 13 Mar 2011 03:56:39 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 5FD193A69ED for ; Sun, 13 Mar 2011 03:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=26547; q=dns/txt; s=iport; t=1300013880; x=1301223480; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=BXmBi+FMArtc0lICqfsuiDkQ89A7aRB76MilGmnU584=; b=iWJm720Au5m18WceoKShoFK5jabUjK/gC2OVz9GgR9+fTD9qyexJjJPr 3i/8El+wRXserr4XJIbY1p+cczn5euxlxeFZ87CZDbRetQ4DN80BW1UJt nHrwJPFKeVbHSX22gDJof9WsHU9exWgUWFitVQUQWIyYQNVH9N9wb80aB A=; X-IronPort-AV: E=Sophos;i="4.62,310,1297036800"; d="scan'208,217";a="78931595" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 13 Mar 2011 10:57:59 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2DAvxZP007107; Sun, 13 Mar 2011 10:57:59 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Mar 2011 11:57:59 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE16D.841476C7" Date: Sun, 13 Mar 2011 11:57:54 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D041A1442@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D041A1425@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working Last Call on draft-ietf-roll-of0-05 Thread-Index: AcvfRdEXV13qFGwwR7qz9v9RM4HFzwCG8qTQAALXArA= References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com><9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D041A1425@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur" , "Philip Levis" X-OriginalArrivalTime: 13 Mar 2011 10:57:59.0696 (UTC) FILETIME=[84448900:01CBE16D] Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 10:56:46 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE16D.841476C7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable All: =20 Here's more text that goes with the proposed resolutionof the range issue: =20 The gap between MINIMUM_RANK_INCREMENT and MAXIMUM_RANK_STRETCH may not be sufficient in every case to strongly distinguish links of different types or categories in order to favor, say, powered over battery-operated or wired over wireless, within a same DAG. An implementation SHOULD allow a configurable factor called Rank Factor and to apply the factor on all links and peers. An implementation MAY recognizes sub-categories of peers and links, such as different MAC types, in which case it SHOULD be able to configure a more specific Rank Factor to those categories. The Rank Factor SHOULD be set between MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR. Once a step of Rank is computed along the rules specified in this document, the result of the computation is multipled by the Rank Factor and the result is what gets added to the Rank of preferred parent in order to obtain the Rank of this node. =20 also =20 7. OF0 Constants and Variables =20 OF0 uses the following constants: =20 MinHopRankIncrease: 256 =20 DEFAULT_RANK_INCREMENT: 3 * MinHopRankIncrease =20 MINIMUM_RANK_INCREMENT: 1 * MinHopRankIncrease =20 MAXIMUM_RANK_INCREMENT: 9 * MinHopRankIncrease =20 MAXIMUM_RANK_STRETCH: 5 * MinHopRankIncrease =20 DEFAULT_RANK_FACTOR: 1 =20 MINIMUM_RANK_FACTOR: 1 =20 MAXIMUM_RANK_FACTOR: 4 =20 =20 What do you think? =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert (pthubert) Sent: Sunday, March 13, 2011 10:51 AM To: JP Vasseur; Philip Levis Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 =20 Hi JP and Phil: =20 The open issue was Phil's comment on the values that in particular MAXIMUM_RANK_STRETCH would not allow more than 16 worst quality hops, which could be problematic in certain cases =20 It has to be noted that: * Getting 16 hops in a row of the worst possible quality seems, like, extreme * the large gap between MINIMUM_RANK_INCREMENT and MAXIMUM_RANK_STRETCH (a factor of 16) allowed to actually making a distinction between links of different types or categories in order to strongly favor say powered over battery or wire over wireless within a same DAG. A reduced range will lower that capability. To compensate that loss, I'm proposing a new multiplication factor that can be applied by configuration to distinguish such cases. =20 =20 =20 So to address the comment, I'll publish with the new proposed value: =20 MinHopRankIncrease: 256 =20 DEFAULT_RANK_INCREMENT: 3 * MinHopRankIncrease =20 MINIMUM_RANK_INCREMENT: 1 * MinHopRankIncrease =20 MAXIMUM_RANK_INCREMENT: 9 * MinHopRankIncrease =20 MAXIMUM_RANK_STRETCH: 5 * MinHopRankIncrease =20 =20 (NEW) MAXIMUM_RANK_FACTOR: 4 =20 What do you think? =20 =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: JP Vasseur [mailto:jpv@cisco.com]=20 Sent: Thursday, March 10, 2011 6:09 PM To: Pascal Thubert (pthubert) Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 =20 Dear all, =20 This terminates the WG LC. Pascal, I think that you answered one of the comments and asked for clarification on the second one. Could you get in touch with Phil who commented, make sure that you addressed his point (I think that there still one unresolved issue) and post the new revision ? =20 Thanks. =20 JP. =20 On Feb 22, 2011, at 9:03 AM, JP Vasseur wrote: =20 Dear all, =20 This document has been stable for quite some time and the latest revision has addressed all comments received so far. This starts a 2-week Working Group Last call on draft-ietf-roll-of0-05, that will end on March 8 at noon ET. =20 Please send your comments to the authors and copy the mailing list. =20 Thanks. =20 JP. =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CBE16D.841476C7 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

All:

 

Here’s more text that goes with the proposed resolutionof the = range issue:

 

   The = gap between MINIMUM_RANK_INCREMENT and MAXIMUM_RANK_STRETCH = may

   not be = sufficient in every case to strongly distinguish links = of

   = different types or categories in order to favor, say, powered = over

   = battery-operated or wired over wireless, within a same DAG.  = An

   = implementation SHOULD allow a configurable factor called Rank = Factor

   and to = apply the factor on all links and peers.  An = implementation

   MAY = recognizes sub-categories of peers and links, such as = different

   MAC = types, in which case it SHOULD be able to configure a = more

   = specific Rank Factor to those categories.  The Rank Factor SHOULD = be

   set = between MINIMUM_RANK_FACTOR and MAXIMUM_RANK_FACTOR.  Once a = step

   of = Rank is computed along the rules specified in this document, = the

   result = of the computation is multipled by the Rank Factor and = the

   result = is what gets added to the Rank of preferred parent in order = to

   obtain = the Rank of this node.

 

also

 

7.  OF0 = Constants and Variables

 

   OF0 = uses the following constants:

 

   = MinHopRankIncrease:  256

 

   = DEFAULT_RANK_INCREMENT:  3 * = MinHopRankIncrease

 

   = MINIMUM_RANK_INCREMENT:  1 * = MinHopRankIncrease

 

   = MAXIMUM_RANK_INCREMENT:  9 * = MinHopRankIncrease

 

   = MAXIMUM_RANK_STRETCH:  5 * = MinHopRankIncrease

 

   = DEFAULT_RANK_FACTOR:  1

 

   = MINIMUM_RANK_FACTOR:  1

 

   = MAXIMUM_RANK_FACTOR:  4

 

 

What do you think?

 

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Pascal Thubert (pthubert)
Sent: Sunday, March 13, 2011 = 10:51 AM
To: JP Vasseur; Philip Levis
Cc: ROLL = WG
Subject: Re: [Roll] Working Last Call on = draft-ietf-roll-of0-05

 

Hi JP and Phil:

 

The open issue was Phil’s comment on the values that in = particular MAXIMUM_RANK_STRETCH would not allow more than 16 worst = quality hops, which could be problematic in certain = cases

 

It has to be noted that:

·         = Getting 16 hops in a row of the worst possible quality seems, like, = extreme

·         = the large gap between MINIMUM_RANK_INCREMENT and MAXIMUM_RANK_STRETCH = (a factor of 16) allowed to actually making a distinction between links = of different types or categories in order to strongly favor say powered = over battery or wire over wireless within a same DAG. A reduced range = will lower that capability. To compensate that loss, I’m proposing = a new multiplication factor that can be applied by configuration to = distinguish such cases.

 

 

 

So to address the comment, I’ll publish with the new proposed = value:

 

   MinHopRankIncrease:  256

 

   DEFAULT_RANK_INCREMENT:  3 * = MinHopRankIncrease

 

   MINIMUM_RANK_INCREMENT:  1 * = MinHopRankIncrease

 

   MAXIMUM_RANK_INCREMENT:  9 * = MinHopRankIncrease

 

   MAXIMUM_RANK_STRETCH:  5 * = MinHopRankIncrease

 

 

(NEW) MAXIMUM_RANK_FACTOR: 4

 

What do you think?

 

 

 

From:= = JP Vasseur [mailto:jpv@cisco.com]
Sent: Thursday, March 10, = 2011 6:09 PM
To: Pascal Thubert (pthubert)
Cc: ROLL = WG
Subject: Re: [Roll] Working Last Call on = draft-ietf-roll-of0-05

 

Dear = all,

 

This terminates the WG LC. Pascal, I think that you = answered one of the comments

and asked for clarification on the second one. Could = you get in touch with Phil who

commented, make sure that you addressed his point (I = think that there still one

unresolved issue) and post the new revision = ?

 

Thanks.

 

JP.

 

On = Feb 22, 2011, at 9:03 AM, JP Vasseur wrote:

 

Dear all,

 

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

 

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

 

Thanks.

 

JP.

 

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

 

------_=_NextPart_001_01CBE16D.841476C7-- From gnawali@cs.stanford.edu Sun Mar 13 09:30:45 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11B533A6A4A for ; Sun, 13 Mar 2011 09:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ikc0LLu4tCwD for ; Sun, 13 Mar 2011 09:30:44 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 451783A6A21 for ; Sun, 13 Mar 2011 09:30:44 -0700 (PDT) Received: from mail-iy0-f172.google.com ([209.85.210.172]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1PyoD8-0003B6-JR for roll@ietf.org; Sun, 13 Mar 2011 09:32:06 -0700 Received: by iyi12 with SMTP id 12so1303400iyi.31 for ; Sun, 13 Mar 2011 09:32:05 -0700 (PDT) Received: by 10.231.3.142 with SMTP id 14mr9051145ibn.84.1300033925823; Sun, 13 Mar 2011 09:32:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.59.197 with HTTP; Sun, 13 Mar 2011 09:31:45 -0700 (PDT) In-Reply-To: References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> <9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D041A1421@XMB-AMS-107.cisco.com> From: Omprakash Gnawali Date: Sun, 13 Mar 2011 09:31:45 -0700 Message-ID: To: JP Vasseur Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: ff384b2b9a2989b26e23b1d864f6aba2 Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 16:30:45 -0000 On Sun, Mar 13, 2011 at 1:34 AM, JP Vasseur wrote: > Hi, > > On Mar 13, 2011, at 10:32 AM, Pascal Thubert (pthubert) wrote: > >> Hi Om: >> >> There was and nothing really came out of it. After a discussion with >> Phil and Dave, even the term last resort will go away. How about "no metric" rather than "last resort"? That would be an accurate description of this OF. Why not use a name that describes this OF rather than OF0, which does not say what it is and makes it sound like default OF? If the intention is to make it a default OF, that should be stated explicitly. - om_p From Internet-Drafts@ietf.org Sun Mar 13 10:45:02 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A15903A68C3; Sun, 13 Mar 2011 10:45:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rycB3VEHoxKP; Sun, 13 Mar 2011 10:45:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45E23A67F8; Sun, 13 Mar 2011 10:45:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110313174501.8934.97665.idtracker@localhost> Date: Sun, 13 Mar 2011 10:45:01 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-of0-06.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 17:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : RPL Objective Function 0 Author(s) : P. Thubert Filename : draft-ietf-roll-of0-06.txt Pages : 10 Date : 2011-03-13 The Routing Protocol for Low Power and Lossy Networks (RPL) defines a generic Distance Vector protocol for Low Power and Lossy Networks (LLNs). RPL is instantiated to honor a particular routing objective/ constraint by the adding a specific Objective Function (OF) that is designed to solve that problem. This specification defines a basic OF, OF0, that uses only the abstract properties exposed in RPL messages with no metric container. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-of0-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-13104147.I-D@ietf.org> --NextPart-- From pthubert@cisco.com Sun Mar 13 10:55:39 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E6293A6A19 for ; Sun, 13 Mar 2011 10:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.478 X-Spam-Level: X-Spam-Status: No, score=-10.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0991npxDpVfD for ; Sun, 13 Mar 2011 10:55:38 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 36E2F3A6A00 for ; Sun, 13 Mar 2011 10:55:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1433; q=dns/txt; s=iport; t=1300039021; x=1301248621; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=m5d7x1HyuSbied7WBUw/VFDb4enkgfa4qwJHT5zk0JQ=; b=m+o2wOe7jheUitnGHqW4DUg+0GpQL+TV49Q/O8upKnUi77FkOReMNTy7 zedRlyL2Yfq4Big+KarRdoCctNrcM0lqG0HDqPFsAQ2reMv9JwOb9y12V /aTCeXMbXU6y3JhUTOgfsTmOE/gDqsKK4aBquuhN0azRLRSzlw8dvfD9k M=; X-IronPort-AV: E=Sophos;i="4.62,311,1297036800"; d="scan'208";a="78948827" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 13 Mar 2011 17:56:59 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2DHuxIx027466; Sun, 13 Mar 2011 17:56:59 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 13 Mar 2011 18:57:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Sun, 13 Mar 2011 18:56:57 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D041A1480@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working Last Call on draft-ietf-roll-of0-05 Thread-Index: AcvhnDNmXEt0ZWYQTlqBTStLyvYRvwAC27ig References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> <9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D041A1421@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Omprakash Gnawali" , "JP Vasseur" X-OriginalArrivalTime: 13 Mar 2011 17:57:00.0203 (UTC) FILETIME=[0D2D77B0:01CBE1A8] Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 17:55:39 -0000 Hi Om: It is not really "no metric" BUT "no metric container". An implementation is free to use any property of the link or the peer and turn that into a step of rank... For all I know, MrHof could be seen as an instance of OF0. If that's the case, maybe you can simplify a bit of your spec by inheriting. All in all, it is a bit late for the name changing. We're past last call, focusing on solving the LC issue and pass to IESG. All the best, Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Omprakash Gnawali [mailto:gnawali@cs.stanford.edu] > Sent: Sunday, March 13, 2011 5:32 PM > To: JP Vasseur > Cc: Pascal Thubert (pthubert); ROLL WG > Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 >=20 > On Sun, Mar 13, 2011 at 1:34 AM, JP Vasseur wrote: > > Hi, > > > > On Mar 13, 2011, at 10:32 AM, Pascal Thubert (pthubert) wrote: > > > >> Hi Om: > >> > >> There was and nothing really came out of it. After a discussion with > >> Phil and Dave, even the term last resort will go away. >=20 > How about "no metric" rather than "last resort"? That would be an accurate > description of this OF. Why not use a name that describes this OF rather than > OF0, which does not say what it is and makes it sound like default OF? If the > intention is to make it a default OF, that should be stated explicitly. >=20 > - om_p From pal@cs.stanford.edu Sun Mar 13 11:13:08 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02EEA3A6A3E for ; Sun, 13 Mar 2011 11:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AUV+g68dgnTx for ; Sun, 13 Mar 2011 11:13:07 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 4A4E93A6A1C for ; Sun, 13 Mar 2011 11:13:07 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PypoD-0002ts-LT; Sun, 13 Mar 2011 11:14:29 -0700 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D041A1480@XMB-AMS-107.cisco.com> Date: Sun, 13 Mar 2011 11:14:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> <9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D041A1421@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D041A1480@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: ae35470b07fbe4e2dbb6b33d1de23969 Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 18:13:08 -0000 On Mar 13, 2011, at 10:56 AM, Pascal Thubert (pthubert) wrote: > Hi Om: >=20 > It is not really "no metric" BUT "no metric container". An > implementation is free to use any property of the link or the peer and > turn that into a step of rank... > For all I know, MrHof could be seen as an instance of OF0. If that's = the > case, maybe you can simplify a bit of your spec by inheriting. >=20 > All in all, it is a bit late for the name changing. We're past last > call, focusing on solving the LC issue and pass to IESG. The IESG changes for RPL necessitate some changes. For example, the = current text relating to backup next hop is now out of sync with RPL = section 14 (and, actually, RPL generally, there's no mention of a parent = set, and the rules for the backup next hop in Section 5 contradict DIO = processing rules in RPL). These issues were minor when OF0 stated it was = not suited to wireless (which, as written, it isn't), but now that the = this qualification has been removed there are further issues. Here's the basic problem: as a working group, our job is to try to = standardize and specify standard, well understood practice when at all = possible, and only when absolutely necessary discuss and reach consensus = on something new. OF0 is taking on a role of being the basic OF that = nodes SHOULD support for interoperability (i.e., so that a RPL node can = join an OF0 network as a router). There's a huge amount of engineering = experience in this space, many different networks and protocols that do = something much like RPL. But *none* of them, as far as I know, do anything like OF0. It's = something "new." This seems contrary to the overall goal of the IETF. = OF0 is the way it is because you wrote it up early as an idea for how an = OF might work. Our criterion for what to standardize on should not be = "first out of the gate." It seems like a terrible mistake to me to have = RPL specify OF0 -- a routing metric with almost no long-term, practical = experience -- as the basic interoperable routing metric when there are = others which are well understood. These issues have to do with the real details of OF0, not its basic = ideas, which are sound. But good engineering often deals with details, = as the recent discussions over section 14 demonstrate. Phil= From pal@cs.stanford.edu Sun Mar 13 11:21:57 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 812493A6B16 for ; Sun, 13 Mar 2011 11:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q8IQ8DxwKdGG for ; Sun, 13 Mar 2011 11:21:56 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 2F8A93A68F5 for ; Sun, 13 Mar 2011 11:21:56 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Pypwi-00039Q-5m; Sun, 13 Mar 2011 11:23:18 -0700 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D041A1431@XMB-AMS-107.cisco.com> Date: Sun, 13 Mar 2011 11:23:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> <9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D041A1421@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D041A1431@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 37a9e86f2e4d2511d38563a73d487f50 Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 18:21:57 -0000 On Mar 13, 2011, at 3:11 AM, Pascal Thubert (pthubert) wrote: > Hi JP: >=20 > The discussion about OF0 and wireless appeared on the ML, and you're > right the latest developments should have had continued there. >=20 > Basically we (seem to) have a consensus that hop count is not wireless > friendly. We have text about that in OF0. >=20 > We also have text in OF0 that says that the step of Rank is/can be > strongly related to hop count, which makes it unfriendly to wireless. > Yet, the step of Rank but can also derive from link metrics, in which > cases depending on how this is done in an implementation, it can be > wireless friendly.=20 >=20 > So the recent addition that OF0 is not wireless friendly was actually > partially my mistake. This assertion is really about hop count and > classical static metrics that directly derive from hop count. This = will > be fixed in OF6 as part of that existing discussion. This is not totally correct. Now some of the processing rules specified = in OF0 are out of sync with the processing rules specified in RPL. E.g.: OF0 says o The backup next_hop MUST be either in the same DODAG version as the preferred parent or in an subsequent version. while RPL says o Every element of a node's DODAG parent set, as conveyed by the last heard DIO message from each DODAG parent, MUST belong to the same DODAG Version. =20 What OF0 is doing is removing the concept of a parent set, which is = critical for DAO operation. OF0 also has text like o A Router with a Rank that is higher than the Rank computed for this node out of the preferred parent SHOULD NOT be selected as parent, to avoid greedy behaviors. It MAY still be selected as sibling if no better Back-up next hop is found. Note that RPL has no notion of "siblings:" this abstraction was pulled = out many, many versions ago. But the current OF0 text has not kept up, = and so it contradicts RPL.=20 > In that same discussion, I proposed to qualify OF0 of a 'last resort' > OF. What I meant by that is that OF0 is not expected to be the best > possible for a given situation but something that can at least allow > connectivity regardless of about everything. In particular, OF0 is not > specific about how the Rank is computed when it is derived from a link > property, this is fully left to implementation or further guidance. >=20 > Rather, OF0 normalizes an additive metric to a 'normal' step of Rank > giving a range from best to worst -note: this range is what the last > open issue is about - . Because OF0 is not specific, it will permit > connectivity but not necessarily the expected optimum by a given > implementation when multiple implementations that compute the step of > Rank differently share a network. >=20 > I got comments outside the list that last resort is not appropriate. = The > proposal here is to reword without the term, better explain the above > while conserving the spirit.=20 >=20 > My proposal is to post 18 before cutoff to the diffs will be visible = to > the group before the last issue is solved. >=20 > What do you think? Given some of these changes are major, I think posting is the right = thing to do. Now that RPL is stable. we should discuss OF0 at 80 and go = through one more iteration on it to make sure it is perfectly in sync = with the main specification. I am happy to help with this and go through = it with a fine-toothed comb. Hopefully we can do this quickly and then = move on immediately after 80. But version -06 will be mildly disastrous, = now that OF0 *is* supposed to apply to wireless and other LLNs. Phil= From gnawali@cs.stanford.edu Sun Mar 13 11:25:46 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3462A3A69C3 for ; Sun, 13 Mar 2011 11:25:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVZPpLCHxg9v for ; Sun, 13 Mar 2011 11:25:45 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 69BD03A68AF for ; Sun, 13 Mar 2011 11:25:45 -0700 (PDT) Received: from mail-iw0-f172.google.com ([209.85.214.172]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Pyq0R-0003GP-SI for roll@ietf.org; Sun, 13 Mar 2011 11:27:08 -0700 Received: by iwl42 with SMTP id 42so5294116iwl.31 for ; Sun, 13 Mar 2011 11:27:07 -0700 (PDT) Received: by 10.231.3.142 with SMTP id 14mr9120003ibn.84.1300040827091; Sun, 13 Mar 2011 11:27:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.59.197 with HTTP; Sun, 13 Mar 2011 11:26:47 -0700 (PDT) In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D041A1480@XMB-AMS-107.cisco.com> References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> <9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D041A1421@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D041A1480@XMB-AMS-107.cisco.com> From: Omprakash Gnawali Date: Sun, 13 Mar 2011 11:26:47 -0700 Message-ID: To: "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: bd70d0bdda1312c8b25f7b39d1e2fb7f Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 18:25:46 -0000 On Sun, Mar 13, 2011 at 10:56 AM, Pascal Thubert (pthubert) wrote: > Hi Om: > > It is not really "no metric" BUT "no metric container". An > implementation is free to use any property of the link or the peer and > turn that into a step of rank... Great. You can call it "no metric container" OF then. > All in all, it is a bit late for the name changing. We're past last > call, focusing on solving the LC issue and pass to IESG. I had suggested the name change in Feb on ROLL list and my assumption was you were looking into that. If it is too late, its not a problem. > For all I know, MrHof could be seen as an instance of OF0. If that's the > case, maybe you can simplify a bit of your spec by inheriting. I am open to this interpretation. However, the inheritance should be from the OF section in RPL draft. That section describes in abstract sense what "OF0" and MRHOF do. It is important for the OF section in RPL, OF0, and MRHOF are compatible in their descriptions of OF. In -06, I suggest being more concrete in this text: "Instead, careful thinking should be applied to determine how the step of Rank is computed from the link properties and attention should be paid to maintain a certain stability in the resulting Rank." - om_p From gnawali@cs.stanford.edu Sun Mar 13 12:25:11 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDF183A6A65 for ; Sun, 13 Mar 2011 12:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tksv1yyiuiQn for ; Sun, 13 Mar 2011 12:25:08 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 862723A6A1A for ; Sun, 13 Mar 2011 12:25:08 -0700 (PDT) Received: from mail-iy0-f172.google.com ([209.85.210.172]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.60) (envelope-from ) id 1Pyqvu-0005WQ-Vj for roll@ietf.org; Sun, 13 Mar 2011 12:26:31 -0700 Received: by iyi12 with SMTP id 12so1409516iyi.31 for ; Sun, 13 Mar 2011 12:26:30 -0700 (PDT) Received: by 10.43.66.5 with SMTP id xo5mr6496103icb.71.1300044390207; Sun, 13 Mar 2011 12:26:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.59.197 with HTTP; Sun, 13 Mar 2011 12:26:10 -0700 (PDT) In-Reply-To: <20110313192248.2F2CA3A6A39@core3.amsl.com> References: <20110313192248.2F2CA3A6A39@core3.amsl.com> From: Omprakash Gnawali Date: Sun, 13 Mar 2011 12:26:10 -0700 Message-ID: To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 10362da83454c0a30f3f1339bddfed40 Subject: [Roll] Fwd: New Version Notification for draft-gnawali-roll-rpl-recommendations-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 Mar 2011 19:25:11 -0000 Here is a new draft. Updates: - clarified that slow down can increase latency - added redundancy constant and route stability vs. path cost sections. Input from the WG on other tried and tested ideas on how to implement/configure RPL welcome. - om_p ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Sun, Mar 13, 2011 at 12:22 PM Subject: New Version Notification for draft-gnawali-roll-rpl-recommendations-01 To: gnawali@cs.stanford.edu Cc: pal@cs.stanford.edu A new version of I-D, draft-gnawali-roll-rpl-recommendations-01.txt has been successfully submitted by Omprakash Gnawali and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-gnawali-roll-rpl-recommendations Revision: =A0 =A0 =A0 =A001 Title: =A0 =A0 =A0 =A0 =A0 Recommendations for Efficient Implementation of = RPL Creation_date: =A0 2011-03-13 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 6 Abstract: RPL is a flexible routing protocol applicable to a wide range of Low Power and Lossy Networks. =A0To enable this wide applicability, RPL provides many configuration options and gives implementers choices on how to implement various components of RPL. =A0Drawing on our experiences, we distill the design choices and configuration parameters that lead to efficient RPL implementations and operations. The IETF Secretariat. From pal@cs.stanford.edu Sun Mar 13 17:15:09 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE7883A68F3 for ; Sun, 13 Mar 2011 17:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NBU9Lo2pe4ZF for ; Sun, 13 Mar 2011 17:15:08 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 028AE3A6A62 for ; Sun, 13 Mar 2011 17:15:05 -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.60) (envelope-from ) id 1PyvSW-0002Hd-Cj; Sun, 13 Mar 2011 17:16:28 -0700 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D04100B2C@XMB-AMS-107.cisco.com> Date: Sun, 13 Mar 2011 17:16:27 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <6B73C805-AE2E-48BF-BC52-AC68813DB1F1@cs.stanford.edu> References: <20110301003318.9EA863A6CBA@core3.amsl.com> <4D6D311C.8020001@ieee.org> <4D6EAE68.4050104@ieee.org> <7DAD25F3-BA17-49BD-AB34-1C1555D696B9@cs.stanford.edu> <8575D552-A980-493C-B3B5-682BA0969ACD@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0405FD39@XMB-AMS-107.cisco.com> <0A9CCA13-35C3-4F14-96D6-B522E3DD858A@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0406047F@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D040FFC6E@XMB-AMS-107.cisco.com> <652D128E-0FDE-41FD-A7A3-634936C4E25B@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D04100 65E@XMB- AMS-107.cisc o.com> <6A2A459175DABE4BB11DE2026AA50A5D04100B2C@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 54cb1bda8084ee4cdf52f72d94b5a886 Cc: roll@ietf.org, phoebus@ieee.org Subject: Re: [Roll] Fwd: New Version Notification fordraft-ietf-roll-minrank-hysteresis-of-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 00:15:09 -0000 On Mar 12, 2011, at 6:43 AM, Pascal Thubert (pthubert) wrote: >>=20 >>=20 >> On Mar 10, 2011, at 9:09 AM, Pascal Thubert (pthubert) wrote: >>=20 >>>>=20 >>>> The issue is when minHopRankIncrease is 1, e.g., in your last > resort >>> OF. >>>>=20 >>> [Pascal] >>> Hum: minHopRankIncrease is a min. In the case of OF0, the default >>> increase is 4 times that min. Which leaves room. >>> Also, some alternate parents like P1 in my example might have a > lower >>> Rank than the preferred parent. >>> All in all, a node can have multiple parents, at a lower, same or >>> higher parent than the preferred. >>=20 >> Please combine these different specifications together: >>=20 >> 8.2.2.4. Rank and Movement within a DODAG Version >>=20 >> 1. A node MUST NOT advertise a Rank less than or equal to any > member >> of its parent set within the DODAG Version. >>=20 >> and >>=20 >> o When the scan is complete, the preferred parent is elected and > the >> node's rank is computed as the preferred parent rank plus the > step >> in rank with that parent. >>=20 >> The failure case is simple. Consider an OF which has a node maintain > three >> elements in its parent set. The Cisco/ARC implementation does this. > The >> MinHopRankIncrease is 10. There are three elements of the parent set, >> which advertise Ranks of A=3D20, B=3D30, and C=3D35. If the node = computes > its >> Rank with respect to each element of the parent set, it obtains a=3D30,= > b=3D40, >> and c=3D45 (upper case is the parent's Rank, lower case is the Rank > computed >> from that route). >>=20 >> There are two options: >>=20 >> Option 1: The node chooses A as the preferred parent. It advertises a > Rank of >> a=3D30. Following 8.2.2.4, it cannot include B or C in its parent = set. > If the >> MaxRankIncrease is less than 10, the node cannot fall back to B or C > in this >> DODAG Iteration. >=20 > [Pascal] You made the hypothesis that the step to A B and C is the min > increase. No, this is not a hypothesis. It's a possible network setup. Or do you = think it's impossible for a network to ever look like this? I am happy = to show you gigabytes of traces from real wireless networks showing such = circumstances. > That looks surprising but let's assume it is true. > If A is the preferred parent for the actual metrics at hand, the node > has to live with it. Assuming a lower Rank than the true one to be = below > B would in turn prevent B from using A. =46rom the selfish position of = the > node that's probably fine, but B might think otherwise. The text does > what it intends to do, that is prevent greediness. We are trying to > build a society of nodes, not to optimize for one given node. I do not understand your metaphors.=20 > [Pascal] Yes, that basically stops a count to infinity that we would > create in the first place. The best way to get a good graph is = probably > not to let the CTI limits decide but to be true to the metrics.=20 What makes you say this? The issue I have is that your claims on what is = better to do seem to be at odds with current practice in most protocol = implementations I am aware of. I'm looking for data to support your = claims. Phil= From pthubert@cisco.com Mon Mar 14 01:55:18 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77BB23A6C11 for ; Mon, 14 Mar 2011 01:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.484 X-Spam-Level: X-Spam-Status: No, score=-10.484 tagged_above=-999 required=5 tests=[AWL=0.115, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8eSHzhDBkuQ6 for ; Mon, 14 Mar 2011 01:55:17 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 9A0DB3A6C3E for ; Mon, 14 Mar 2011 01:55:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4575; q=dns/txt; s=iport; t=1300093000; x=1301302600; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=sRz5G3INW+eX2mmQQYnQ2NCybozGWVS9KgLDntReqeo=; b=DCB9JcH3Vb1vKpY3XuWPMjOxL8e9z043VxGMycM9ZNZfi/U7tympaiXS 4Ot8v6GuoNKRhlwrAQNYPpVKdQk7/zDO8ver8CB2Q7Ebyvo3tbZ6/ASWu DdifyL7CKWWWpsCxTSMFyECw05MZMuwb2DHjbBZP143ekdQq8b7432mb7 4=; X-IronPort-AV: E=Sophos;i="4.62,314,1297036800"; d="scan'208";a="79015854" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-1.cisco.com with ESMTP; 14 Mar 2011 08:56:39 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2E8udRs010818; Mon, 14 Mar 2011 08:56:39 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 09:56:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Mar 2011 09:56:34 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D041A1564@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working Last Call on draft-ietf-roll-of0-05 Thread-Index: Acvhq7uv5HisqihaSheIa96PL7AfqgAd2DkA References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> <9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D041A1421@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D041A1431@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 14 Mar 2011 08:56:39.0509 (UTC) FILETIME=[BB59E850:01CBE225] Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 08:55:18 -0000 Hi Phil: > > > > So the recent addition that OF0 is not wireless friendly was actually > > partially my mistake. This assertion is really about hop count and > > classical static metrics that directly derive from hop count. This > > will be fixed in OF6 as part of that existing discussion. >=20 > This is not totally correct. Now some of the processing rules specified in OF0 > are out of sync with the processing rules specified in RPL. [Pascal] is that related to wireless or a more general comment? >=20 > E.g.: OF0 says >=20 > o The backup next_hop MUST be either in the same DODAG version as > the preferred parent or in an subsequent version. >=20 > while RPL says >=20 > o Every element of a node's DODAG parent > set, as conveyed by the last heard DIO message from each DODAG > parent, MUST belong to the same DODAG Version. >=20 > What OF0 is doing is removing the concept of a parent set, which is critical for > DAO operation. [Pascal] I love the way you reverse logic. The backup next hop is not necessarily a parent (I would have called it backup parent I suppose). It is a backup next hop that allows forwarding traffic. "The backup next_hop might be a parent or a sibling" does not have ONLY in it. But I agree I can make that a bit more clear as a simple editorial. Will do that. Note: If the backup next hop is from a subsequent version then it is also ready to be used as a parent when this node moves to that version, e.g. if the preferred parent in the current version is no more available or the preferred parent move to the subsequent version. You'll note that passing a packet to a non-parent backup implies acting as a leaf for the version of the backup. This is specified in RPL. >=20 > OF0 also has text like >=20 > o A Router with a Rank that is higher than the Rank computed for > this node out of the preferred parent SHOULD NOT be selected as > parent, to avoid greedy behaviors. It MAY still be selected as > sibling if no better Back-up next hop is found. >=20 >=20 > Note that RPL has no notion of "siblings:" this abstraction was pulled out > many, many versions ago. But the current OF0 text has not kept up, and so it > contradicts RPL. [Pascal] RPL does not prevent siblings. It just leaves them to further specification. In particular a new OF is not obliged/encouraged by the main spec to consider siblings. But I think I agree with your bottom line. if OF0 is to be referenced by RPL then this text takes a new importance and should be examined by the group. > > In that same discussion, I proposed to qualify OF0 of a 'last resort' > > OF. What I meant by that is that OF0 is not expected to be the best > > possible for a given situation but something that can at least allow > > connectivity regardless of about everything. In particular, OF0 is not > > specific about how the Rank is computed when it is derived from a link > > property, this is fully left to implementation or further guidance. > > > > Rather, OF0 normalizes an additive metric to a 'normal' step of Rank > > giving a range from best to worst -note: this range is what the last > > open issue is about - . Because OF0 is not specific, it will permit > > connectivity but not necessarily the expected optimum by a given > > implementation when multiple implementations that compute the step of > > Rank differently share a network. > > > > I got comments outside the list that last resort is not appropriate. > > The proposal here is to reword without the term, better explain the > > above while conserving the spirit. > > > > My proposal is to post 18 before cutoff to the diffs will be visible > > to the group before the last issue is solved. > > > > What do you think? >=20 > Given some of these changes are major, I think posting is the right thing to > do. Now that RPL is stable. we should discuss OF0 at 80 and go through one > more iteration on it to make sure it is perfectly in sync with the main > specification. I am happy to help with this and go through it with a fine- > toothed comb. Hopefully we can do this quickly and then move on > immediately after 80. But version -06 will be mildly disastrous, now that OF0 > *is* supposed to apply to wireless and other LLNs. >=20 [Pascal] Your help is definitely appreciated (even and mostly when we disagree at the start : ) ). I'll post a 7 to clarify your point 1. But I need the group on your point 2. Cheers, Pascal From pthubert@cisco.com Mon Mar 14 02:00:31 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 609CC3A6C3E for ; Mon, 14 Mar 2011 02:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.489 X-Spam-Level: X-Spam-Status: No, score=-10.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4LsUp9b8PGOB for ; Mon, 14 Mar 2011 02:00:30 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 133333A68E9 for ; Mon, 14 Mar 2011 02:00:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=902; q=dns/txt; s=iport; t=1300093313; x=1301302913; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=ukBlhHSjEcXcyivEiD8ECCf0P1afjL5bBBclGt+vy20=; b=W7/LNC/eXdJACN+ffwP1fmHMlcQYrbgTmVsG3R1tdhuKw5WlaTZGAz12 mze0OM4RKKQUog8uw1sGoIT2BycTkqlWkTcy56BJSfqJOUJiE3PJ0Itmq fqs8VUpeHB8Qj/JQQCRlM1959hFnhWBSu93bHi7JjR5J9UFohi2MdUGIk I=; X-IronPort-AV: E=Sophos;i="4.62,314,1297036800"; d="scan'208";a="21563108" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 14 Mar 2011 09:01:52 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2E91qMd013149; Mon, 14 Mar 2011 09:01:52 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 10:01:52 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 14 Mar 2011 10:01:50 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D041A156E@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working Last Call on draft-ietf-roll-of0-05 Thread-Index: AcvhrEkf5O1RSWhKQYaHZw9oZFR9AwAeaJaw References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> <9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D041A1421@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D041A1480@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Omprakash Gnawali" X-OriginalArrivalTime: 14 Mar 2011 09:01:52.0623 (UTC) FILETIME=[75FB4FF0:01CBE226] Cc: ROLL WG Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 09:00:31 -0000 Hi Om: > I am open to this interpretation. However, the inheritance should be from > the OF section in RPL draft. That section describes in abstract sense what > "OF0" and MRHOF do. It is important for the OF section in RPL, OF0, and > MRHOF are compatible in their descriptions of OF. >=20 > In -06, I suggest being more concrete in this text: >=20 > "Instead, careful thinking should be applied > to determine how the step of Rank is computed from > the link > properties and attention should be paid to maintain a > certain > stability in the resulting Rank." >=20 [Pascal] I can hardly add normative text at this point.=20 But I suppose that giving a non-normative example that points on Mr Hof as a way to handle the situation would not hurt. I'll optimistically post 7 with that and if that's against the rules after LC then I'll repost to remove. Pascal From Internet-Drafts@ietf.org Mon Mar 14 02:45:04 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E02A3A68E0; Mon, 14 Mar 2011 02:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.571 X-Spam-Level: X-Spam-Status: No, score=-102.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7OCmfgmqugMO; Mon, 14 Mar 2011 02:45:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D0B3A6AAD; Mon, 14 Mar 2011 02:45:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314094501.1366.59375.idtracker@localhost> Date: Mon, 14 Mar 2011 02:45:01 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-of0-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 09:45:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : RPL Objective Function 0 Author(s) : P. Thubert Filename : draft-ietf-roll-of0-07.txt Pages : 10 Date : 2011-03-14 The Routing Protocol for Low Power and Lossy Networks (RPL) defines a generic Distance Vector protocol for Low Power and Lossy Networks (LLNs). RPL is instantiated to honor a particular routing objective/ constraint by the adding a specific Objective Function (OF) that is designed to solve that problem. This specification defines a basic OF, OF0, that uses only the abstract properties exposed in RPL messages with no metric container. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-of0-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14023630.I-D@ietf.org> --NextPart-- From pthubert@cisco.com Mon Mar 14 03:14:10 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B75A3A6B40 for ; Mon, 14 Mar 2011 03:14:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.494 X-Spam-Level: X-Spam-Status: No, score=-10.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4KI3PsHxM9JN for ; Mon, 14 Mar 2011 03:14:09 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id CD40B3A6B10 for ; Mon, 14 Mar 2011 03:14:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4090; q=dns/txt; s=iport; t=1300097732; x=1301307332; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=vg3e15/jV7WCjyopb7hMSgxpkX2b4vCkKRERJCr9ji0=; b=NBkPtDhyVD0B9VD+zXblOHa9Jg96/5W2KQxPVg39cXc/PiZGWqycWhzQ fS9iac5rjU+0UV2eO51T9JR3rwWgl4HSGudIovpCno91IQA5IsCCplL7j PG2+Hk7DVbscQXrdy5BF9DsF5egWyGkr0AH4nEOtkv4cYl2g5nLnXRwXz k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIAAPqHfU2Q/khLgWdsb2JhbACEPZQCjGphFAEBFiYlpC2LG5AKgSeDRXYEkCY X-IronPort-AV: E=Sophos;i="4.62,314,1297036800"; d="scan'208";a="21586593" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 14 Mar 2011 10:15:28 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2EAFS0W021687; Mon, 14 Mar 2011 10:15:28 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 11:15:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Mon, 14 Mar 2011 11:15:22 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D041A1631@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: a status for draft-ietf-roll-of0 Thread-Index: AcviMLnY3sWwq5S4TpiFDkkc0YpS6g== From: "Pascal Thubert (pthubert)" To: "Adrian Farrel" , X-OriginalArrivalTime: 14 Mar 2011 10:15:28.0214 (UTC) FILETIME=[BDE10760:01CBE230] Cc: ROLL WG Subject: [Roll] a status for draft-ietf-roll-of0 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 10:14:10 -0000 SGkgQWRyaWFuIGFuZCBhbGw6DQoNCkhlcmUncyBhIHF1aWNrIHN1bW1hcnkgb24gdGhlIGxhdGVz dCBhY3Rpdml0eSBvbiBPRjAgZHJhZnQuIE9GMC0wNSBwYXNzZWQgbGFzdCBjYWxsIGJ1dCBoYXMg cGVuZGluZyBpc3N1ZXMuDQoNCjA2IGFkZHJlc3NlczoNCi0gaXNzdWVzIHdpdGggdGhlIHJhbmdl IG9mIHRoZSBzdGVwIG9mIFJhbmsgYW5kIHRoZSBudW1iZXIgb2YgaG9wcyBpbiB0aGUgd29yc3Qg Y2FzZSBzY2VuYXJpby4NCi0gaXNzdWVzIHdpdGggdGhlIHJlY29tbWVuZGF0aW9uIFdSVCB3aXJl bGVzcyBsaW5rcw0KDQpUaGFua3MgdG8gT20gYW5kIFBoaWwncyBxdWljayBUQVQgdGhpcyB3ZWVr ZW5kLCBJIGNvdWxkIHB1Ymxpc2ggYW4gMDcgYmFjayB0byBiYWNrIHdpdGggdGhlIDA2LiAwNyBh ZGRpdGlvbmFsbHkgYWRkcmVzc2VzOg0KDQotIGxhY2sgb2YgY2xhcml0eSB0aGF0IHRoZSBiYWNr dXAgbmV4dF9ob3AgaXMgbm90IG5lY2Vzc2FyeSBhIHBhcmVudA0KLSBsYWNrIG9mIGNsYXJpdHkg b24gd2hhdCBwYXlpbmcgYXR0ZW50aW9uIHRvIFJhbmsgc3RhYmlsaXR5IGNvdWxkIG1lYW4uDQoN Ck5vdyB3ZSBuZWVkIHRvIHJldmlldyB0aGUgY2hhbmdlcyBpbiAwNiBhbmQgMDcgYW5kIHNlZSBp ZiB0aGV5IGFkZHJlc3MgdGhlIG9wZW4gaXNzdWVzIHByb3Blcmx5LiBJbiBwYXJ0aWN1bGFyOg0K DQotIFRvIGNvbXBlbnNhdGUgdGhlIHNtYWxsZXIgcmFuZ2UgZm9yIHRoZSBzdGVwIG9mIHJhbmss IGEgbmV3IGZhY3RvciB3YXMgYWRkZWQuIFRoZSBmYWN0b3IgaGFzIGEgZGVmYXVsdCBvZiAxLiBN YXliZSB3ZSBzaG91bGQgcmVjb21tZW5kIGEgZGlmZmVyZW50IGRlZmF1bHQgZm9yIHdpcmVkLXBv d2VyZWQgKHNheSAxKSB3aXJlbGVzcyBvciBiYXR0ZXJ5IChzYXkgMiBvciAzKSBhbmQgd2lyZWxl c3MgYW5kIGJhdHRlcnkgKHNheSA0IG9yIDUpLiBTaW5jZSB0aGlzIGlzIGEgcGFyYW1ldGVyLCBp dCBpcyBhbHdheXMgcG9zc2libGUgZm9yIGEgZGVwbG95bWVudCB0byBvdmVycmlkZSB0aGUgZGVm YXVsdHMgdG8gZ2V0IG1vcmUgaG9wcywgc3RpbGwgdXAgdG8gMjU2IGJlc3QgY2FzZSBhbmQgMjgg d29yc3QgY2FzZSwgYnV0IHRoYXQgcHJvcG9zYWwgd291bGQgeWllbGQgYnkgZGVmYXVsdCBvbmx5 IDUgdG8gNyBob3BzIHRoYXQgY29tYmluZSB3aXJlbGVzcyBhbmQgYmF0dGVyeSBhbmQgd29yc3Qg Y2FzZSBsaW5rICBwcm9wZXJ0aWVzLg0KDQoNCkFsc286DQotIE9GMCBzdGlsbCBtZW50aW9ucyBz aWJsaW5ncyB0aGF0IGFyZSBub3QgZGlzY3Vzc2VkIGFueW1vcmUgaW4gdGhlIG1haW4gc3BlYy4g VGhlIHF1ZXN0aW9uIGlzIHdoYXQgdG8gZG8gd2l0aCB0aGVtIGluIHRoaXMgc3BlYy4gV2UgY291 bGQgb24gcGFwZXI6DQoxKSAgcmVtb3ZlIHRoZSBub3Rpb24gb2Ygc2libGluZyBhbmQgdGhlIHJh bmsgc3RyZXRjaCB0aGF0IGdvZXMgd2l0aCBpdCBhbHRvZ2V0aGVyLiBUaGF0IG1pZ2h0IGJlIHRv dWNoeSBzaW5jZSB0aGUgdGV4dCBtYWRlIGxhc3QgY2FsbCwgYW5kIEkgY2FuJ3QgZGlzY3VzcyB0 aGF0IGFzcGVjdC4NCjIpICBrZWVwIHRoZSB0ZXh0LiBCdXQgdGhlbiB3ZSBwcm9iYWJseSBuZWVk IHRvIHByb3ZpZGUgYSBtaW5pbXVtIGd1aWRhbmNlIGZvciBsb29wIGF2b2lkYW5jZSAoZS5nLiB1 bmxlc3MgZnVydGhlciBndWlkYW5jZSwgZG8gbm90IGZvcndhcmQgdG8gYSBzaWJsaW5nIGEgcGFj a2V0IGZyb20gYSBsZWFmIG9yIGEgc2libGluZykuDQoNCkkgdGhpbmsgSSBkaWQgYWxsIHRoZSBl ZGl0b3JpYWwgd29yayBJIGNvdWxkIGFuZCBJIG5lZWQgZ3VpZGFuY2UgdG8gbW92ZSBmb3J3YXJk Lg0KDQpXaGF0IGRvIHlvdSB0aGluaz8NCg0KUGFzY2FsDQpodHRwOi8vd3d3Lnh0cmFub3JtYWwu Y29tL3dhdGNoLzcwMTEzNTcvDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IElFVEYgSS1EIFN1Ym1pc3Npb24gVG9vbCBbbWFpbHRvOmlkc3VibWlzc2lvbkBpZXRmLm9yZ10g DQpTZW50OiBNb25kYXksIE1hcmNoIDE0LCAyMDExIDEwOjM3IEFNDQpUbzogUGFzY2FsIFRodWJl cnQgKHB0aHViZXJ0KQ0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFm dC1pZXRmLXJvbGwtb2YwLTA3IA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRm LXJvbGwtb2YwLTA3LnR4dCBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBhc2Nh bCBUaHViZXJ0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6 CSBkcmFmdC1pZXRmLXJvbGwtb2YwDQpSZXZpc2lvbjoJIDA3DQpUaXRsZToJCSBSUEwgT2JqZWN0 aXZlIEZ1bmN0aW9uIDANCkNyZWF0aW9uX2RhdGU6CSAyMDExLTAzLTE0DQpXRyBJRDoJCSByb2xs DQpOdW1iZXJfb2ZfcGFnZXM6IDEwDQoNCkFic3RyYWN0Og0KVGhlIFJvdXRpbmcgUHJvdG9jb2wg Zm9yIExvdyBQb3dlciBhbmQgTG9zc3kgTmV0d29ya3MgKFJQTCkgZGVmaW5lcyBhIGdlbmVyaWMg RGlzdGFuY2UgVmVjdG9yIHByb3RvY29sIGZvciBMb3cgUG93ZXIgYW5kIExvc3N5IE5ldHdvcmtz IChMTE5zKS4gIFJQTCBpcyBpbnN0YW50aWF0ZWQgdG8gaG9ub3IgYSBwYXJ0aWN1bGFyIHJvdXRp bmcgb2JqZWN0aXZlLyBjb25zdHJhaW50IGJ5IHRoZSBhZGRpbmcgYSBzcGVjaWZpYyBPYmplY3Rp dmUgRnVuY3Rpb24gKE9GKSB0aGF0IGlzIGRlc2lnbmVkIHRvIHNvbHZlIHRoYXQgcHJvYmxlbS4g IFRoaXMgc3BlY2lmaWNhdGlvbiBkZWZpbmVzIGEgYmFzaWMgT0YsIE9GMCwgdGhhdCB1c2VzIG9u bHkgdGhlIGFic3RyYWN0IHByb3BlcnRpZXMgZXhwb3NlZCBpbiBSUEwgbWVzc2FnZXMgd2l0aCBu byBtZXRyaWMgY29udGFpbmVyLg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClRoZSBJ RVRGIFNlY3JldGFyaWF0Lg0KDQoNCg== From Internet-Drafts@ietf.org Mon Mar 14 08:00:08 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F07003A6DAF; Mon, 14 Mar 2011 08:00:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.574 X-Spam-Level: X-Spam-Status: No, score=-102.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prJUZCAPaBlE; Mon, 14 Mar 2011 08:00:06 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C904A3A6DC5; Mon, 14 Mar 2011 08:00:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314150002.18047.72934.idtracker@localhost> Date: Mon, 14 Mar 2011 08:00:02 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-terminology-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:00:08 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Terminology in Low power And Lossy Networks Author(s) : J. Vasseur Filename : draft-ietf-roll-terminology-05.txt Pages : 8 Date : 2011-03-14 The documents defines a terminology for discussing routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). A LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g. Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-terminology-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14075155.I-D@ietf.org> --NextPart-- From jpv@cisco.com Mon Mar 14 08:44:38 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A92D3A6BA6 for ; Mon, 14 Mar 2011 08:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.498 X-Spam-Level: X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_MOSTLY=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGYlZkSE6iqy for ; Mon, 14 Mar 2011 08:44:37 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 24A6D3A696C for ; Mon, 14 Mar 2011 08:44:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=7912; q=dns/txt; s=iport; t=1300117561; x=1301327161; h=from:subject:date:references:to:message-id:mime-version; bh=dpoajsdwHmz/ihkM4J3km74IXhI0R3inLf//SdYLZLM=; b=fmi88Z7DrIdYKVA7ppy/luPfI+/gaMXuYwXGvSVefNeK/xXchZdy3DFI lIKunlzaUOJsO+ISzuxeMsgA8qkfJrz8RWD+bfj4mPGvBsZTbZIN1EHfr R08ERd0aWUeAakPgV+ljbFVgcfEdvO5RqZ3VRbLGk4uBRivnY/XwIpsXg I=; X-Files: None : None X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar8IAKHVfU2tJXHB/2dsb2JhbACfK4YJVXekFpt0hWIEjFKDTgY X-IronPort-AV: E=Sophos;i="4.62,316,1297036800"; d="scan'208,217";a="346004779" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by sj-iport-5.cisco.com with ESMTP; 14 Mar 2011 15:45:53 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by rcdn-core2-6.cisco.com (8.14.3/8.14.3) with ESMTP id p2EFjMpe017937 for ; Mon, 14 Mar 2011 15:45:52 GMT Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 23:45:48 +0800 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 23:45:47 +0800 From: JP Vasseur Content-Type: multipart/alternative; boundary=Apple-Mail-223--312200605 Date: Mon, 14 Mar 2011 16:45:46 +0100 References: <20110314150002.18047.72934.idtracker@localhost> To: ROLL WG Message-Id: Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 14 Mar 2011 15:45:47.0870 (UTC) FILETIME=[E35087E0:01CBE25E] Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-terminology-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:44:38 -0000 --Apple-Mail-223--312200605 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Simple refresh. Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: March 14, 2011 4:00:02 PM GMT+01:00 > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: I-D Action:draft-ietf-roll-terminology-05.txt > Reply-To: internet-drafts@ietf.org >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Routing Over Low power and Lossy = networks Working Group of the IETF. >=20 >=20 > Title : Terminology in Low power And Lossy Networks > Author(s) : J. Vasseur > Filename : draft-ietf-roll-terminology-05.txt > Pages : 8 > Date : 2011-03-14 >=20 > The documents defines a terminology for discussing routing > requirements and solutions for networks referred to as Low power and > Lossy Networks (LLN). A LLN is typically composed of many embedded > devices with limited power, memory, and processing resources > interconnected by a variety of links. There is a wide scope of > application areas for LLNs, including industrial monitoring, building > automation (e.g. Heating, Ventilating, Air Conditioning, lighting, > access control, fire), connected home, healthcare, environmental > monitoring, urban sensor networks, energy management, assets > tracking, refrigeration. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-05.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-223--312200605 Content-Type: multipart/mixed; boundary=Apple-Mail-224--312200604 --Apple-Mail-224--312200604 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Date: March 14, 2011 4:00:02 PM = GMT+01:00
Subject: I-D = Action:draft-ietf-roll-terminology-05.txt
Reply-To: internet-drafts@ietf.org
<= /span>

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 =           : = Terminology in Low power And Lossy Networks
Author(s) =       : J. Vasseur
Filename =        : = draft-ietf-roll-terminology-05.txt
Pages =           : 8
Date =            : = 2011-03-14

The documents defines a terminology for discussing = routing
requirements and solutions for networks referred to as Low = power and
Lossy Networks (LLN).  A LLN is typically composed of = many embedded
devices with limited power, memory, and processing = resources
interconnected by a variety of links.  There is a wide = scope of
application areas for LLNs, including industrial monitoring, = building
automation (e.g.  Heating, Ventilating, Air = Conditioning, lighting,
access control, fire), connected home, = healthcare, environmental
monitoring, urban sensor networks, energy = management, assets
tracking, refrigeration.

A URL for this = Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-05.t= xt

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

Below is the data = which will enable a MIME compliant mail reader
implementation to = automatically retrieve the ASCII version of = the
Internet-Draft.
= --Apple-Mail-224--312200604 Content-Disposition: attachment; filename="Mail Attachment" Content-Type: message/external-body; name="Mail Attachment" Content-Transfer-Encoding: 7bit Content-Type: text/plain
Content-ID: <2011-03-14075155.I-D@ietf.org>

--Apple-Mail-224--312200604 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii
_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--Apple-Mail-224--312200604-- --Apple-Mail-223--312200605-- From jpv@cisco.com Mon Mar 14 08:46:10 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C83C33A6DE0 for ; Mon, 14 Mar 2011 08:46:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.511 X-Spam-Level: X-Spam-Status: No, score=-110.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6t3uf63y30M5 for ; Mon, 14 Mar 2011 08:46:09 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 43D093A6DE3 for ; Mon, 14 Mar 2011 08:46:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=8851; q=dns/txt; s=iport; t=1300117653; x=1301327253; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=m4e4Aw+fDYXqCxapr4tilUNRjbS7aPBtaAMpy6+F5Ww=; b=L4nJyw0rSLgTTHYy5rASJ92jYqDh8Vy4kM406eHugcvciYIeUk7IDeNv nn7BbnERFcjMteqfgwE8ObfvZRe1CPRNQQAHN4UuhfqLq5d+v1rYsFIw4 x7rAZYVskadC48YwmW+Vdgh6rSYAqmqY7qELY3RFvg2Pt6Mi/O9nOnKrU g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvEAAMrVfU2tJXG8/2dsb2JhbACYRI1Fd6QUm3SFYgSMUoNOBg X-IronPort-AV: E=Sophos;i="4.62,316,1297036800"; d="scan'208,217";a="414193916" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-1.cisco.com with ESMTP; 14 Mar 2011 15:47:32 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2EFlVYx025536; Mon, 14 Mar 2011 15:47:31 GMT Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 23:47:30 +0800 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 23:47:29 +0800 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-225--312101824 From: JP Vasseur In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D041A1631@XMB-AMS-107.cisco.com> Date: Mon, 14 Mar 2011 16:47:25 +0100 Message-Id: <210F1CBE-ACA0-4B68-8F22-C6AAB1081EAE@cisco.com> References: <6A2A459175DABE4BB11DE2026AA50A5D041A1631@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 14 Mar 2011 15:47:29.0577 (UTC) FILETIME=[1FEFC990:01CBE25F] Cc: ROLL WG , Adrian Farrel , roll-chairs@tools.ietf.org Subject: Re: [Roll] a status for draft-ietf-roll-of0 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:46:10 -0000 --Apple-Mail-225--312101824 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Pascal, Thanks for this summary. See in line, On Mar 14, 2011, at 11:15 AM, Pascal Thubert (pthubert) wrote: > Hi Adrian and all: >=20 > Here's a quick summary on the latest activity on OF0 draft. OF0-05 = passed last call but has pending issues. >=20 > 06 addresses: > - issues with the range of the step of Rank and the number of hops in = the worst case scenario. > - issues with the recommendation WRT wireless links >=20 > Thanks to Om and Phil's quick TAT this weekend, I could publish an 07 = back to back with the 06. 07 additionally addresses: >=20 > - lack of clarity that the backup next_hop is not necessary a parent > - lack of clarity on what paying attention to Rank stability could = mean. >=20 > Now we need to review the changes in 06 and 07 and see if they address = the open issues properly. In particular: >=20 > - To compensate the smaller range for the step of rank, a new factor = was added. The factor has a default of 1. Maybe we should recommend a = different default for wired-powered (say 1) wireless or battery (say 2 = or 3) and wireless and battery (say 4 or 5). Since this is a parameter, = it is always possible for a deployment to override the defaults to get = more hops, still up to 256 best case and 28 worst case, but that = proposal would yield by default only 5 to 7 hops that combine wireless = and battery and worst case link properties. >=20 >=20 > Also: > - OF0 still mentions siblings that are not discussed anymore in the = main spec. The question is what to do with them in this spec. We could = on paper: > 1) remove the notion of sibling and the rank stretch that goes with = it altogether. That might be touchy since the text made last call, and I = can't discuss that aspect. > 2) keep the text. But then we probably need to provide a minimum = guidance for loop avoidance (e.g. unless further guidance, do not = forward to a sibling a packet from a leaf or a sibling). >=20 > I think I did all the editorial work I could and I need guidance to = move forward. >=20 > What do you think? >=20 >=20 I would vote for 1) since there was an agreement do remove the notion of = siblings from the core specification. Thanks. JP. > Pascal > http://www.xtranormal.com/watch/7011357/ >=20 >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Monday, March 14, 2011 10:37 AM > To: Pascal Thubert (pthubert) > Subject: New Version Notification for draft-ietf-roll-of0-07 >=20 >=20 > A new version of I-D, draft-ietf-roll-of0-07.txt has been successfully = submitted by Pascal Thubert and posted to the IETF repository. >=20 > Filename: draft-ietf-roll-of0 > Revision: 07 > Title: RPL Objective Function 0 > Creation_date: 2011-03-14 > WG ID: roll > Number_of_pages: 10 >=20 > Abstract: > The Routing Protocol for Low Power and Lossy Networks (RPL) defines a = generic Distance Vector protocol for Low Power and Lossy Networks = (LLNs). RPL is instantiated to honor a particular routing objective/ = constraint by the adding a specific Objective Function (OF) that is = designed to solve that problem. This specification defines a basic OF, = OF0, that uses only the abstract properties exposed in RPL messages with = no metric container. > = =20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 --Apple-Mail-225--312101824 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii Hi Pascal,

Thanks for this summary.

See in line,

On Mar 14, 2011, at 11:15 AM, Pascal Thubert (pthubert) wrote:

Hi Adrian and all:

Here's a quick summary on the latest activity on OF0 draft. OF0-05 passed last call but has pending issues.

06 addresses:
- issues with the range of the step of Rank and the number of hops in the worst case scenario.
- issues with the recommendation WRT wireless links

Thanks to Om and Phil's quick TAT this weekend, I could publish an 07 back to back with the 06. 07 additionally addresses:

- lack of clarity that the backup next_hop is not necessary a parent
- lack of clarity on what paying attention to Rank stability could mean.

Now we need to review the changes in 06 and 07 and see if they address the open issues properly. In particular:

- To compensate the smaller range for the step of rank, a new factor was added. The factor has a default of 1. Maybe we should recommend a different default for wired-powered (say 1) wireless or battery (say 2 or 3) and wireless and battery (say 4 or 5). Since this is a parameter, it is always possible for a deployment to override the defaults to get more hops, still up to 256 best case and 28 worst case, but that proposal would yield by default only 5 to 7 hops that combine wireless and battery and worst case link  properties.


Also:
- OF0 still mentions siblings that are not discussed anymore in the main spec. The question is what to do with them in this spec. We could on paper:
1)  remove the notion of sibling and the rank stretch that goes with it altogether. That might be touchy since the text made last call, and I can't discuss that aspect.
2)  keep the text. But then we probably need to provide a minimum guidance for loop avoidance (e.g. unless further guidance, do not forward to a sibling a packet from a leaf or a sibling).

I think I did all the editorial work I could and I need guidance to move forward.

What do you think?

I would vote for 1) since there was an agreement do remove the notion of siblings from the core specification.

Thanks.

JP.

Pascal
http://www.xtranormal.com/watch/7011357/


-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]
Sent: Monday, March 14, 2011 10:37 AM
To: Pascal Thubert (pthubert)
Subject: New Version Notification for draft-ietf-roll-of0-07


A new version of I-D, draft-ietf-roll-of0-07.txt has been successfully submitted by Pascal Thubert and posted to the IETF repository.

Filename:        draft-ietf-roll-of0
Revision:        07
Title:           RPL Objective Function 0
Creation_date:   2011-03-14
WG ID:           roll
Number_of_pages: 10

Abstract:
The Routing Protocol for Low Power and Lossy Networks (RPL) defines a generic Distance Vector protocol for Low Power and Lossy Networks (LLNs).  RPL is instantiated to honor a particular routing objective/ constraint by the adding a specific Objective Function (OF) that is designed to solve that problem.  This specification defines a basic OF, OF0, that uses only the abstract properties exposed in RPL messages with no metric container.
                                                                                 


The IETF Secretariat.


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


--Apple-Mail-225--312101824-- From jpv@cisco.com Mon Mar 14 08:49:14 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 872B33A6D60 for ; Mon, 14 Mar 2011 08:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.521 X-Spam-Level: X-Spam-Status: No, score=-110.521 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bty+ras8XrdX for ; Mon, 14 Mar 2011 08:49:13 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 6F87A3A6971 for ; Mon, 14 Mar 2011 08:49:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=11213; q=dns/txt; s=iport; t=1300117835; x=1301327435; h=from:mime-version:subject:date:references:cc:to: message-id; bh=FbDd6GOTFQ3AQvvjhizCnLumspNgcVfTnHlJljdNVuM=; b=jqpn7Mewhnzq1vKNw1oQ6OnR67BRvVFrTcm4egqAdF2aQZGhdNoBKbcl 1HQYVDEBsdj/GLFD+JlEa652GL498YjAxiw2fgnnwO3Ic36wO0YS+yM5G OtOb4lXgoxYUTJ4hk/r5146YRBkdPszWgb7ijZW/inZTaaQ2ZdgamyFsr 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIAAH7WfU2Q/khNgWdsb2JhbACYRI1FFAEBFiYlpBmbeYViBIxSg04G X-IronPort-AV: E=Sophos;i="4.62,316,1297036800"; d="scan'208,217";a="21643607" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 14 Mar 2011 15:50:34 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2EFoWFc029240 for ; Mon, 14 Mar 2011 15:50:33 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); Mon, 14 Mar 2011 23:50:32 +0800 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 23:50:31 +0800 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-226--311918106 Date: Mon, 14 Mar 2011 16:50:28 +0100 References: <6A2A459175DABE4BB11DE2026AA50A5D041A1631@XMB-AMS-107.cisco.com> To: ROLL WG Message-Id: <51C91B31-BE6B-4A4A-8CB2-12B691416073@cisco.com> X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 14 Mar 2011 15:50:31.0296 (UTC) FILETIME=[8C3FE800:01CBE25F] Subject: [Roll] *One week Working Last Call - Fwd: a status for draft-ietf-roll-of0 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 15:49:14 -0000 --Apple-Mail-226--311918106 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear Working Group, Since some of changes took place at the very last minute, I would like = to start another WG Last Call on the revision 07 of draft-ietf-roll-of0 that end on March 21 at noon ET. = Please send your comments to the Author and copy the mailing list. Thanks. JP. Begin forwarded message: > From: "Pascal Thubert (pthubert)" > Date: March 14, 2011 11:15:22 AM GMT+01:00 > To: "Adrian Farrel" , = > Cc: "ROLL WG" > Subject: [Roll] a status for draft-ietf-roll-of0 >=20 > Hi Adrian and all: >=20 > Here's a quick summary on the latest activity on OF0 draft. OF0-05 = passed last call but has pending issues. >=20 > 06 addresses: > - issues with the range of the step of Rank and the number of hops in = the worst case scenario. > - issues with the recommendation WRT wireless links >=20 > Thanks to Om and Phil's quick TAT this weekend, I could publish an 07 = back to back with the 06. 07 additionally addresses: >=20 > - lack of clarity that the backup next_hop is not necessary a parent > - lack of clarity on what paying attention to Rank stability could = mean. >=20 > Now we need to review the changes in 06 and 07 and see if they address = the open issues properly. In particular: >=20 > - To compensate the smaller range for the step of rank, a new factor = was added. The factor has a default of 1. Maybe we should recommend a = different default for wired-powered (say 1) wireless or battery (say 2 = or 3) and wireless and battery (say 4 or 5). Since this is a parameter, = it is always possible for a deployment to override the defaults to get = more hops, still up to 256 best case and 28 worst case, but that = proposal would yield by default only 5 to 7 hops that combine wireless = and battery and worst case link properties. >=20 >=20 > Also: > - OF0 still mentions siblings that are not discussed anymore in the = main spec. The question is what to do with them in this spec. We could = on paper: > 1) remove the notion of sibling and the rank stretch that goes with = it altogether. That might be touchy since the text made last call, and I = can't discuss that aspect. > 2) keep the text. But then we probably need to provide a minimum = guidance for loop avoidance (e.g. unless further guidance, do not = forward to a sibling a packet from a leaf or a sibling). >=20 > I think I did all the editorial work I could and I need guidance to = move forward. >=20 > What do you think? >=20 > Pascal > http://www.xtranormal.com/watch/7011357/ >=20 >=20 > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Monday, March 14, 2011 10:37 AM > To: Pascal Thubert (pthubert) > Subject: New Version Notification for draft-ietf-roll-of0-07 >=20 >=20 > A new version of I-D, draft-ietf-roll-of0-07.txt has been successfully = submitted by Pascal Thubert and posted to the IETF repository. >=20 > Filename: draft-ietf-roll-of0 > Revision: 07 > Title: RPL Objective Function 0 > Creation_date: 2011-03-14 > WG ID: roll > Number_of_pages: 10 >=20 > Abstract: > The Routing Protocol for Low Power and Lossy Networks (RPL) defines a = generic Distance Vector protocol for Low Power and Lossy Networks = (LLNs). RPL is instantiated to honor a particular routing objective/ = constraint by the adding a specific Objective Function (OF) that is = designed to solve that problem. This specification defines a basic OF, = OF0, that uses only the abstract properties exposed in RPL messages with = no metric container. > = =20 >=20 >=20 > The IETF Secretariat. >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 --Apple-Mail-226--311918106 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Dear = Working Group,

Since some of changes took place at = the very last minute, I would like to start another WG Last Call on = the
revision 07 of draft-ietf-roll-of0 that end on March = 21 at noon ET. Please send your comments to the Author
and = copy the mailing = list.

Thanks.

JP.

Begin forwarded message:

From: "Pascal Thubert = (pthubert)" <pthubert@cisco.com>
Date: March 14, 2011 = 11:15:22 AM GMT+01:00
Cc: "ROLL WG" <roll@ietf.org>
Subject: [Roll] a status = for draft-ietf-roll-of0

Hi Adrian = and all:

Here's a quick summary on the latest activity on OF0 draft. OF0-05 = passed last call but has pending issues.

06 addresses:
- issues with the range of the step of Rank and the number of hops in = the worst case scenario.
- issues with the recommendation WRT wireless links

Thanks to Om and Phil's quick TAT this weekend, I could publish an 07 = back to back with the 06. 07 additionally addresses:

- lack of clarity that the backup next_hop is not necessary a parent
- lack of clarity on what paying attention to Rank stability could = mean.

Now we need to review the changes in 06 and 07 and see if they address = the open issues properly. In particular:

- To compensate the smaller range for the step of rank, a new factor was = added. The factor has a default of 1. Maybe we should recommend a = different default for wired-powered (say 1) wireless or battery (say 2 = or 3) and wireless and battery (say 4 or 5). Since this is a parameter, = it is always possible for a deployment to override the defaults to get = more hops, still up to 256 best case and 28 worst case, but that = proposal would yield by default only 5 to 7 hops that combine wireless = and battery and worst case link  properties.


Also:
- OF0 still mentions siblings that are not discussed anymore in the main = spec. The question is what to do with them in this spec. We could on = paper:
1)  remove the notion of sibling and the rank stretch that goes = with it altogether. That might be touchy since the text made last call, = and I can't discuss that aspect.
2)  keep the text. But then we probably need to provide a minimum = guidance for loop avoidance (e.g. unless further guidance, do not = forward to a sibling a packet from a leaf or a sibling).

I think I did all the editorial work I could and I need guidance to move = forward.

What do you think?

Pascal
http://www.xtranormal.co= m/watch/7011357/


-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Monday, March 14, 2011 10:37 AM
To: Pascal Thubert (pthubert)
Subject: New Version Notification for draft-ietf-roll-of0-07


A new version of I-D, draft-ietf-roll-of0-07.txt has been successfully = submitted by Pascal Thubert and posted to the IETF repository.

Filename:        = draft-ietf-roll-of0
Revision:        07
Title:           RPL = Objective Function 0
Creation_date:   2011-03-14
WG ID:           roll
Number_of_pages: 10

Abstract:
The Routing Protocol for Low Power and Lossy Networks (RPL) defines a = generic Distance Vector protocol for Low Power and Lossy Networks = (LLNs).  RPL is instantiated to honor a particular routing = objective/ constraint by the adding a specific Objective Function (OF) = that is designed to solve that problem.  This specification defines = a basic OF, OF0, that uses only the abstract properties exposed in RPL = messages with no metric container.
=             &n= bsp;           &nbs= p;            =             &n= bsp;           &nbs= p;            =        


The IETF Secretariat.


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


= --Apple-Mail-226--311918106-- From pthubert@cisco.com Mon Mar 14 09:01:52 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1BB33A6E3C for ; Mon, 14 Mar 2011 09:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.498 X-Spam-Level: X-Spam-Status: No, score=-10.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xOhKLUBhvN68 for ; Mon, 14 Mar 2011 09:01:50 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id D18373A6DA7 for ; Mon, 14 Mar 2011 09:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=14048; q=dns/txt; s=iport; t=1300118589; x=1301328189; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=iyN5R5ciuPjG1+voBDJNFQZSWKks3Qgt2zXXpe++QCc=; b=Y5BaA9Oc1X0wtbMRPHTR6ejkIALW8T0fIRxLMFVem+6kn0WmiWHJ0Ur3 i7yO1EC3T83li2H0X4+R5wdglc0zKouehDKxfV9QN3y0UwlL4ldGLsFWw r1a7Fw169WncTzM4CTXjrBhmNDNpJ4S+AYIjKZzBu5vGC3n+auh20mDIz A=; X-IronPort-AV: E=Sophos;i="4.62,316,1297036800"; d="scan'208,217";a="21645516" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 14 Mar 2011 16:03:09 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2EG39U5014431; Mon, 14 Mar 2011 16:03:09 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Mar 2011 17:03:08 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE261.4FBCBC47" Date: Mon, 14 Mar 2011 17:03:03 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D041A188F@XMB-AMS-107.cisco.com> In-Reply-To: <210F1CBE-ACA0-4B68-8F22-C6AAB1081EAE@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] a status for draft-ietf-roll-of0 Thread-Index: AcviXyPMSQx03ucDSc2IzYng7DI0OwAAd8QA References: <6A2A459175DABE4BB11DE2026AA50A5D041A1631@XMB-AMS-107.cisco.com> <210F1CBE-ACA0-4B68-8F22-C6AAB1081EAE@cisco.com> From: "Pascal Thubert (pthubert)" To: "JP Vasseur" X-OriginalArrivalTime: 14 Mar 2011 16:03:08.0893 (UTC) FILETIME=[4FD008D0:01CBE261] Cc: ROLL WG , Adrian Farrel , roll-chairs@tools.ietf.org Subject: Re: [Roll] a status for draft-ietf-roll-of0 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 16:01:52 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE261.4FBCBC47 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi JP =20 My memory is that there was no agreement, so the shepherd made the decision. That decision applies to the main RPL spec. OF0 is a different beast so it is fair IMHO to ask the question again.=20 =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: JP Vasseur [mailto:jpv@cisco.com]=20 Sent: Monday, March 14, 2011 4:47 PM To: Pascal Thubert (pthubert) Cc: Adrian Farrel; roll-chairs@tools.ietf.org; ROLL WG Subject: Re: [Roll] a status for draft-ietf-roll-of0 =20 Hi Pascal, =20 Thanks for this summary. =20 See in line, =20 On Mar 14, 2011, at 11:15 AM, Pascal Thubert (pthubert) wrote: Hi Adrian and all: Here's a quick summary on the latest activity on OF0 draft. OF0-05 passed last call but has pending issues. 06 addresses: - issues with the range of the step of Rank and the number of hops in the worst case scenario. - issues with the recommendation WRT wireless links Thanks to Om and Phil's quick TAT this weekend, I could publish an 07 back to back with the 06. 07 additionally addresses: - lack of clarity that the backup next_hop is not necessary a parent - lack of clarity on what paying attention to Rank stability could mean. Now we need to review the changes in 06 and 07 and see if they address the open issues properly. In particular: - To compensate the smaller range for the step of rank, a new factor was added. The factor has a default of 1. Maybe we should recommend a different default for wired-powered (say 1) wireless or battery (say 2 or 3) and wireless and battery (say 4 or 5). Since this is a parameter, it is always possible for a deployment to override the defaults to get more hops, still up to 256 best case and 28 worst case, but that proposal would yield by default only 5 to 7 hops that combine wireless and battery and worst case link properties. Also: - OF0 still mentions siblings that are not discussed anymore in the main spec. The question is what to do with them in this spec. We could on paper: 1) remove the notion of sibling and the rank stretch that goes with it altogether. That might be touchy since the text made last call, and I can't discuss that aspect. 2) keep the text. But then we probably need to provide a minimum guidance for loop avoidance (e.g. unless further guidance, do not forward to a sibling a packet from a leaf or a sibling). I think I did all the editorial work I could and I need guidance to move forward. What do you think? I would vote for 1) since there was an agreement do remove the notion of siblings from the core specification. =20 Thanks. =20 JP. Pascal http://www.xtranormal.com/watch/7011357/ =09 =09 -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] Sent: Monday, March 14, 2011 10:37 AM To: Pascal Thubert (pthubert) Subject: New Version Notification for draft-ietf-roll-of0-07 =09 =09 A new version of I-D, draft-ietf-roll-of0-07.txt has been successfully submitted by Pascal Thubert and posted to the IETF repository. =09 Filename: draft-ietf-roll-of0 Revision: 07 Title: RPL Objective Function 0 Creation_date: 2011-03-14 WG ID: roll Number_of_pages: 10 =09 Abstract: The Routing Protocol for Low Power and Lossy Networks (RPL) defines a generic Distance Vector protocol for Low Power and Lossy Networks (LLNs). RPL is instantiated to honor a particular routing objective/ constraint by the adding a specific Objective Function (OF) that is designed to solve that problem. This specification defines a basic OF, OF0, that uses only the abstract properties exposed in RPL messages with no metric container. =09 =09 =09 The IETF Secretariat. =09 =09 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CBE261.4FBCBC47 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi JP

 

My memory is that there was no agreement, so the shepherd made the = decision. That decision applies to the main RPL = spec.

OF0 is a different beast so it is fair IMHO to ask the question = again.

 

 

From:= = JP Vasseur [mailto:jpv@cisco.com]
Sent: Monday, March 14, = 2011 4:47 PM
To: Pascal Thubert (pthubert)
Cc: = Adrian Farrel; roll-chairs@tools.ietf.org; ROLL WG
Subject: = Re: [Roll] a status for = draft-ietf-roll-of0

 

Hi = Pascal,

 

Thanks for this summary.

 

See in line,

 

On = Mar 14, 2011, at 11:15 AM, Pascal Thubert (pthubert) = wrote:



Hi = Adrian and all:

Here's a quick summary on the latest activity on = OF0 draft. OF0-05 passed last call but has pending issues.

06 = addresses:
- issues with the range of the step of Rank and the number = of hops in the worst case scenario.
- issues with the recommendation = WRT wireless links

Thanks to Om and Phil's quick TAT this = weekend, I could publish an 07 back to back with the 06. 07 additionally = addresses:

- lack of clarity that the backup next_hop is not = necessary a parent
- lack of clarity on what paying attention to Rank = stability could mean.

Now we need to review the changes in 06 and = 07 and see if they address the open issues properly. In = particular:

- To compensate the smaller range for the step of = rank, a new factor was added. The factor has a default of 1. Maybe we = should recommend a different default for wired-powered (say 1) wireless = or battery (say 2 or 3) and wireless and battery (say 4 or 5). Since = this is a parameter, it is always possible for a deployment to override = the defaults to get more hops, still up to 256 best case and 28 worst = case, but that proposal would yield by default only 5 to 7 hops that = combine wireless and battery and worst case link  = properties.


Also:
- OF0 still mentions siblings that are = not discussed anymore in the main spec. The question is what to do with = them in this spec. We could on paper:
1)  remove the notion of = sibling and the rank stretch that goes with it altogether. That might be = touchy since the text made last call, and I can't discuss that = aspect.
2)  keep the text. But then we probably need to provide = a minimum guidance for loop avoidance (e.g. unless further guidance, do = not forward to a sibling a packet from a leaf or a sibling).

I = think I did all the editorial work I could and I need guidance to move = forward.

What do you think?

I would vote for 1) since there was an agreement do = remove the notion of siblings from the core = specification.

 

Thanks.

 

JP.

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


-----Original Message-----
From: = IETF I-D Submission Tool [mailto:idsubmission@ietf.org]Sent: Monday, March 14, 2011 10:37 AM
To: Pascal Thubert = (pthubert)
Subject: New Version Notification for = draft-ietf-roll-of0-07


A new version of I-D, = draft-ietf-roll-of0-07.txt has been successfully submitted by Pascal = Thubert and posted to the IETF = repository.

Filename:        = draft-ietf-roll-of0
Revision:       = ; 07
Title:           = RPL Objective Function 0
Creation_date:   2011-03-14
WG = ID:           = roll
Number_of_pages: 10

Abstract:
The Routing Protocol for = Low Power and Lossy Networks (RPL) defines a generic Distance Vector = protocol for Low Power and Lossy Networks (LLNs).  RPL is = instantiated to honor a particular routing objective/ constraint by the = adding a specific Objective Function (OF) that is designed to solve that = problem.  This specification defines a basic OF, OF0, that uses = only the abstract properties exposed in RPL messages with no metric = container.
          = ;            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;          

The IETF = Secretariat.


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

<= p class=3DMsoNormal> 

------_=_NextPart_001_01CBE261.4FBCBC47-- From Internet-Drafts@ietf.org Mon Mar 14 11:30:02 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DF5A3A6A4A; Mon, 14 Mar 2011 11:30:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.576 X-Spam-Level: X-Spam-Status: No, score=-102.576 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OiG3MaNxc2wL; Mon, 14 Mar 2011 11:30:01 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A541D3A6A03; Mon, 14 Mar 2011 11:30:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110314183001.6103.4783.idtracker@localhost> Date: Mon, 14 Mar 2011 11:30:01 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-rpl-19.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 18:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : RPL: IPv6 Routing Protocol for Low power and Lossy Networks Author(s) : T. Winter, et al. Filename : draft-ietf-roll-rpl-19.txt Pages : 163 Date : 2011-03-14 Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained. LLN routers typically operate with constraints on processing power, memory, and energy (battery power). Their interconnects are characterized by high loss rates, low data rates, and instability. LLNs are comprised of anything from a few dozen and up to thousands of routers. Supported traffic flows include point-to-point (between devices inside the LLN), point-to-multipoint (from a central control point to a subset of devices inside the LLN), and multipoint-to-point (from devices inside the LLN towards a central control point). This document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point, as well as point-to- multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-rpl-19.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-rpl-19.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-14112155.I-D@ietf.org> --NextPart-- From pal@cs.stanford.edu Tue Mar 15 18:51:41 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FC243A6976 for ; Tue, 15 Mar 2011 18:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5b-639feokCp for ; Tue, 15 Mar 2011 18:51:39 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id BEB8F3A6A7E for ; Tue, 15 Mar 2011 18:51:39 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Pzfv5-00062R-8O; Tue, 15 Mar 2011 18:53:05 -0700 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1082) From: Philip Levis In-Reply-To: <20110314094501.1366.59375.idtracker@localhost> Date: Tue, 15 Mar 2011 18:53:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20110314094501.1366.59375.idtracker@localhost> To: ROLL WG , "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1082) X-Scan-Signature: b18bfb97b6ee282caf2c82162b965e52 Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 01:51:41 -0000 On Mar 14, 2011, at 2:45 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Routing Over Low power and Lossy = networks Working Group of the IETF. >=20 >=20 > Title : RPL Objective Function 0 > Author(s) : P. Thubert > Filename : draft-ietf-roll-of0-07.txt > Pages : 10 > Date : 2011-03-14 >=20 > The Routing Protocol for Low Power and Lossy Networks (RPL) defines a > generic Distance Vector protocol for Low Power and Lossy Networks > (LLNs). RPL is instantiated to honor a particular routing objective/ > constraint by the adding a specific Objective Function (OF) that is > designed to solve that problem. This specification defines a basic > OF, OF0, that uses only the abstract properties exposed in RPL > messages with no metric container. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-07.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ Comments and suggested edits on OF0-07 follow. Because of the very short = timeframe I am including concrete edits rather than general = recommendations. My general read is that the core ideas of OF0 are sound = but its current text is very much out of date with how RPL works: it has = many holdovers from older specifications of RPL, such as siblings and = how Rank is computed. Correspondingly it is very confusing and = inconsistent with the core protocol. It also contradicts general = practice in LLN routing, at least as far as I am aware of it. My edits = try to fix this, as well as clean up a range of grammatical issues. Abstract: =20 "RPL is instantiated to honor a particular routing objective/constraint = by the adding a specific Objective Function (OF) that is designed to = solve that problem. " should become "A RPL instance specifies an Objective Function (OF) that defines how = nodes in the instance compute distance and select routes." Reason: "honor" is inaccurate, that suggests one could not follow it. It = is not clear what "problem" the sentence refers to. "by the adding" is = grammatically incorrect. I think the new sentence more clearly and = accurately says what the existing one is trying to. ---- Introduction edit 1: "Considering the wide variety of use cases, link types and metrics, the Routing Protocol for Low Power and Lossy Networks [I-D.ietf-roll-rpl] was designed as a generic core that is agnostic to metrics and instantiated using Objective Functions. RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) within instances of the protocol, each instance being set up to honor a particular routing objective/constraint of a given deployment. This instantiation is achieved by plugging into the RPL core a specific Objective Function (OF) that is designed to solve that problem to be addressed by that instance." should become "Considering the wide variety of use cases, link types and metrics, the Routing Protocol for Low Power and Lossy Networks [I-D.ietf-roll-rpl] was designed as a generic core that is agnostic to metrics. Each RPL instance specifies an Objective Function which nodes in that instance use to compute and select routes. This = separation of Objective Functions from the core protocol specification allows = RPL to adapt to meet the different optimization criteria the wide range = of use cases requires." Reason: The second paragraph in the original version is confused: it = suggests that one instantiates RPL by giving it an Objective Function. = This is not true. Tries to explain the reason for the separation, rather = than how it's used. Introduction edit 2: "An Objective Function selects the DODAG version that a device joins, and a number of neighbor routers within that version as parents and siblings. The OF is also responsible for computing the Rank of the device, that abstracts a relative position within the DODAG and is used by the RPL core to enable a degree of loop avoidance and verify forward progression towards a destination, as specified in [I-D.ietf-roll-rpl]." should become "A RPL instance forms Destination Oriented Directed Acyclic Graphs = (DODAGs). An Objective Function selects the DODAG that a device joins, the neighbor routers within that DODAG that the device maintains state on, and which neighbors the device selects as parents towards the root of the DODAG. The OF is also responsible for computing the = Rank of the device, an abstract distance from the DODAG root." Reason: There is no reason to talk about loop avoidance and datapath = validation here. Siblings are no longer a primitive in RPL, the rewrite = makes the above description accurately reflect the text in DIO = processing in -19. Introduction edit 3: Cut the paragraph: =20 "Indeed, it is the general design in RPL that the metrics are passed from parent to children in a specific container and that the OF will derive the Rank from the natural metric. The separation of Rank and metrics avoids a loss of information as the various metrics are propagated down the DAG. This specification can be used when the link properties that are considered are such that they can be turned in a scalar step of Rank in a reversible fashion and the resulting step of rank is additive over multiple hops." Reason: this is unnecessary detail and just a restatement of RPL and = makes this draft confusing, because it's describing a property of RPL = that the draft does not use. Introduction edit 4: "OF0 does not leverage metric containers such as described in the metrics draft [I-D.ietf-roll-routing-metrics]. OF0 does not require information in the RPL messages but the abstract information from the DIO base container, such as Rank and an administrative preference, that is transported in DIOs as DODAGPreference in [I-D.ietf-roll-rpl]." should become "OF0 does not use RPL metric containers[I-D.ietf-roll-routing-metrics] = and ignores them. OF0 only requires the information in the DIO base container, such as Rank = and the DODAGPreference field that describes an administrative = preference[I-D.ietf-roll-rpl]." Reason: The DODAGPreference is not transported in the draft; it's = transported in a DIO Base container. It's better to say what OF0 = requires, rather than what it doesn't require, as the latter is = imprecise and open to interpretation (e.g. one could claim it needs = information in a DIS). ------ Goal edit 1: 3. Goal should become 3. Objective Function 0 Overview Reason: This section is not just about goals, it is about how OF 0 = works. Goal edit 2: "The metric used in OF0 can be an administratively defined scalar = cost that is trivially added up along a path to compute the RPL Rank, as defined in [I-D.ietf-roll-rpl]. Depending on how the step of Rank is computed by an implementation, the Rank of a node might be analogous to a weighted hop count of the path to the root. Using a metric that in essence is similar to hop count implies that the quality of the connectivity should be asserted so that only neighbors with a good enough connectivity are presented to the OF. How that connectivity is asserted and maintained is not covered by this specification. In wireless networks, Hop Count will tend to favor paths with long distance links and non optimal connectivity properties. In some situations, this might end up partitioning the network. As a result, the link selection must be very conservative, and the available link set is thus constrained. For those reasons, though it can be used on wired links and wired link emulations such as WIFI infrastructure mode, a metric derived from hop count is generally not recommended for wireless networks. Instead, careful thinking should be applied to determine how the step of Rank is computed from the link properties. For instance, the Minimum Rank Objective Function with Hysteresis [I-D.ietf-roll-minrank-hysteresis-of] provides guidance on how hysteresis can be used to maintain a certain stability of the resulting Rank." should become "OF0 computes Rank as a simple scalar cost that nodes add up along a path. OF0 assigns a cost to each link to another node that it monitors and computes Rank as the Rank of the other node plus the cost of the link. The exact method for computing link cost is implementation-dependent. One trivial OF0 implementation might compute the Rank as a weighted hop count where some links cost more than one hop. =20 Using a metric similar to hop count implies that the OF0 = implementation only considers neighbors with good enough connectivity, especially in wireless networks. In wireless networks, an unweighted hop count favors paths with long distance links and poor connectivity = properties[De Couto]. Wireless networks using OF0 should carefully compute the step of Rank from link properties to avoid this problem. For instance, the = Minimum=20 Rank Objective Function with Hysteresis = [I-D.ietf-roll-minrank-hysteresis-of]=20 provides guidance on how link cost can be computed and hysteresis can = improve Rank stability." Here's the reference: [De Couto] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and = Robert Morris, A High-Throughput Path Metric for Multi-Hop Wireless = Routing, Proceedings of the 9th ACM International Conference on Mobile = Computing and Networking (MobiCom =9103), San Diego, California, = September 2003. Reason: The current text suggests hopcount as a mechanism, but then says = that it's not advised for wireless networks. But this is not quite = correct: OF0 uses a link weighting, which means it could work fine as = long as you weight the links properly. The reference to MRHOF is also a = non-sequitor: it jumps from cost computation to route selection = hysteresis. Instead, MRHOF is relevant here because it talks about ways = to compute Rank steps. The comment about WiFi should be removed because, = well, it is wireless. Goal edit 3: All text in 3 after=20 "A node MAY stretch its step of Rank by up to MAXIMUM_RANK_STRETCH in order to enable the selection of a sibling when only one parent is available. For instance, say that a node computes a step of Rank of 4 units of MINIMUM_RANK_INCREMENT from a preferred parent with a Rank of 6 units resulting in a Rank of 10 units for this node. Say that with that Rank of 10 units, this node would end up with only one parent and no sibling, though there is a neighbor with a Rank of 12 units. In that case, the node is entitled to stretch its step of Rank by a value of 2 units, thus using a step of Rank of 6 units so as to reach a Rank of 12 units and find a sibling. But the node is not entitled to use a step of Rank larger than 6 units since that would be a greedy behavior that would deprive the neighbor of this node of a successor. Also, if the neighbor had exposed a Rank of 16 units, the stretch of Rank from 10 to 16 units would have exceeded MAXIMUM_RANK_STRETCH of 5 units and thus the neighbor would not have been selectable even as a sibling...." should become "The core RPL specification describes constraints on how nodes select potential parents, called a parent set, from their neighbors.=20 OF0 selects a parent set trying to balance three needs. The first is that the route through its preferred parent has as low a Rank as possible. The second is that it has multiple elements in its parent set. The third is that the Rank it sets for the node is not much higher than the Rank associated with the route through its preferred parent. Generally, the first two are more important than the third: advertising a high Rank in order to maintain some path diversity is better than advertising a lower Rank but being unable to route when the corresponding link fails. OF0 has a parameter, MAXIMUM_RANK_STRETCH, which defines the maximum stretch between the associated Rank of members of its parent set. If the Rank associated with a route through a node's preferred parent = is R, then the node MUST NOT advertise a Rank greater than=20 R + MAXIMUM_RANK_STRETCH. OF0 has two rules when selecting the DODAG Version of its parent set. First, OF0 MUST select a parent set from a DODAG Version that has the highest administrative preference among the DODAG Versions it is = aware=20 of. Among the DODAGs with this highest administrative preference = value, OF0 MUST select a Grounded DODAG if one is available." Reason: the current text talks about stretching Rank to reach siblings = without first saying how Rank is computed. Siblings are no longer a = concept in RPL. The concepts are neighbor set, parent set, and preferred = parent. The edit clearly states how preferred parents are selected, the = parent set is selected, etc. The statements about Grounded and = administrative preference are not normative, yet should be. The rule on = MAXIMUM_RANK_STRETCH is now defined properly in line with how parent = sets affect DIO processing. Goal edit 4: Remove section 4: it contradicts itself several times. For example, 6 = says that one SHOULD use a newer DODAG Version; 9 says that one SHOULD = use the existing DODAG Version. Furthermore, it is not clear that the = actual order specified is the right one (it is not based on any existing = implementations). Rule 4 is subsumed in the Goal edit 3 text, as is rule = 5. Rule 7 (minimize Rank) will cause route flapping because it comes = before rule 10 (keep existing preferred parent). Goal edit 5: Remove section 5: the abstraction of a parent set in the RPL core = specification removes the need for a backup next hop: every element of = the parent set is a backup next hop. This section could be rewritten to = reflect a parent set, but Goal edit 3 addresses this somewhat. If you think section 4 and 5 should stay, I can try a rewrite that would = make them consistent with the DIO processing rules in -19 as well as not = contradictory and applicable to wireless networks. Phil =20 From c.chauvenet@watteco.com Wed Mar 16 02:41:21 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA573A68DE for ; Wed, 16 Mar 2011 02:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.831 X-Spam-Level: X-Spam-Status: No, score=-4.831 tagged_above=-999 required=5 tests=[AWL=1.767, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTOmM3YfTv6w for ; Wed, 16 Mar 2011 02:41:15 -0700 (PDT) Received: from VA3EHSOBE006.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by core3.amsl.com (Postfix) with ESMTP id AADC13A68F0 for ; Wed, 16 Mar 2011 02:41:12 -0700 (PDT) Received: from mail42-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.8; Wed, 16 Mar 2011 09:42:34 +0000 Received: from mail42-va3 (localhost.localdomain [127.0.0.1]) by mail42-va3-R.bigfish.com (Postfix) with ESMTP id 8AEB51A302F7 for ; Wed, 16 Mar 2011 09:42:34 +0000 (UTC) X-SpamScore: -9 X-BigFish: VPS-9(zzbb2cK14ffOzz1202hz31iz8275bh8275dhz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB023.red002.local; RD:none; EFVD:NLI Received: from mail42-va3 (localhost.localdomain [127.0.0.1]) by mail42-va3 (MessageSwitch) id 1300268546778601_774; Wed, 16 Mar 2011 09:42:26 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.243]) by mail42-va3.bigfish.com (Postfix) with ESMTP id B489911D804C for ; Wed, 16 Mar 2011 09:42:26 +0000 (UTC) Received: from IE2RD2HUB023.red002.local (213.199.187.153) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.1.225.8; Wed, 16 Mar 2011 09:42:23 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB023.red002.local ([10.43.198.101]) with mapi; Wed, 16 Mar 2011 02:42:14 -0700 From: C Chauvenet To: "'roll@ietf.org'" Date: Wed, 16 Mar 2011 02:39:19 -0700 Thread-Topic: I flag inconsistency in rpl-metrics-19 ? Thread-Index: Acvjvel74ULcY3YaQrWTlerBMyJl4g== Message-ID: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A716FIE2RD2XVS211r_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Subject: [Roll] I flag inconsistency in rpl-metrics-19 ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 09:41:21 -0000 --_000_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A716FIE2RD2XVS211r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, Reading the routing-metrics-19 draft I noticed something odd about the I fl= ag in the NE and the LC sub-Object : In the NE sub Object (Section 3.2) : " I (Included): the I bit is only rele= vant when the node type is used as a constraint. [...]. When set, this indicates that nodes of the typ= e specified in the node type field MUST be included. Conversely, when cleared, this indicates that nodes of type specified in the node type field MUST be excluded." In the LC object (section 4.4.1) : " I Bit: The I bit is only relevant whe= n the Link Color is used as a constraint. When cleared, this indicates that links with the specified color must be included. When set, this indicates that links with the specified color must be excluded." I guess there an inversion in the latter definition. Furthermore at the end of the section 3.2 : " If the NE object comprises se= veral sub-objects when used as a constraint, each sub-object adds or subtracts node subsets as the sub-objects are parsed in order. The initial set (full or empty) is defined by the I bit of the first sub-object: full if that I bit is an exclusion, empty if that I bit is an inclusion." Behavior of the I flag in this case seems conflitcting with the wording, or= I missed something ? Maybe editors of the document could clarify this. C=E9dric. --_000_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A716FIE2RD2XVS211r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Reading= the routing-metrics-19 draft I noticed something odd about the I flag in t= he NE and the LC sub-Object :

 = ;

In the NE sub= Object (Section 3.2) : " I (Included): the I bit is only relevant when the node type is

used as a constraint. [̷= 0;]. When set, this indicates that nodes of the type

specified in the node type field MUST be= included. Conversely,

when cleared, this indicates that nodes of type specified in th= e

node type field MUST be excluded."=

 

In the LC object (section 4.4.1)  : &= quot; I Bit: The I bit= is only relevant when the Link Color is used as a

constraint. When cleared, this indicates t= hat links with the

specif= ied color must be included. When set, this indicates that

links with the specified color must be excluded.&qu= ot;

 

I = guess there an inversion in the latter definition.

 

Furthermore at the end of the section 3.2 : " If the NE object comprises several s= ub-objects when used as a

constraint, each sub-object adds or subtracts node subsets as the

sub-objects are parsed in order= . The initial set (full or empty) is

defined by the I bit of the first sub-object: full if th= at I bit is

an exclusion, empty if that I= bit is an inclusion."

 

Behavior of the I flag in this case seems conf= litcting with the wording, or I missed something ?

 

Maybe editors of the= document could clarify this.

 = ;

Cédric.

 

= --_000_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A716FIE2RD2XVS211r_-- From pthubert@cisco.com Wed Mar 16 08:10:35 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E94513A6957 for ; Wed, 16 Mar 2011 08:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.203 X-Spam-Level: X-Spam-Status: No, score=-10.203 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFeQhh8eU4Zb for ; Wed, 16 Mar 2011 08:10:33 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id D265E3A6977 for ; Wed, 16 Mar 2011 08:10:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=17843; q=dns/txt; s=iport; t=1300288320; x=1301497920; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=zF26oTR3kmTYjAa4hDHnJEl1fZScOWafOLvxaad1PUQ=; b=dKjn5Ud1M4EUwcmUO3NVEJLioVOYVUgUFmUwNMKIiQfr9D/k8igH9wIt I/pc0pd0honaMwWIZU/c2gzyg0Wcu+lhO8W7lxUjO7EuneaXFMjC6Xs01 83kLr7UdiHlpiJwH6aZy7YOVupHgmdw4hozq2GBH2M+UeEULbZTokSJhD 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwEAB5wgE2Q/khLgWdsb2JhbACmDRQBARYmJaRZnFWFYwSQMYhu X-IronPort-AV: E=Sophos;i="4.63,194,1299456000"; d="scan'208";a="21971484" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 16 Mar 2011 15:11:59 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2GFBwfK023811; Wed, 16 Mar 2011 15:11:58 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2011 16:11:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Mar 2011 16:11:53 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D041A22B7@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-07.txt Thread-Index: AcvjfOxJdY/1lcGaSFSoRFAO+mM+agARc5bA References: <20110314094501.1366.59375.idtracker@localhost> From: "Pascal Thubert (pthubert)" To: "Philip Levis" , "ROLL WG" X-OriginalArrivalTime: 16 Mar 2011 15:11:58.0791 (UTC) FILETIME=[7EB72570:01CBE3EC] Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 15:10:36 -0000 Thanks a lot for all this Phil, [Pascal] Please find some answers below. I'd really appreciate that others comment about this. > > The Routing Protocol for Low Power and Lossy Networks (RPL) defines a > > generic Distance Vector protocol for Low Power and Lossy Networks > > (LLNs). RPL is instantiated to honor a particular routing objective/ > > constraint by the adding a specific Objective Function (OF) that is > > designed to solve that problem. This specification defines a basic > > OF, OF0, that uses only the abstract properties exposed in RPL > > messages with no metric container. > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-07.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ >=20 > Comments and suggested edits on OF0-07 follow. Because of the very short > timeframe I am including concrete edits rather than general > recommendations. My general read is that the core ideas of OF0 are sound > but its current text is very much out of date with how RPL works: it has many > holdovers from older specifications of RPL, such as siblings and how Rank is > computed. Correspondingly it is very confusing and inconsistent with the > core protocol. It also contradicts general practice in LLN routing, at least as far > as I am aware of it. My edits try to fix this, as well as clean up a range of > grammatical issues. >=20 > Abstract: >=20 > "RPL is instantiated to honor a particular routing objective/constraint by the > adding a specific Objective Function (OF) that is designed to solve that > problem. " >=20 > should become >=20 > "A RPL instance specifies an Objective Function (OF) that defines how nodes > in the instance compute distance and select routes." [Pascal]=20 The term instantiated here refers to the fact that RPL as a protocol has a generic core. To turn it into an runnable protocol, it has to be instantiated by adding and OF. The result is a protocol. Your words are correct but refer to a different thing. A RPL instance is a runtime construct. There is no need to redefine it here. >=20 > Reason: "honor" is inaccurate, that suggests one could not follow it. It is not > clear what "problem" the sentence refers to. "by the adding" is > grammatically incorrect. I think the new sentence more clearly and accurately > says what the existing one is trying to. =20 [Pascal] the grammar will be fixed by the RFC editor. Maybe achieve would be better than honor? > ---- >=20 > Introduction edit 1: >=20 > "Considering the wide variety of use cases, link types and metrics, > the Routing Protocol for Low Power and Lossy Networks > [I-D.ietf-roll-rpl] was designed as a generic core that is agnostic > to metrics and instantiated using Objective Functions. >=20 > RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) > within instances of the protocol, each instance being set up to honor > a particular routing objective/constraint of a given deployment. > This instantiation is achieved by plugging into the RPL core a > specific Objective Function (OF) that is designed to solve that > problem to be addressed by that instance." >=20 > should become >=20 > "Considering the wide variety of use cases, link types and metrics, > the Routing Protocol for Low Power and Lossy Networks > [I-D.ietf-roll-rpl] was designed as a generic core that is agnostic > to metrics. Each RPL instance specifies an Objective Function which > nodes in that instance use to compute and select routes. This separation > of Objective Functions from the core protocol specification allows RPL > to adapt to meet the different optimization criteria the wide range of > use cases requires." >=20 > Reason: The second paragraph in the original version is confused: it suggests > that one instantiates RPL by giving it an Objective Function. This is not true. [Pascal] Well yes it is true. But we are referring to different things. > Tries to explain the reason for the separation, rather than how it's used. [Pascal] I like your last sentence though. > Introduction edit 2: >=20 >=20 > "An Objective Function selects the DODAG version that a device joins, > and a number of neighbor routers within that version as parents and > siblings. The OF is also responsible for computing the Rank of the > device, that abstracts a relative position within the DODAG and is > used by the RPL core to enable a degree of loop avoidance and verify > forward progression towards a destination, as specified in > [I-D.ietf-roll-rpl]." >=20 > should become >=20 > "A RPL instance forms Destination Oriented Directed Acyclic Graphs > (DODAGs). > An Objective Function selects the DODAG that a device joins, > the neighbor routers within that DODAG that the device maintains > state on, and which neighbors the device selects as parents towards > the root of the DODAG. The OF is also responsible for computing the Rank > of the > device, an abstract distance from the DODAG root." >=20 > Reason: There is no reason to talk about loop avoidance and datapath > validation here. Siblings are no longer a primitive in RPL, the rewrite makes > the above description accurately reflect the text in DIO processing in -19. [Pascal] I suggest we discuss the sibling separately, see if the resolution is to introduce them in this spec or remove all that's related to sibling. This being said, I can agree that we do not need to define Rank anymore that we need to define RPL Instance. I'm fine with the removal though the existing text does not hurt IMHO. >=20 > Introduction edit 3: >=20 > Cut the paragraph: >=20 > "Indeed, it is the general design in RPL that the metrics are passed > from parent to children in a specific container and that the OF will > derive the Rank from the natural metric. The separation of Rank and > metrics avoids a loss of information as the various metrics are > propagated down the DAG. This specification can be used when the > link properties that are considered are such that they can be turned > in a scalar step of Rank in a reversible fashion and the resulting > step of rank is additive over multiple hops." >=20 > Reason: this is unnecessary detail and just a restatement of RPL and makes > this draft confusing, because it's describing a property of RPL that the draft > does not use. [Pascal] this paragraph was added to clear things up based on your comments (and Om's) I could remove the first half though again I do not see any arm in it. The second half " This specification can be used ... " seems a bit more important unless you consider that all metrics can be turned into an additive step of rank? >=20 > Introduction edit 4: >=20 > "OF0 does not leverage metric containers such as > described in the metrics draft [I-D.ietf-roll-routing-metrics]. OF0 > does not require information in the RPL messages but the abstract > information from the DIO base container, such as Rank and an > administrative preference, that is transported in DIOs as > DODAGPreference in [I-D.ietf-roll-rpl]." >=20 > should become >=20 > "OF0 does not use RPL metric containers[I-D.ietf-roll-routing-metrics] and > ignores them. OF0 > only requires the information in the DIO base container, such as Rank and > the > DODAGPreference field that describes an administrative preference[I- > D.ietf-roll-rpl]." >=20 > Reason: The DODAGPreference is not transported in the draft; it's > transported in a DIO Base container. It's better to say what OF0 requires, > rather than what it doesn't require, as the latter is imprecise and open to > interpretation (e.g. one could claim it needs information in a DIS). >=20 [Pascal] Makes sense to me; I trust that we can push that straight to the RFC editor. > ------ >=20 > Goal edit 1: >=20 > 3. Goal >=20 > should become >=20 > 3. Objective Function 0 Overview >=20 > Reason: This section is not just about goals, it is about how OF 0 works. >=20 [Pascal] OK >=20 > Goal edit 2: >=20 > "The metric used in OF0 can be an administratively defined scalar cost > that is trivially added up along a path to compute the RPL Rank, as > defined in [I-D.ietf-roll-rpl]. Depending on how the step of Rank is > computed by an implementation, the Rank of a node might be analogous > to a weighted hop count of the path to the root. Using a metric that > in essence is similar to hop count implies that the quality of the > connectivity should be asserted so that only neighbors with a good > enough connectivity are presented to the OF. How that connectivity > is asserted and maintained is not covered by this specification. >=20 > In wireless networks, Hop Count will tend to favor paths with long > distance links and non optimal connectivity properties. In some > situations, this might end up partitioning the network. As a result, > the link selection must be very conservative, and the available link > set is thus constrained. For those reasons, though it can be used on > wired links and wired link emulations such as WIFI infrastructure > mode, a metric derived from hop count is generally not recommended > for wireless networks. Instead, careful thinking should be applied > to determine how the step of Rank is computed from the link > properties. For instance, the Minimum Rank Objective Function with > Hysteresis [I-D.ietf-roll-minrank-hysteresis-of] provides guidance on > how hysteresis can be used to maintain a certain stability of the > resulting Rank." >=20 >=20 > should become >=20 > "OF0 computes Rank as a simple scalar cost that nodes add up > along a path. OF0 assigns a cost to each link to another node > that it monitors and computes Rank as the Rank of the other node plus > the cost of the link. The exact method for computing link cost is > implementation-dependent. >=20 > One trivial OF0 implementation might compute the Rank > as a weighted hop count where some links cost more than one hop. > Using a metric similar to hop count implies that the OF0 implementation > only considers neighbors with good enough connectivity, especially > in wireless networks. In wireless networks, an unweighted hop count > favors paths with long distance links and poor connectivity properties[De > Couto]. > Wireless networks using OF0 should carefully compute the step of Rank > from link properties to avoid this problem. For instance, the Minimum > Rank Objective Function with Hysteresis [I-D.ietf-roll-minrank-hysteresis- > of] > provides guidance on how link cost can be computed and hysteresis can > improve > Rank stability." >=20 > Here's the reference: >=20 > [De Couto] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and Robert > Morris, A High-Throughput Path Metric for Multi-Hop Wireless Routing, > Proceedings of the 9th ACM International Conference on Mobile Computing > and Networking (MobiCom '03), San Diego, California, September 2003. >=20 > Reason: The current text suggests hopcount as a mechanism, but then says > that it's not advised for wireless networks. But this is not quite correct: OF0 > uses a link weighting, which means it could work fine as long as you weight > the links properly. The reference to MRHOF is also a non-sequitor: it jumps > from cost computation to route selection hysteresis. Instead, MRHOF is > relevant here because it talks about ways to compute Rank steps. The > comment about WiFi should be removed because, well, it is wireless. >=20 [Pascal] Very good > Goal edit 3: >=20 > All text in 3 after > "A node MAY stretch its step of Rank by up to MAXIMUM_RANK_STRETCH > in > order to enable the selection of a sibling when only one parent is > available. For instance, say that a node computes a step of Rank of > 4 units of MINIMUM_RANK_INCREMENT from a preferred parent with a > Rank > of 6 units resulting in a Rank of 10 units for this node. Say that > with that Rank of 10 units, this node would end up with only one > parent and no sibling, though there is a neighbor with a Rank of 12 > units. In that case, the node is entitled to stretch its step of > Rank by a value of 2 units, thus using a step of Rank of 6 units so > as to reach a Rank of 12 units and find a sibling. But the node is > not entitled to use a step of Rank larger than 6 units since that > would be a greedy behavior that would deprive the neighbor of this > node of a successor. Also, if the neighbor had exposed a Rank of 16 > units, the stretch of Rank from 10 to 16 units would have exceeded > MAXIMUM_RANK_STRETCH of 5 units and thus the neighbor would not > have > been selectable even as a sibling...." >=20 > should become >=20 > "The core RPL specification describes constraints on how nodes select > potential parents, called a parent set, from their neighbors. > OF0 selects a parent set trying to balance three needs. The first is > that the route through its preferred parent has as low a Rank as > possible. The second is that it has multiple elements in its parent > set. The third is that the Rank it sets for the node is not much > higher than the Rank associated with the route through its preferred > parent. Generally, the first two are more important than the third: > advertising a high Rank in order to maintain some path diversity is > better than advertising a lower Rank but being unable to route when > the corresponding link fails. >=20 > OF0 has a parameter, MAXIMUM_RANK_STRETCH, which defines the > maximum > stretch between the associated Rank of members of its parent set. > If the Rank associated with a route through a node's preferred parent is > R, then the node MUST NOT advertise a Rank greater than > R + MAXIMUM_RANK_STRETCH. >=20 > OF0 has two rules when selecting the DODAG Version of its parent set. > First, OF0 MUST select a parent set from a DODAG Version that has the > highest administrative preference among the DODAG Versions it is aware > of. Among the DODAGs with this highest administrative preference value, > OF0 MUST select a Grounded DODAG if one is available." >=20 >=20 : the current text talks about stretching Rank to reach siblings without > first saying how Rank is computed. Siblings are no longer a concept in RPL. > The concepts are neighbor set, parent set, and preferred parent. The edit > clearly states how preferred parents are selected, the parent set is selected, > etc. The statements about Grounded and administrative preference are not > normative, yet should be. The rule on MAXIMUM_RANK_STRETCH is now > defined properly in line with how parent sets affect DIO processing. >=20 [Pascal] Note that the stretch is associated to siblings. It is the stretch between Rank obtained from the preferred parent and a sibling, not the license to go deeper to get an alternate parent, which would be a bit greedy. I expected this text to go down the sink with the sibling text. What you're doing here changes the meaning of stretch considerably. This would be a new behavior and thus a new LC.=20 > Reason > Goal edit 4: >=20 > Remove section 4: it contradicts itself several times. For example, 6 says that > one SHOULD use a newer DODAG Version; 9 says that one SHOULD use the > existing DODAG Version. Furthermore, it is not clear that the actual order > specified is the right one (it is not based on any existing implementations). > Rule 4 is subsumed in the Goal edit 3 text, as is rule 5. Rule 7 (minimize Rank) > will cause route flapping because it comes before rule 10 (keep existing > preferred parent). [Pascal] There is no contradiction. This really boils down to 9 is useless and can be safely removed. Rule 7 would cause flapping if the Rank changes are not dampened. But the spec indicates that they should be. 10 before 7 would lock to a parent forever. Finally this text was reviewed by the group and is normative.=20 So it was implemented by those who implemented OF0. We did not get a feedback that the order was wrong.=20 And since we passed LC, I'm not anxious to make any change there (but remove the useless 9). > Goal edit 5: >=20 > Remove section 5: the abstraction of a parent set in the RPL core > specification removes the need for a backup next hop: every element of the > parent set is a backup next hop. This section could be rewritten to reflect a > parent set, but Goal edit 3 addresses this somewhat. [Pascal] OF0 only requires one backup. But I agree it does not preclude having more. And I agree that alt parents are all possible backups. But I want to insist that a backup is not necessarily a parent. > If you think section 4 and 5 should stay, I can try a rewrite that would make > them consistent with the DIO processing rules in -19 as well as not > contradictory and applicable to wireless networks. [Pascal] I do not think we have choice about that: the sections are normative and should stay consistent to what they were at LC, unless we have an IESG issue. Text improvements that reduce the chances for a misunderstanding within those constraints are welcome. Let's talk in Prague. Cheers, Pascal >=20 >=20 >=20 >=20 >=20 >=20 From pal@cs.stanford.edu Wed Mar 16 09:11:57 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE1643A69C7 for ; Wed, 16 Mar 2011 09:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_102=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUOZhN4QmpN6 for ; Wed, 16 Mar 2011 09:11:55 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 3F0433A69BC for ; Wed, 16 Mar 2011 09:11:55 -0700 (PDT) Received: from dn0a210072.sunet ([10.33.0.114]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1PztLc-0008Si-Tu; Wed, 16 Mar 2011 09:13:22 -0700 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D041A22B7@XMB-AMS-107.cisco.com> Date: Wed, 16 Mar 2011 09:13:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <9F3EA16A-3390-4FEE-9EA3-96018FBB7CF2@cs.stanford.edu> References: <20110314094501.1366.59375.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D041A22B7@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: cc8b4b2d731df8c324856003c7fc5987 Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 16:11:58 -0000 On Mar 16, 2011, at 8:11 AM, Pascal Thubert (pthubert) wrote: > Thanks a lot for all this Phil, >=20 > [Pascal] Please find some answers below. I'd really appreciate that > others comment about this. >=20 >>> The Routing Protocol for Low Power and Lossy Networks (RPL) defines > a >>> generic Distance Vector protocol for Low Power and Lossy Networks >>> (LLNs). RPL is instantiated to honor a particular routing > objective/ >>> constraint by the adding a specific Objective Function (OF) that is >>> designed to solve that problem. This specification defines a basic >>> OF, OF0, that uses only the abstract properties exposed in RPL >>> messages with no metric container. >>>=20 >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-07.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> Comments and suggested edits on OF0-07 follow. Because of the very > short >> timeframe I am including concrete edits rather than general >> recommendations. My general read is that the core ideas of OF0 are > sound >> but its current text is very much out of date with how RPL works: it > has many >> holdovers from older specifications of RPL, such as siblings and how > Rank is >> computed. Correspondingly it is very confusing and inconsistent with > the >> core protocol. It also contradicts general practice in LLN routing, = at > least as far >> as I am aware of it. My edits try to fix this, as well as clean up a > range of >> grammatical issues. >>=20 >> Abstract: >>=20 >> "RPL is instantiated to honor a particular routing > objective/constraint by the >> adding a specific Objective Function (OF) that is designed to solve > that >> problem. " >>=20 >> should become >>=20 >> "A RPL instance specifies an Objective Function (OF) that defines how > nodes >> in the instance compute distance and select routes." >=20 > [Pascal]=20 > The term instantiated here refers to the fact that RPL as a protocol = has > a generic core. To turn it into an runnable protocol, it has to be > instantiated by adding and OF. The result is a protocol. > Your words are correct but refer to a different thing. A RPL instance = is > a runtime construct. There is no need to redefine it here. I think this is -- at least to me -- a confusing use of the word = "instantiate." Adding an OF doesn't instantiate RPL: having a DODAG Root = does. Of course, for a DODAG Root to exist there must be an OF selected = for the corresponding RPL instance. Or are you saying you can have zero = nodes yet have a RPL instance? The problem is that "RPL Instance" is = defined in -19 as: RPL Instance: A set of one or more DODAGs that share a RPLInstanceID. A RPL node can belong to at most one DODAG in a RPL Instance. Each RPL Instance operates independently of other RPL Instances. This document describes operation within a single RPL Instance. When I read "instantiate" I think "make a RPL Instance." Adding an OF to = RPL does not create a RPL Instance, right? >=20 >>=20 >> Reason: "honor" is inaccurate, that suggests one could not follow it. > It is not >> clear what "problem" the sentence refers to. "by the adding" is >> grammatically incorrect. I think the new sentence more clearly and > accurately >> says what the existing one is trying to. >=20 > [Pascal] the grammar will be fixed by the RFC editor. Maybe achieve > would be better than honor? >=20 I think "meet" would possibly make more sense. But regardless, the = second sentence doesn't make a lot of sense as it is. >> ---- >>=20 >> Introduction edit 1: >>=20 >> "Considering the wide variety of use cases, link types and metrics, >> the Routing Protocol for Low Power and Lossy Networks >> [I-D.ietf-roll-rpl] was designed as a generic core that is agnostic >> to metrics and instantiated using Objective Functions. >>=20 >> RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) >> within instances of the protocol, each instance being set up to > honor >> a particular routing objective/constraint of a given deployment. >> This instantiation is achieved by plugging into the RPL core a >> specific Objective Function (OF) that is designed to solve that >> problem to be addressed by that instance." >>=20 >> should become >>=20 >> "Considering the wide variety of use cases, link types and metrics, >> the Routing Protocol for Low Power and Lossy Networks >> [I-D.ietf-roll-rpl] was designed as a generic core that is agnostic >> to metrics. Each RPL instance specifies an Objective Function which >> nodes in that instance use to compute and select routes. This > separation >> of Objective Functions from the core protocol specification allows > RPL >> to adapt to meet the different optimization criteria the wide range > of >> use cases requires." >>=20 >> Reason: The second paragraph in the original version is confused: it > suggests >> that one instantiates RPL by giving it an Objective Function. This is > not true. >=20 > [Pascal] Well yes it is true. But we are referring to different = things. Please refer to the RPL Instance definition above. >=20 >=20 >> Tries to explain the reason for the separation, rather than how it's > used. > [Pascal] I like your last sentence though. >=20 >> Introduction edit 2: >>=20 >>=20 >> "An Objective Function selects the DODAG version that a device > joins, >> and a number of neighbor routers within that version as parents and >> siblings. The OF is also responsible for computing the Rank of the >> device, that abstracts a relative position within the DODAG and is >> used by the RPL core to enable a degree of loop avoidance and > verify >> forward progression towards a destination, as specified in >> [I-D.ietf-roll-rpl]." >>=20 >> should become >>=20 >> "A RPL instance forms Destination Oriented Directed Acyclic Graphs >> (DODAGs). >> An Objective Function selects the DODAG that a device joins, >> the neighbor routers within that DODAG that the device maintains >> state on, and which neighbors the device selects as parents towards >> the root of the DODAG. The OF is also responsible for computing the > Rank >> of the >> device, an abstract distance from the DODAG root." >>=20 >> Reason: There is no reason to talk about loop avoidance and datapath >> validation here. Siblings are no longer a primitive in RPL, the > rewrite makes >> the above description accurately reflect the text in DIO processing = in > -19. >=20 > [Pascal] I suggest we discuss the sibling separately, see if the > resolution is to introduce them in this spec or remove all that's > related to sibling. > This being said, I can agree that we do not need to define Rank = anymore > that we need to define RPL Instance. I'm fine with the removal though > the existing text does not hurt IMHO. There was a long discussion among the WG and authors remove the concept = of siblings from RPL because they were confusing and not actually = relevant to the protocol as it's now defined: they were another = abstraction that just make the whole thing more complicated. = Reintroducing the concept here seems contrary to that consensus. >=20 >=20 >>=20 >> Introduction edit 3: >>=20 >> Cut the paragraph: >>=20 >> "Indeed, it is the general design in RPL that the metrics are passed >> from parent to children in a specific container and that the OF > will >> derive the Rank from the natural metric. The separation of Rank > and >> metrics avoids a loss of information as the various metrics are >> propagated down the DAG. This specification can be used when the >> link properties that are considered are such that they can be > turned >> in a scalar step of Rank in a reversible fashion and the resulting >> step of rank is additive over multiple hops." >>=20 >> Reason: this is unnecessary detail and just a restatement of RPL and > makes >> this draft confusing, because it's describing a property of RPL that > the draft >> does not use. >=20 > [Pascal] this paragraph was added to clear things up based on your > comments (and Om's) > I could remove the first half though again I do not see any arm in it. > The second half " This specification can be used ... " seems a bit = more > important unless you consider that all metrics can be turned into an > additive step of rank? I don't think it's necessary. All that's needed is the clear statement = (which the draft has) that OF0 ignores metric containers. >=20 >>=20 >> Introduction edit 4: >>=20 >> "OF0 does not leverage metric containers such as >> described in the metrics draft [I-D.ietf-roll-routing-metrics]. > OF0 >> does not require information in the RPL messages but the abstract >> information from the DIO base container, such as Rank and an >> administrative preference, that is transported in DIOs as >> DODAGPreference in [I-D.ietf-roll-rpl]." >>=20 >> should become >>=20 >> "OF0 does not use RPL metric > containers[I-D.ietf-roll-routing-metrics] and >> ignores them. OF0 >> only requires the information in the DIO base container, such as > Rank and >> the >> DODAGPreference field that describes an administrative > preference[I- >> D.ietf-roll-rpl]." >>=20 >> Reason: The DODAGPreference is not transported in the draft; it's >> transported in a DIO Base container. It's better to say what OF0 > requires, >> rather than what it doesn't require, as the latter is imprecise and > open to >> interpretation (e.g. one could claim it needs information in a DIS). >>=20 > [Pascal] Makes sense to me; I trust that we can push that straight to > the RFC editor. >=20 >=20 >> ------ >>=20 >> Goal edit 1: >>=20 >> 3. Goal >>=20 >> should become >>=20 >> 3. Objective Function 0 Overview >>=20 >> Reason: This section is not just about goals, it is about how OF 0 > works. >>=20 > [Pascal] OK >=20 >=20 >>=20 >> Goal edit 2: >>=20 >> "The metric used in OF0 can be an administratively defined scalar > cost >> that is trivially added up along a path to compute the RPL Rank, as >> defined in [I-D.ietf-roll-rpl]. Depending on how the step of Rank > is >> computed by an implementation, the Rank of a node might be > analogous >> to a weighted hop count of the path to the root. Using a metric > that >> in essence is similar to hop count implies that the quality of the >> connectivity should be asserted so that only neighbors with a good >> enough connectivity are presented to the OF. How that connectivity >> is asserted and maintained is not covered by this specification. >>=20 >> In wireless networks, Hop Count will tend to favor paths with long >> distance links and non optimal connectivity properties. In some >> situations, this might end up partitioning the network. As a > result, >> the link selection must be very conservative, and the available > link >> set is thus constrained. For those reasons, though it can be used > on >> wired links and wired link emulations such as WIFI infrastructure >> mode, a metric derived from hop count is generally not recommended >> for wireless networks. Instead, careful thinking should be applied >> to determine how the step of Rank is computed from the link >> properties. For instance, the Minimum Rank Objective Function with >> Hysteresis [I-D.ietf-roll-minrank-hysteresis-of] provides guidance > on >> how hysteresis can be used to maintain a certain stability of the >> resulting Rank." >>=20 >>=20 >> should become >>=20 >> "OF0 computes Rank as a simple scalar cost that nodes add up >> along a path. OF0 assigns a cost to each link to another node >> that it monitors and computes Rank as the Rank of the other node > plus >> the cost of the link. The exact method for computing link cost is >> implementation-dependent. >>=20 >> One trivial OF0 implementation might compute the Rank >> as a weighted hop count where some links cost more than one hop. >> Using a metric similar to hop count implies that the OF0 > implementation >> only considers neighbors with good enough connectivity, especially >> in wireless networks. In wireless networks, an unweighted hop count >> favors paths with long distance links and poor connectivity > properties[De >> Couto]. >> Wireless networks using OF0 should carefully compute the step of > Rank >> from link properties to avoid this problem. For instance, the > Minimum >> Rank Objective Function with Hysteresis > [I-D.ietf-roll-minrank-hysteresis- >> of] >> provides guidance on how link cost can be computed and hysteresis > can >> improve >> Rank stability." >>=20 >> Here's the reference: >>=20 >> [De Couto] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and > Robert >> Morris, A High-Throughput Path Metric for Multi-Hop Wireless Routing, >> Proceedings of the 9th ACM International Conference on Mobile > Computing >> and Networking (MobiCom '03), San Diego, California, September 2003. >>=20 >> Reason: The current text suggests hopcount as a mechanism, but then > says >> that it's not advised for wireless networks. But this is not quite > correct: OF0 >> uses a link weighting, which means it could work fine as long as you > weight >> the links properly. The reference to MRHOF is also a non-sequitor: it > jumps >> from cost computation to route selection hysteresis. Instead, MRHOF = is >> relevant here because it talks about ways to compute Rank steps. The >> comment about WiFi should be removed because, well, it is wireless. >>=20 > [Pascal] Very good >=20 >> Goal edit 3: >>=20 >> All text in 3 after >> "A node MAY stretch its step of Rank by up to MAXIMUM_RANK_STRETCH >> in >> order to enable the selection of a sibling when only one parent is >> available. For instance, say that a node computes a step of Rank > of >> 4 units of MINIMUM_RANK_INCREMENT from a preferred parent with a >> Rank >> of 6 units resulting in a Rank of 10 units for this node. Say that >> with that Rank of 10 units, this node would end up with only one >> parent and no sibling, though there is a neighbor with a Rank of 12 >> units. In that case, the node is entitled to stretch its step of >> Rank by a value of 2 units, thus using a step of Rank of 6 units so >> as to reach a Rank of 12 units and find a sibling. But the node is >> not entitled to use a step of Rank larger than 6 units since that >> would be a greedy behavior that would deprive the neighbor of this >> node of a successor. Also, if the neighbor had exposed a Rank of > 16 >> units, the stretch of Rank from 10 to 16 units would have exceeded >> MAXIMUM_RANK_STRETCH of 5 units and thus the neighbor would not >> have >> been selectable even as a sibling...." >>=20 >> should become >>=20 >> "The core RPL specification describes constraints on how nodes > select >> potential parents, called a parent set, from their neighbors. >> OF0 selects a parent set trying to balance three needs. The first > is >> that the route through its preferred parent has as low a Rank as >> possible. The second is that it has multiple elements in its > parent >> set. The third is that the Rank it sets for the node is not much >> higher than the Rank associated with the route through its > preferred >> parent. Generally, the first two are more important than the > third: >> advertising a high Rank in order to maintain some path diversity is >> better than advertising a lower Rank but being unable to route when >> the corresponding link fails. >>=20 >> OF0 has a parameter, MAXIMUM_RANK_STRETCH, which defines the >> maximum >> stretch between the associated Rank of members of its parent set. >> If the Rank associated with a route through a node's preferred > parent is >> R, then the node MUST NOT advertise a Rank greater than >> R + MAXIMUM_RANK_STRETCH. >>=20 >> OF0 has two rules when selecting the DODAG Version of its parent > set. >> First, OF0 MUST select a parent set from a DODAG Version that has > the >> highest administrative preference among the DODAG Versions it is > aware >> of. Among the DODAGs with this highest administrative preference > value, >> OF0 MUST select a Grounded DODAG if one is available." >>=20 >>=20 > : the current text talks about stretching Rank to reach siblings = without >> first saying how Rank is computed. Siblings are no longer a concept = in > RPL. >> The concepts are neighbor set, parent set, and preferred parent. The > edit >> clearly states how preferred parents are selected, the parent set is > selected, >> etc. The statements about Grounded and administrative preference are > not >> normative, yet should be. The rule on MAXIMUM_RANK_STRETCH is now >> defined properly in line with how parent sets affect DIO processing. >>=20 >=20 > [Pascal] Note that the stretch is associated to siblings. It is the > stretch between Rank obtained from the preferred parent and a sibling, > not the license to go deeper to get an alternate parent, which would = be > a bit greedy. I expected this text to go down the sink with the = sibling > text. What you're doing here changes the meaning of stretch > considerably. This would be a new behavior and thus a new LC.=20 But RPL does not have a concept of siblings! I know you love them but = PLEASE don't try to reintroduce the concept. Doing so is tremendously = confusing. We all agreed to remove siblings. You need to respect that = decision rather than try to push RPL back in the direction you = preferred. More generally, after reading OF0-07 very carefully, I think you need to = re-read the DIO processing rules in RPL-19. The current OF0 text is = based on a very old version of RPL (makes sense, given it's been around = since then) and is no longer consistent with current descriptions of the = protocol. >=20 >> Reason >> Goal edit 4: >>=20 >> Remove section 4: it contradicts itself several times. For example, 6 > says that >> one SHOULD use a newer DODAG Version; 9 says that one SHOULD use the >> existing DODAG Version. Furthermore, it is not clear that the actual > order >> specified is the right one (it is not based on any existing > implementations). >> Rule 4 is subsumed in the Goal edit 3 text, as is rule 5. Rule 7 > (minimize Rank) >> will cause route flapping because it comes before rule 10 (keep > existing >> preferred parent). >=20 > [Pascal] There is no contradiction. This really boils down to 9 is > useless and can be safely removed. I think removing 9. makes sense.=20 Part of the issue here is that all of the rules are SHOULDs. This means = one can write an OF0 which follows none of them yet still follows the = RFC.=20 I see two ways of reconciling 7 and 10. 1) Tweak the text in 7 to say=20 7. When computing a resulting Rank for this node from a parent Rank and a Step of Rank from that parent, a parent that results in a = significantly lower Rank than the current preferred parent SHOULD be = preferred. or merge 7 and 10 7. The preferred parent that was already in use SHOULD be preferred, = unless there is another element of the parent set which results in a = significantly lower Rank, in which case this parent SHOULD be preferred. >=20 > Rule 7 would cause flapping if the Rank changes are not dampened. But > the spec indicates that they should be. 10 before 7 would lock to a > parent forever. >=20 > Finally this text was reviewed by the group and is normative.=20 > So it was implemented by those who implemented OF0. We did not get a > feedback that the order was wrong.=20 > And since we passed LC, I'm not anxious to make any change there (but > remove the useless 9). I don't think this is the correct way to interpret the process. We are = in LC now. The prior version, which passed LC, said "OF0 is not for = wireless." This version says that OF0 can be used for wireless. So I am = giving technical comments that allow it to make that claim. Can someone who has implemented OF0 to follow the rules in Section 4 = speak up and attest to their correctness? They seem to contradict what I = understand distance vector calculations in wireless networks normally = do. Of course, since all of the rules in 4 are SHOULDs, it is possible = to write any algorithm and have it "follow" OF0. That doesn't mean we = shouldn't try to provide guidance on what is the right thing to do in = the general case. >=20 >> Goal edit 5: >>=20 >> Remove section 5: the abstraction of a parent set in the RPL core >> specification removes the need for a backup next hop: every element = of > the >> parent set is a backup next hop. This section could be rewritten to > reflect a >> parent set, but Goal edit 3 addresses this somewhat. >=20 > [Pascal] OF0 only requires one backup. But I agree it does not = preclude > having more. And I agree that alt parents are all possible backups. = But > I want to insist that a backup is not necessarily a parent. Please read the DIO processing rules of RPL-19. By definition, it may = need to be, because of the rules on MaxRankIncrease. >=20 >> If you think section 4 and 5 should stay, I can try a rewrite that > would make >> them consistent with the DIO processing rules in -19 as well as not >> contradictory and applicable to wireless networks. >=20 > [Pascal] I do not think we have choice about that: the sections are > normative and should stay consistent to what they were at LC, unless = we > have an IESG issue. Please note as above, we are in LC. The point of this LC is to make sure = that OF0 can be applied to wireless, because of changes in the RPL spec = in IESG review that made OF0 a SHOULD. The fact that it went through LC = when it said it was not intended for wireless is not particularly = relevant. > Text improvements that reduce the chances for a misunderstanding = within > those constraints are welcome. I think you are incorrectly constraining the document. Phil= From dominique.barthel@orange-ftgroup.com Wed Mar 16 09:20:36 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA9693A699A for ; Wed, 16 Mar 2011 09:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.248 X-Spam-Level: X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WneZzl0FSFZ3 for ; Wed, 16 Mar 2011 09:20:35 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id C71213A69AD for ; Wed, 16 Mar 2011 09:20:34 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 047638B8003; Wed, 16 Mar 2011 17:22:30 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id EF1308B8002; Wed, 16 Mar 2011 17:22:29 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Mar 2011 17:22:00 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE3F6.46BAF63E" Date: Wed, 16 Mar 2011 17:21:05 +0100 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF0231EC65@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I flag inconsistency in rpl-metrics-19 ? Thread-Index: Acvjvel74ULcY3YaQrWTlerBMyJl4gANvuyA References: From: To: , X-OriginalArrivalTime: 16 Mar 2011 16:22:00.0615 (UTC) FILETIME=[47329B70:01CBE3F6] Subject: Re: [Roll] I flag inconsistency in rpl-metrics-19 ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 16:20:36 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE3F6.46BAF63E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Cedric, =20 Good catch ! A quick response : just looking at your mail and the quoted text, my = take is that 4.4.1 is wrong, as you suspected. We'll probably have to do an erratum after RFC publication, because I = don't think this mistake justifies for a complete document respin = including WG last call, etc. =20 However, regarding section 3.2, I think it is correct. The idea is that, = if the first sub-object is an EXCLUDE (resp. INCLUDE), it should exclude = from (resp. add to) an initially FULL (resp. EMPTY) set. It does not = make sense to exclude a subset of a empty set, or to add a subset to a = full set, does it? =20 I'll give it a more thorough look shortly. Thanks a lot =20 Dominique ________________________________ De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = C Chauvenet Envoy=E9 : mercredi 16 mars 2011 10:39 =C0 : 'roll@ietf.org' Objet : [Roll] I flag inconsistency in rpl-metrics-19 ? Hi all,=20 =20 Reading the routing-metrics-19 draft I noticed something odd about the I = flag in the NE and the LC sub-Object : =20 In the NE sub Object (Section 3.2) : " I (Included): the I bit is only = relevant when the node type is used as a constraint. [...]. When set, this indicates that nodes of the = type specified in the node type field MUST be included. Conversely, when cleared, this indicates that nodes of type specified in the node type field MUST be excluded." =20 In the LC object (section 4.4.1) : " I Bit: The I bit is only relevant = when the Link Color is used as a constraint. When cleared, this indicates that links with the specified color must be included. When set, this indicates that links with the specified color must be excluded." =20 I guess there an inversion in the latter definition. =20 Furthermore at the end of the section 3.2 : " If the NE object comprises = several sub-objects when used as a constraint, each sub-object adds or subtracts node subsets as the sub-objects are parsed in order. The initial set (full or empty) is defined by the I bit of the first sub-object: full if that I bit is an exclusion, empty if that I bit is an inclusion." =20 Behavior of the I flag in this case seems conflitcting with the wording, = or I missed something ? =20 Maybe editors of the document could clarify this. =20 C=E9dric. =20 ------_=_NextPart_001_01CBE3F6.46BAF63E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello Cedric,
 
Good catch !
A quick response : just looking at your mail and = the quoted=20 text, my take is that 4.4.1 is wrong, as you = suspected.
We'll probably have to do an erratum after = RFC=20 publication, because I don't think this mistake justifies for a complete = document respin including WG last call, etc.
 
However, regarding section 3.2, I think it is = correct. The=20 idea is that, if the first sub-object is an EXCLUDE (resp. = INCLUDE),=20 it should exclude from (resp. add to) an initially FULL (resp.=20 EMPTY) set. It does not make sense to exclude a subset of a empty = set, or=20 to add a subset to a full set, does it?
 
I'll give it a more thorough look = shortly.
Thanks a lot
 
Dominique

De : roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] De la part de C=20 Chauvenet
Envoy=E9 : mercredi 16 mars 2011 = 10:39
=C0 :=20 'roll@ietf.org'
Objet : [Roll] I flag inconsistency in=20 rpl-metrics-19 ?

Hi all,

 

Reading the routing-metrics-19 draft I noticed = something odd=20 about the I flag in the NE and the LC sub-Object :

 

In the NE sub Object (Section 3.2) : " I (Included): the I bit = is only=20 relevant when the node type is

used as a=20 constraint. [=85]. When set, this indicates that nodes of the=20 type

specified=20 in the node type field MUST be included.=20 Conversely,

when=20 cleared, this indicates that nodes of type specified in=20 the

node type=20 field MUST be excluded."

 

In the LC object (section 4.4.1)  : " I Bit: The I bit is = only relevant=20 when the Link Color is used as a

constraint. When = cleared,=20 this indicates that links with the

specified=20 color must be included. When set, this indicates=20 that

links=20 with the specified color must be excluded."

 

I guess there an inversion in the latter=20 definition.

 

Furthermore at the end of the section 3.2 : " If the NE object = comprises=20 several sub-objects when used as a

constraint, each = sub-object adds=20 or subtracts node subsets as the

sub-objects are parsed = in order.=20 The initial set (full or empty) is

defined=20 by the I bit of the first sub-object: full if that I bit=20 is

an=20 exclusion, empty if that I bit is an=20 inclusion."

 

Behavior of the I flag in this case seems = conflitcting with=20 the wording, or I missed something ?

 

Maybe editors of the document could clarify=20 this.

 

C=E9dric.

 

------_=_NextPart_001_01CBE3F6.46BAF63E-- From c.chauvenet@watteco.com Wed Mar 16 09:40:29 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29C0C3A69E1 for ; Wed, 16 Mar 2011 09:40:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.184 X-Spam-Level: X-Spam-Status: No, score=-5.184 tagged_above=-999 required=5 tests=[AWL=1.414, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6+syR7+F8gCI for ; Wed, 16 Mar 2011 09:40:23 -0700 (PDT) Received: from VA3EHSOBE006.bigfish.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by core3.amsl.com (Postfix) with ESMTP id 1C0B03A68EB for ; Wed, 16 Mar 2011 09:40:22 -0700 (PDT) Received: from mail178-va3-R.bigfish.com (10.7.14.248) by VA3EHSOBE006.bigfish.com (10.7.40.26) with Microsoft SMTP Server id 14.1.225.8; Wed, 16 Mar 2011 16:41:49 +0000 Received: from mail178-va3 (localhost.localdomain [127.0.0.1]) by mail178-va3-R.bigfish.com (Postfix) with ESMTP id 3B1A9168549; Wed, 16 Mar 2011 16:41:49 +0000 (UTC) X-SpamScore: -30 X-BigFish: VPS-30(zzbb2cK14ffOzz1202hzz8275bh8275dh1033ILz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB009.red002.local; RD:none; EFVD:NLI Received: from mail178-va3 (localhost.localdomain [127.0.0.1]) by mail178-va3 (MessageSwitch) id 1300293707374245_26389; Wed, 16 Mar 2011 16:41:47 +0000 (UTC) Received: from VA3EHSMHS004.bigfish.com (unknown [10.7.14.253]) by mail178-va3.bigfish.com (Postfix) with ESMTP id 4D7721B68052; Wed, 16 Mar 2011 16:41:47 +0000 (UTC) Received: from IE2RD2HUB009.red002.local (213.199.187.153) by VA3EHSMHS004.bigfish.com (10.7.99.14) with Microsoft SMTP Server (TLS) id 14.1.225.22; Wed, 16 Mar 2011 16:41:45 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB009.red002.local ([10.33.16.248]) with mapi; Wed, 16 Mar 2011 09:41:30 -0700 From: C Chauvenet To: "dominique.barthel@orange-ftgroup.com" , "roll@ietf.org" Date: Wed, 16 Mar 2011 09:41:28 -0700 Thread-Topic: [Roll] I flag inconsistency in rpl-metrics-19 ? Thread-Index: Acvjvel74ULcY3YaQrWTlerBMyJl4gANvuyAAADl85A= Message-ID: References: <8E09C72DBC577D489F13A71228C0B7BF0231EC65@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF0231EC65@ftrdmel0.rd.francetelecom.fr> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/alternative; boundary="_000_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A738BIE2RD2XVS211r_" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Subject: Re: [Roll] I flag inconsistency in rpl-metrics-19 ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 16:40:29 -0000 --_000_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A738BIE2RD2XVS211r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dominique, Agree on the erratum. Your explication on the meaning of the I flag in section 3.2 is very clear.= I didn't understood it correctly, so the text is correct in the draft. Thank's for you reply. C=E9dric. De : dominique.barthel@orange-ftgroup.com [mailto:dominique.barthel@orange-= ftgroup.com] Envoy=E9 : mercredi 16 mars 2011 17:21 =C0 : C Chauvenet; roll@ietf.org Objet : RE: [Roll] I flag inconsistency in rpl-metrics-19 ? Hello Cedric, Good catch ! A quick response : just looking at your mail and the quoted text, my take i= s that 4.4.1 is wrong, as you suspected. We'll probably have to do an erratum after RFC publication, because I don't= think this mistake justifies for a complete document respin including WG l= ast call, etc. However, regarding section 3.2, I think it is correct. The idea is that, if= the first sub-object is an EXCLUDE (resp. INCLUDE), it should exclude from= (resp. add to) an initially FULL (resp. EMPTY) set. It does not make sense= to exclude a subset of a empty set, or to add a subset to a full set, does= it? I'll give it a more thorough look shortly. Thanks a lot Dominique ________________________________ De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de C C= hauvenet Envoy=E9 : mercredi 16 mars 2011 10:39 =C0 : 'roll@ietf.org' Objet : [Roll] I flag inconsistency in rpl-metrics-19 ? Hi all, Reading the routing-metrics-19 draft I noticed something odd about the I fl= ag in the NE and the LC sub-Object : In the NE sub Object (Section 3.2) : " I (Included): the I bit is only rele= vant when the node type is used as a constraint. [...]. When set, this indicates that nodes of the typ= e specified in the node type field MUST be included. Conversely, when cleared, this indicates that nodes of type specified in the node type field MUST be excluded." In the LC object (section 4.4.1) : " I Bit: The I bit is only relevant whe= n the Link Color is used as a constraint. When cleared, this indicates that links with the specified color must be included. When set, this indicates that links with the specified color must be excluded." I guess there an inversion in the latter definition. Furthermore at the end of the section 3.2 : " If the NE object comprises se= veral sub-objects when used as a constraint, each sub-object adds or subtracts node subsets as the sub-objects are parsed in order. The initial set (full or empty) is defined by the I bit of the first sub-object: full if that I bit is an exclusion, empty if that I bit is an inclusion." Behavior of the I flag in this case seems conflitcting with the wording, or= I missed something ? Maybe editors of the document could clarify this. C=E9dric. --_000_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A738BIE2RD2XVS211r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dominique,

 

Agree on the erratum.

 

=

Your explication on the = meaning of the I flag in section 3.2 is very clear. I didn't understood it = correctly, so the text is correct in the draft.

Thank's for you reply.

 = ;

C=E9dr= ic.

 

De : dominique.barthel@orange-ftgro= up.com [mailto:dominique.barthel@orange-ftgroup.com]
Envoy=E9 := mercredi 16 mars 2011 17:21
=C0 : C Chauvenet; roll@iet= f.org
Objet : RE: [Roll] I flag inconsistency in rpl-metrics= -19 ?

 

Hello Cedric,

 

Good catch !

A quick response : just looking at y= our mail and the quoted text, my take is that 4.4.1 is wrong, as you suspec= ted.

<= span style=3D'font-size:10.0pt;font-family:"Arial","sans-serif";color:blue;= mso-fareast-language:FR'>We'll probably have to do an erratum after RF= C publication, because I don't think this mistake justifies for a complete = document respin including WG last call, etc.

 

However, regardi= ng section 3.2, I think it is correct. The idea is that, if the first&= nbsp;sub-object is an EXCLUDE (resp. INCLUDE), it should exclude from (resp= . add to) an initially FULL (resp. EMPTY) set. It does not make s= ense to exclude a subset of a empty set, or to add a subset to a full set, = does it?

 

I'll give it a more thorough look shortly.

Thanks a lot

 

Dominique=

 <= /o:p>

De : roll-bounces@ietf.org [mailto:rol= l-bounces@ietf.org] De la part de C Chauvenet
Envoy=E9 :<= /b> mercredi 16 mars 2011 10:39
=C0 : 'roll@ietf.org'
= Objet : [Roll] I flag inconsistency in rpl-metrics-19 ?

Hi all,

 

Readi= ng the routing-metrics-19 draft I noticed something odd about the I flag in= the NE and the LC sub-Object :

&nb= sp;

In the NE sub Object (Section 3.2) : &quo= t; I (Included): the I= bit is only relevant when the node type is

used as a= constraint. […]. When set, this indicates that nodes of the t= ype

specified in the node type field MUST be include= d. Conversely,

when cleared, this indicates = that nodes of type specified in the

node type field MUS= T be excluded."

=  

In the LC object (section 4.4.1)  = ;: " I Bit: The I= bit is only relevant when the Link Color is used as a

= constraint. When cleared, this indicates that links with the

specified color must be included. When set, this= indicates that

links with the specified color must be = excluded."

 

I guess there an inversion in the latter definition.<= /o:p>

 

Fur= thermore at the end of the section 3.2 : " If the NE object comprises several sub-objects wh= en used as a

constraint, each sub-object adds or subtra= cts node subsets as the

sub-objects are parsed in order= . The initial set (full or empty) is

defined by the I b= it of the first sub-object: full if that I bit is<= /p>

an exclusion, empty if that I bit is an inclusion.&q= uot;

 

B= ehavior of the I flag in this case seems conflitcting with the wording, or = I missed something ?

 

Maybe editors of the document could clarify this.

 

= C=E9dric.

 

= --_000_BDF612E3788C4C4791A1A49AC3CB7C970B4E6A738BIE2RD2XVS211r_-- From yoav@yitran.com Wed Mar 16 15:00:40 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7627B3A6A66 for ; Wed, 16 Mar 2011 15:00:40 -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_102=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8g-2QW8gxFtW for ; Wed, 16 Mar 2011 15:00:38 -0700 (PDT) Received: from na3sys009aog102.obsmtp.com (na3sys009aog102.obsmtp.com [74.125.149.69]) by core3.amsl.com (Postfix) with SMTP id C596E3A6A5C for ; Wed, 16 Mar 2011 15:00:36 -0700 (PDT) Received: from source ([209.85.160.172]) (using TLSv1) by na3sys009aob102.postini.com ([74.125.148.12]) with SMTP ID DSNKTYEzW1bFeckwgQCwyPLSy7zFybDL7IPs@postini.com; Wed, 16 Mar 2011 15:02:05 PDT Received: by mail-gy0-f172.google.com with SMTP id 3so1034076gyf.31 for ; Wed, 16 Mar 2011 15:02:03 -0700 (PDT) Received: by 10.101.175.21 with SMTP id c21mr390519anp.67.1300312923080; Wed, 16 Mar 2011 15:02:03 -0700 (PDT) From: Yoav Ben-Yehezkel References: <20110314094501.1366.59375.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D041A22B7@XMB-AMS-107.cisco.com> <9F3EA16A-3390-4FEE-9EA3-96018FBB7CF2@cs.stanford.edu> In-Reply-To: <9F3EA16A-3390-4FEE-9EA3-96018FBB7CF2@cs.stanford.edu> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acvj9RpsVzLX1mTCRReqwqmboY0LNAAL/kXg Date: Thu, 17 Mar 2011 00:00:00 +0200 Message-ID: To: Philip Levis , "Pascal Thubert (pthubert)" Content-Type: text/plain; charset=ISO-8859-1 Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 22:00:40 -0000 Hi, I looked at the RPL spec, and there is indeed no mentioning of siblings. Therefore, I think Phil has a point that it is out of context in OF0 from the main body of RPL. However, seeing the potential benefit by the use of siblings - is there a method by which the related text on sibling becomes an optional feature (maybe specified in a separate I-D)? Best regards, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: Wednesday, March 16, 2011 6:13 PM To: Pascal Thubert (pthubert) Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-07.txt On Mar 16, 2011, at 8:11 AM, Pascal Thubert (pthubert) wrote: > Thanks a lot for all this Phil, > > [Pascal] Please find some answers below. I'd really appreciate that > others comment about this. > >>> The Routing Protocol for Low Power and Lossy Networks (RPL) defines > a >>> generic Distance Vector protocol for Low Power and Lossy Networks >>> (LLNs). RPL is instantiated to honor a particular routing > objective/ >>> constraint by the adding a specific Objective Function (OF) that is >>> designed to solve that problem. This specification defines a basic >>> OF, OF0, that uses only the abstract properties exposed in RPL >>> messages with no metric container. >>> >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-07.txt >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >> >> Comments and suggested edits on OF0-07 follow. Because of the very > short >> timeframe I am including concrete edits rather than general >> recommendations. My general read is that the core ideas of OF0 are > sound >> but its current text is very much out of date with how RPL works: it > has many >> holdovers from older specifications of RPL, such as siblings and how > Rank is >> computed. Correspondingly it is very confusing and inconsistent with > the >> core protocol. It also contradicts general practice in LLN routing, at > least as far >> as I am aware of it. My edits try to fix this, as well as clean up a > range of >> grammatical issues. >> >> Abstract: >> >> "RPL is instantiated to honor a particular routing > objective/constraint by the >> adding a specific Objective Function (OF) that is designed to solve > that >> problem. " >> >> should become >> >> "A RPL instance specifies an Objective Function (OF) that defines how > nodes >> in the instance compute distance and select routes." > > [Pascal] > The term instantiated here refers to the fact that RPL as a protocol has > a generic core. To turn it into an runnable protocol, it has to be > instantiated by adding and OF. The result is a protocol. > Your words are correct but refer to a different thing. A RPL instance is > a runtime construct. There is no need to redefine it here. I think this is -- at least to me -- a confusing use of the word "instantiate." Adding an OF doesn't instantiate RPL: having a DODAG Root does. Of course, for a DODAG Root to exist there must be an OF selected for the corresponding RPL instance. Or are you saying you can have zero nodes yet have a RPL instance? The problem is that "RPL Instance" is defined in -19 as: RPL Instance: A set of one or more DODAGs that share a RPLInstanceID. A RPL node can belong to at most one DODAG in a RPL Instance. Each RPL Instance operates independently of other RPL Instances. This document describes operation within a single RPL Instance. When I read "instantiate" I think "make a RPL Instance." Adding an OF to RPL does not create a RPL Instance, right? > >> >> Reason: "honor" is inaccurate, that suggests one could not follow it. > It is not >> clear what "problem" the sentence refers to. "by the adding" is >> grammatically incorrect. I think the new sentence more clearly and > accurately >> says what the existing one is trying to. > > [Pascal] the grammar will be fixed by the RFC editor. Maybe achieve > would be better than honor? > I think "meet" would possibly make more sense. But regardless, the second sentence doesn't make a lot of sense as it is. >> ---- >> >> Introduction edit 1: >> >> "Considering the wide variety of use cases, link types and metrics, >> the Routing Protocol for Low Power and Lossy Networks >> [I-D.ietf-roll-rpl] was designed as a generic core that is agnostic >> to metrics and instantiated using Objective Functions. >> >> RPL forms Destination Oriented Directed Acyclic Graphs (DODAGs) >> within instances of the protocol, each instance being set up to > honor >> a particular routing objective/constraint of a given deployment. >> This instantiation is achieved by plugging into the RPL core a >> specific Objective Function (OF) that is designed to solve that >> problem to be addressed by that instance." >> >> should become >> >> "Considering the wide variety of use cases, link types and metrics, >> the Routing Protocol for Low Power and Lossy Networks >> [I-D.ietf-roll-rpl] was designed as a generic core that is agnostic >> to metrics. Each RPL instance specifies an Objective Function which >> nodes in that instance use to compute and select routes. This > separation >> of Objective Functions from the core protocol specification allows > RPL >> to adapt to meet the different optimization criteria the wide range > of >> use cases requires." >> >> Reason: The second paragraph in the original version is confused: it > suggests >> that one instantiates RPL by giving it an Objective Function. This is > not true. > > [Pascal] Well yes it is true. But we are referring to different things. Please refer to the RPL Instance definition above. > > >> Tries to explain the reason for the separation, rather than how it's > used. > [Pascal] I like your last sentence though. > >> Introduction edit 2: >> >> >> "An Objective Function selects the DODAG version that a device > joins, >> and a number of neighbor routers within that version as parents and >> siblings. The OF is also responsible for computing the Rank of the >> device, that abstracts a relative position within the DODAG and is >> used by the RPL core to enable a degree of loop avoidance and > verify >> forward progression towards a destination, as specified in >> [I-D.ietf-roll-rpl]." >> >> should become >> >> "A RPL instance forms Destination Oriented Directed Acyclic Graphs >> (DODAGs). >> An Objective Function selects the DODAG that a device joins, >> the neighbor routers within that DODAG that the device maintains >> state on, and which neighbors the device selects as parents towards >> the root of the DODAG. The OF is also responsible for computing the > Rank >> of the >> device, an abstract distance from the DODAG root." >> >> Reason: There is no reason to talk about loop avoidance and datapath >> validation here. Siblings are no longer a primitive in RPL, the > rewrite makes >> the above description accurately reflect the text in DIO processing in > -19. > > [Pascal] I suggest we discuss the sibling separately, see if the > resolution is to introduce them in this spec or remove all that's > related to sibling. > This being said, I can agree that we do not need to define Rank anymore > that we need to define RPL Instance. I'm fine with the removal though > the existing text does not hurt IMHO. There was a long discussion among the WG and authors remove the concept of siblings from RPL because they were confusing and not actually relevant to the protocol as it's now defined: they were another abstraction that just make the whole thing more complicated. Reintroducing the concept here seems contrary to that consensus. > > >> >> Introduction edit 3: >> >> Cut the paragraph: >> >> "Indeed, it is the general design in RPL that the metrics are passed >> from parent to children in a specific container and that the OF > will >> derive the Rank from the natural metric. The separation of Rank > and >> metrics avoids a loss of information as the various metrics are >> propagated down the DAG. This specification can be used when the >> link properties that are considered are such that they can be > turned >> in a scalar step of Rank in a reversible fashion and the resulting >> step of rank is additive over multiple hops." >> >> Reason: this is unnecessary detail and just a restatement of RPL and > makes >> this draft confusing, because it's describing a property of RPL that > the draft >> does not use. > > [Pascal] this paragraph was added to clear things up based on your > comments (and Om's) > I could remove the first half though again I do not see any arm in it. > The second half " This specification can be used ... " seems a bit more > important unless you consider that all metrics can be turned into an > additive step of rank? I don't think it's necessary. All that's needed is the clear statement (which the draft has) that OF0 ignores metric containers. > >> >> Introduction edit 4: >> >> "OF0 does not leverage metric containers such as >> described in the metrics draft [I-D.ietf-roll-routing-metrics]. > OF0 >> does not require information in the RPL messages but the abstract >> information from the DIO base container, such as Rank and an >> administrative preference, that is transported in DIOs as >> DODAGPreference in [I-D.ietf-roll-rpl]." >> >> should become >> >> "OF0 does not use RPL metric > containers[I-D.ietf-roll-routing-metrics] and >> ignores them. OF0 >> only requires the information in the DIO base container, such as > Rank and >> the >> DODAGPreference field that describes an administrative > preference[I- >> D.ietf-roll-rpl]." >> >> Reason: The DODAGPreference is not transported in the draft; it's >> transported in a DIO Base container. It's better to say what OF0 > requires, >> rather than what it doesn't require, as the latter is imprecise and > open to >> interpretation (e.g. one could claim it needs information in a DIS). >> > [Pascal] Makes sense to me; I trust that we can push that straight to > the RFC editor. > > >> ------ >> >> Goal edit 1: >> >> 3. Goal >> >> should become >> >> 3. Objective Function 0 Overview >> >> Reason: This section is not just about goals, it is about how OF 0 > works. >> > [Pascal] OK > > >> >> Goal edit 2: >> >> "The metric used in OF0 can be an administratively defined scalar > cost >> that is trivially added up along a path to compute the RPL Rank, as >> defined in [I-D.ietf-roll-rpl]. Depending on how the step of Rank > is >> computed by an implementation, the Rank of a node might be > analogous >> to a weighted hop count of the path to the root. Using a metric > that >> in essence is similar to hop count implies that the quality of the >> connectivity should be asserted so that only neighbors with a good >> enough connectivity are presented to the OF. How that connectivity >> is asserted and maintained is not covered by this specification. >> >> In wireless networks, Hop Count will tend to favor paths with long >> distance links and non optimal connectivity properties. In some >> situations, this might end up partitioning the network. As a > result, >> the link selection must be very conservative, and the available > link >> set is thus constrained. For those reasons, though it can be used > on >> wired links and wired link emulations such as WIFI infrastructure >> mode, a metric derived from hop count is generally not recommended >> for wireless networks. Instead, careful thinking should be applied >> to determine how the step of Rank is computed from the link >> properties. For instance, the Minimum Rank Objective Function with >> Hysteresis [I-D.ietf-roll-minrank-hysteresis-of] provides guidance > on >> how hysteresis can be used to maintain a certain stability of the >> resulting Rank." >> >> >> should become >> >> "OF0 computes Rank as a simple scalar cost that nodes add up >> along a path. OF0 assigns a cost to each link to another node >> that it monitors and computes Rank as the Rank of the other node > plus >> the cost of the link. The exact method for computing link cost is >> implementation-dependent. >> >> One trivial OF0 implementation might compute the Rank >> as a weighted hop count where some links cost more than one hop. >> Using a metric similar to hop count implies that the OF0 > implementation >> only considers neighbors with good enough connectivity, especially >> in wireless networks. In wireless networks, an unweighted hop count >> favors paths with long distance links and poor connectivity > properties[De >> Couto]. >> Wireless networks using OF0 should carefully compute the step of > Rank >> from link properties to avoid this problem. For instance, the > Minimum >> Rank Objective Function with Hysteresis > [I-D.ietf-roll-minrank-hysteresis- >> of] >> provides guidance on how link cost can be computed and hysteresis > can >> improve >> Rank stability." >> >> Here's the reference: >> >> [De Couto] Douglas S. J. De Couto, Daniel Aguayo, John Bicket, and > Robert >> Morris, A High-Throughput Path Metric for Multi-Hop Wireless Routing, >> Proceedings of the 9th ACM International Conference on Mobile > Computing >> and Networking (MobiCom '03), San Diego, California, September 2003. >> >> Reason: The current text suggests hopcount as a mechanism, but then > says >> that it's not advised for wireless networks. But this is not quite > correct: OF0 >> uses a link weighting, which means it could work fine as long as you > weight >> the links properly. The reference to MRHOF is also a non-sequitor: it > jumps >> from cost computation to route selection hysteresis. Instead, MRHOF is >> relevant here because it talks about ways to compute Rank steps. The >> comment about WiFi should be removed because, well, it is wireless. >> > [Pascal] Very good > >> Goal edit 3: >> >> All text in 3 after >> "A node MAY stretch its step of Rank by up to MAXIMUM_RANK_STRETCH >> in >> order to enable the selection of a sibling when only one parent is >> available. For instance, say that a node computes a step of Rank > of >> 4 units of MINIMUM_RANK_INCREMENT from a preferred parent with a >> Rank >> of 6 units resulting in a Rank of 10 units for this node. Say that >> with that Rank of 10 units, this node would end up with only one >> parent and no sibling, though there is a neighbor with a Rank of 12 >> units. In that case, the node is entitled to stretch its step of >> Rank by a value of 2 units, thus using a step of Rank of 6 units so >> as to reach a Rank of 12 units and find a sibling. But the node is >> not entitled to use a step of Rank larger than 6 units since that >> would be a greedy behavior that would deprive the neighbor of this >> node of a successor. Also, if the neighbor had exposed a Rank of > 16 >> units, the stretch of Rank from 10 to 16 units would have exceeded >> MAXIMUM_RANK_STRETCH of 5 units and thus the neighbor would not >> have >> been selectable even as a sibling...." >> >> should become >> >> "The core RPL specification describes constraints on how nodes > select >> potential parents, called a parent set, from their neighbors. >> OF0 selects a parent set trying to balance three needs. The first > is >> that the route through its preferred parent has as low a Rank as >> possible. The second is that it has multiple elements in its > parent >> set. The third is that the Rank it sets for the node is not much >> higher than the Rank associated with the route through its > preferred >> parent. Generally, the first two are more important than the > third: >> advertising a high Rank in order to maintain some path diversity is >> better than advertising a lower Rank but being unable to route when >> the corresponding link fails. >> >> OF0 has a parameter, MAXIMUM_RANK_STRETCH, which defines the >> maximum >> stretch between the associated Rank of members of its parent set. >> If the Rank associated with a route through a node's preferred > parent is >> R, then the node MUST NOT advertise a Rank greater than >> R + MAXIMUM_RANK_STRETCH. >> >> OF0 has two rules when selecting the DODAG Version of its parent > set. >> First, OF0 MUST select a parent set from a DODAG Version that has > the >> highest administrative preference among the DODAG Versions it is > aware >> of. Among the DODAGs with this highest administrative preference > value, >> OF0 MUST select a Grounded DODAG if one is available." >> >> > : the current text talks about stretching Rank to reach siblings without >> first saying how Rank is computed. Siblings are no longer a concept in > RPL. >> The concepts are neighbor set, parent set, and preferred parent. The > edit >> clearly states how preferred parents are selected, the parent set is > selected, >> etc. The statements about Grounded and administrative preference are > not >> normative, yet should be. The rule on MAXIMUM_RANK_STRETCH is now >> defined properly in line with how parent sets affect DIO processing. >> > > [Pascal] Note that the stretch is associated to siblings. It is the > stretch between Rank obtained from the preferred parent and a sibling, > not the license to go deeper to get an alternate parent, which would be > a bit greedy. I expected this text to go down the sink with the sibling > text. What you're doing here changes the meaning of stretch > considerably. This would be a new behavior and thus a new LC. But RPL does not have a concept of siblings! I know you love them but PLEASE don't try to reintroduce the concept. Doing so is tremendously confusing. We all agreed to remove siblings. You need to respect that decision rather than try to push RPL back in the direction you preferred. More generally, after reading OF0-07 very carefully, I think you need to re-read the DIO processing rules in RPL-19. The current OF0 text is based on a very old version of RPL (makes sense, given it's been around since then) and is no longer consistent with current descriptions of the protocol. > >> Reason >> Goal edit 4: >> >> Remove section 4: it contradicts itself several times. For example, 6 > says that >> one SHOULD use a newer DODAG Version; 9 says that one SHOULD use the >> existing DODAG Version. Furthermore, it is not clear that the actual > order >> specified is the right one (it is not based on any existing > implementations). >> Rule 4 is subsumed in the Goal edit 3 text, as is rule 5. Rule 7 > (minimize Rank) >> will cause route flapping because it comes before rule 10 (keep > existing >> preferred parent). > > [Pascal] There is no contradiction. This really boils down to 9 is > useless and can be safely removed. I think removing 9. makes sense. Part of the issue here is that all of the rules are SHOULDs. This means one can write an OF0 which follows none of them yet still follows the RFC. I see two ways of reconciling 7 and 10. 1) Tweak the text in 7 to say 7. When computing a resulting Rank for this node from a parent Rank and a Step of Rank from that parent, a parent that results in a significantly lower Rank than the current preferred parent SHOULD be preferred. or merge 7 and 10 7. The preferred parent that was already in use SHOULD be preferred, unless there is another element of the parent set which results in a significantly lower Rank, in which case this parent SHOULD be preferred. > > Rule 7 would cause flapping if the Rank changes are not dampened. But > the spec indicates that they should be. 10 before 7 would lock to a > parent forever. > > Finally this text was reviewed by the group and is normative. > So it was implemented by those who implemented OF0. We did not get a > feedback that the order was wrong. > And since we passed LC, I'm not anxious to make any change there (but > remove the useless 9). I don't think this is the correct way to interpret the process. We are in LC now. The prior version, which passed LC, said "OF0 is not for wireless." This version says that OF0 can be used for wireless. So I am giving technical comments that allow it to make that claim. Can someone who has implemented OF0 to follow the rules in Section 4 speak up and attest to their correctness? They seem to contradict what I understand distance vector calculations in wireless networks normally do. Of course, since all of the rules in 4 are SHOULDs, it is possible to write any algorithm and have it "follow" OF0. That doesn't mean we shouldn't try to provide guidance on what is the right thing to do in the general case. > >> Goal edit 5: >> >> Remove section 5: the abstraction of a parent set in the RPL core >> specification removes the need for a backup next hop: every element of > the >> parent set is a backup next hop. This section could be rewritten to > reflect a >> parent set, but Goal edit 3 addresses this somewhat. > > [Pascal] OF0 only requires one backup. But I agree it does not preclude > having more. And I agree that alt parents are all possible backups. But > I want to insist that a backup is not necessarily a parent. Please read the DIO processing rules of RPL-19. By definition, it may need to be, because of the rules on MaxRankIncrease. > >> If you think section 4 and 5 should stay, I can try a rewrite that > would make >> them consistent with the DIO processing rules in -19 as well as not >> contradictory and applicable to wireless networks. > > [Pascal] I do not think we have choice about that: the sections are > normative and should stay consistent to what they were at LC, unless we > have an IESG issue. Please note as above, we are in LC. The point of this LC is to make sure that OF0 can be applied to wireless, because of changes in the RPL spec in IESG review that made OF0 a SHOULD. The fact that it went through LC when it said it was not intended for wireless is not particularly relevant. > Text improvements that reduce the chances for a misunderstanding within > those constraints are welcome. I think you are incorrectly constraining the document. Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Thu Mar 17 00:07:07 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02CBE3A6A3E for ; Thu, 17 Mar 2011 00:07:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.494 X-Spam-Level: X-Spam-Status: No, score=-10.494 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHdwEhSPzwFw for ; Thu, 17 Mar 2011 00:07:01 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 57A883A67AE for ; Thu, 17 Mar 2011 00:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=15651; q=dns/txt; s=iport; t=1300345708; x=1301555308; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=M9V6qayLa/1/I6Aa3yuz78x1VqiCjIZWmY86CMcwK+s=; b=c3+EApdeqOziT9UXMQ0ziRSct89NCyy6GQkBnvUkv7VR8IYzhK5N+ten hbR5tmEXLo+j/71kGS6xwPpqtVsGGEl5FRgkrwQFYWyVr8YjERbUsyVyx 0kgeEKRUyGQff6N85xctbC4/YvetB2NQM6kNFT5axvhkkIa1foY8t6zXx w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah0BAPVPgU2Q/khLgWdsb2JhbACCW5VBjTIUAQEWJiWnGJw1hWMEkDE X-IronPort-AV: E=Sophos;i="4.63,198,1299456000"; d="scan'208,217";a="22058107" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 17 Mar 2011 07:08:26 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2H78Qrd022943; Thu, 17 Mar 2011 07:08:26 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 08:08:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE472.1C762287" Date: Thu, 17 Mar 2011 08:08:22 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0423EDB4@XMB-AMS-107.cisco.com> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF0231EC65@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I flag inconsistency in rpl-metrics-19 ? Thread-Index: Acvjvel74ULcY3YaQrWTlerBMyJl4gANvuyAAB9ChuA= References: <8E09C72DBC577D489F13A71228C0B7BF0231EC65@ftrdmel0.rd.francetelecom.fr> From: "Pascal Thubert (pthubert)" To: , , X-OriginalArrivalTime: 17 Mar 2011 07:08:26.0886 (UTC) FILETIME=[1CAF8260:01CBE472] Subject: Re: [Roll] I flag inconsistency in rpl-metrics-19 ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 07:07:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE472.1C762287 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Dominique: =20 Don't worry about RFC erratum, we still have to go to RFC editor, and = the chairs can still provide an editor note with the fix... =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = dominique.barthel@orange-ftgroup.com Sent: Wednesday, March 16, 2011 5:21 PM To: c.chauvenet@watteco.com; roll@ietf.org Subject: Re: [Roll] I flag inconsistency in rpl-metrics-19 ? =20 Hello Cedric, =20 Good catch ! A quick response : just looking at your mail and the quoted text, my = take is that 4.4.1 is wrong, as you suspected. We'll probably have to do an erratum after RFC publication, because I = don't think this mistake justifies for a complete document respin = including WG last call, etc. =20 However, regarding section 3.2, I think it is correct. The idea is that, = if the first sub-object is an EXCLUDE (resp. INCLUDE), it should exclude = from (resp. add to) an initially FULL (resp. EMPTY) set. It does not = make sense to exclude a subset of a empty set, or to add a subset to a = full set, does it? =20 I'll give it a more thorough look shortly. Thanks a lot =20 Dominique =20 ________________________________ De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = C Chauvenet Envoy=E9 : mercredi 16 mars 2011 10:39 =C0 : 'roll@ietf.org' Objet : [Roll] I flag inconsistency in rpl-metrics-19 ? Hi all,=20 =20 Reading the routing-metrics-19 draft I noticed something odd about the I = flag in the NE and the LC sub-Object : =20 In the NE sub Object (Section 3.2) : " I (Included): the I bit is only = relevant when the node type is used as a constraint. [...]. When set, this indicates that nodes of the = type specified in the node type field MUST be included. Conversely, when cleared, this indicates that nodes of type specified in the node type field MUST be excluded." =20 In the LC object (section 4.4.1) : " I Bit: The I bit is only relevant = when the Link Color is used as a constraint. When cleared, this indicates that links with the specified color must be included. When set, this indicates that links with the specified color must be excluded." =20 I guess there an inversion in the latter definition. =20 Furthermore at the end of the section 3.2 : " If the NE object comprises = several sub-objects when used as a constraint, each sub-object adds or subtracts node subsets as the sub-objects are parsed in order. The initial set (full or empty) is defined by the I bit of the first sub-object: full if that I bit is an exclusion, empty if that I bit is an inclusion." =20 Behavior of the I flag in this case seems conflitcting with the wording, = or I missed something ? =20 Maybe editors of the document could clarify this. =20 C=E9dric. =20 ------_=_NextPart_001_01CBE472.1C762287 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Dominique:

 

Don’t worry about = RFC erratum, we still have to go to RFC editor, and the chairs can still = provide an editor note with the fix…

 

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = dominique.barthel@orange-ftgroup.com
Sent: Wednesday, = March 16, 2011 5:21 PM
To: c.chauvenet@watteco.com; = roll@ietf.org
Subject: Re: [Roll] I flag inconsistency in = rpl-metrics-19 ?

 

He= llo Cedric,

 

Go= od catch !

A = quick response : just looking at your mail and the quoted text, my take = is that 4.4.1 is wrong, as you suspected.

We= 'll probably have to do an erratum after RFC publication, because I = don't think this mistake justifies for a complete document respin = including WG last call, etc.

 

Ho= wever, regarding section 3.2, I think it is correct. The idea is that, = if the first sub-object is an EXCLUDE (resp. INCLUDE), it = should exclude from (resp. add to) an initially FULL (resp. = EMPTY) set. It does not make sense to exclude a subset of a empty = set, or to add a subset to a full set, does it?

 

I'= ll give it a more thorough look shortly.

Th= anks a lot

 

Do= minique

 

De : = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part = de C Chauvenet
Envoy=E9 : mercredi 16 mars 2011 = 10:39
=C0 : 'roll@ietf.org'
Objet : [Roll] = I flag inconsistency in rpl-metrics-19 ?

Hi all,

 

Reading the routing-metrics-19 draft I noticed something odd = about the I flag in the NE and the LC sub-Object = :

 

In the NE sub Object (Section 3.2) : " I (Included): = the I bit is only relevant when the node type is

used as a constraint. = […]. When set, this indicates that nodes of the = type

specified in the node = type field MUST be included. Conversely,

when cleared, this = indicates that nodes of type specified in the

node type field MUST be = excluded."

 

In the LC object (section 4.4.1) =  : " I Bit: The I bit is only = relevant when the Link Color is used as a

constraint. When = cleared, this indicates that links with = the

specified color must be = included. When set, this indicates = that

links with the specified = color must be excluded."

 

I guess there an inversion in the = latter definition.

 

Furthermore at the end of the section 3.2 : " If the NE = object comprises several sub-objects when used as = a

constraint, each = sub-object adds or subtracts node subsets as the

sub-objects are parsed in = order. The initial set (full or empty) is

defined by the I bit of = the first sub-object: full if that I bit = is

an exclusion, = empty if that I bit is an = inclusion."

 

Behavior of the I flag in this = case seems conflitcting with the wording, or I missed something = ?

 

Maybe editors of the document could clarify = this.

 

C=E9dric.

 

------_=_NextPart_001_01CBE472.1C762287-- From jpv@cisco.com Thu Mar 17 00:59:13 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B8D93A6407 for ; Thu, 17 Mar 2011 00:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.49 X-Spam-Level: X-Spam-Status: No, score=-109.49 tagged_above=-999 required=5 tests=[AWL=-1.109, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, TVD_SPACE_RATIO=2.219, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SxJQ9IPDhOlp for ; Thu, 17 Mar 2011 00:59:12 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id EEC123A682E for ; Thu, 17 Mar 2011 00:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=70; q=dns/txt; s=iport; t=1300348839; x=1301558439; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=9NvXRCLc2ALY6G3yQrst1m6P0w7bu6emqjvf7DSCZTM=; b=MyUL0/ty7p8/GJUOQnyQShqVEiZeTPI6P9eLkfVDm9jI/IXJ5qYYFxQz YQJ7aosfokuP25GVVgZ15VNkyT0PYbLc3jxVIFVVfQ8RlneVyqzaKyKZv yUtfIMWQ5XLpCu7netvw5LckcedkisdRUu7yklpOOLmvPp5hrCYZF3z23 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApsIAOFcgU2tJXG9/2dsb2JhbAClTHMEiEUBnwucJ4VjBIUvhy+DTQY X-IronPort-AV: E=Sophos;i="4.63,198,1299456000"; d="scan'208";a="321258185" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-2.cisco.com with ESMTP; 17 Mar 2011 08:00:38 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2H80ci8014396 for ; Thu, 17 Mar 2011 08:00:38 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 01:00:37 -0700 Received: from [10.2.59.95] ([10.21.123.191]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 01:00:37 -0700 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Thu, 17 Mar 2011 01:00:36 -0700 Message-Id: <55878119-E0DB-4BE2-9FE4-1270409576AD@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 17 Mar 2011 08:00:37.0840 (UTC) FILETIME=[66E12D00:01CBE479] Subject: [Roll] Agenda slightly updated X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 07:59:13 -0000 http://www.ietf.org/proceedings/80/agenda/roll.txt Thanks. JP. From pthubert@cisco.com Thu Mar 17 01:43:11 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E889B3A6806 for ; Thu, 17 Mar 2011 01:43:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lH+P+2p5gP1c for ; Thu, 17 Mar 2011 01:43:10 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id BAA303A67F4 for ; Thu, 17 Mar 2011 01:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=11702; q=dns/txt; s=iport; t=1300351477; x=1301561077; h=mime-version:subject:date:message-id:in-reply-to: references:from:to:cc; bh=oiKsG+OgwgwB8uBbAtWhXzRCQT08gv1J0wzLHM/oDhk=; b=iEfNcW6+e0v8XO67HCVvL8nAqeRauJoayEqHxrCvQznflGfOT1VgLdD2 WhxynpKvb/CPQTBr1yT0mpi2/XdkeAb98V4vpEfb8SEmFXxGfO2mRfe4q Kg7l+gFd5WeXtOxu61ks5OdIuCjWjB63jV1gX4Y7TZN7i1YFcPgJBYaBf 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aq4EADZmgU2Q/khMgWdsb2JhbAClTBQBARYmJagKnCKFYwSQMYhu X-IronPort-AV: E=Sophos;i="4.63,198,1299456000"; d="scan'208";a="22074042" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 17 Mar 2011 08:44:36 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2H8iaUA025573; Thu, 17 Mar 2011 08:44:36 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 09:44:36 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CBE47F.8BA913A7" Date: Thu, 17 Mar 2011 09:44:18 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0423EE17@XMB-AMS-107.cisco.com> In-Reply-To: <9F3EA16A-3390-4FEE-9EA3-96018FBB7CF2@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-07.txt Thread-Index: Acvj9Rx1UNG1r7npTBSvhdbpon6RkwAfS5bQ References: <20110314094501.1366.59375.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D041A22B7@XMB-AMS-107.cisco.com> <9F3EA16A-3390-4FEE-9EA3-96018FBB7CF2@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 17 Mar 2011 08:44:36.0878 (UTC) FILETIME=[8BDE6AE0:01CBE47F] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 08:43:12 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE47F.8BA913A7 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Phil > > The term instantiated here refers to the fact that RPL as a protocol > > has a generic core. To turn it into an runnable protocol, it has to be > > instantiated by adding and OF. The result is a protocol. > > Your words are correct but refer to a different thing. A RPL instance > > is a runtime construct. There is no need to redefine it here. >=20 > I think this is -- at least to me -- a confusing use of the word "instantiate." > Adding an OF doesn't instantiate RPL: having a DODAG Root does. Of course, > for a DODAG Root to exist there must be an OF selected for the > corresponding RPL instance. Or are you saying you can have zero nodes yet > have a RPL instance? The problem is that "RPL Instance" is defined in -19 as: >=20 > RPL Instance: A set of one or more DODAGs that share a > RPLInstanceID. A RPL node can belong to at most one DODAG in a > RPL Instance. Each RPL Instance operates independently of > other RPL Instances. This document describes operation within > a single RPL Instance. >=20 > When I read "instantiate" I think "make a RPL Instance." Adding an OF to RPL > does not create a RPL Instance, right? [Pascal] Yes. I do see why you feel that instantiate is ill chosen.=20 I'm trying to convey the message that OF is an abstract interface that needs to be implemented. When an OF is plugged in, RPL becomes a complete protocol. IOW, RPL is really a generic class of protocol, that cannot run by itself. The difference between this and classical TLVs in other protocols is that the OF implies executable code. Suggestion? >=20 > > > >> > >> Reason: "honor" is inaccurate, that suggests one could not follow it. > > It is not > >> clear what "problem" the sentence refers to. "by the adding" is > >> grammatically incorrect. I think the new sentence more clearly and > > accurately > >> says what the existing one is trying to. > > > > [Pascal] the grammar will be fixed by the RFC editor. Maybe achieve > > would be better than honor? > > >=20 > I think "meet" would possibly make more sense. But regardless, the second > sentence doesn't make a lot of sense as it is. [Pascal] OK > > > > [Pascal] Well yes it is true. But we are referring to different things. >=20 > Please refer to the RPL Instance definition above. [Pascal] This text does not have 'RPL Instance' . But then again I can see why you feel we should avoid the term instantiate. > > [Pascal] I suggest we discuss the sibling separately, see if the > > resolution is to introduce them in this spec or remove all that's > > related to sibling. > > This being said, I can agree that we do not need to define Rank > > anymore that we need to define RPL Instance. I'm fine with the removal > > though the existing text does not hurt IMHO. >=20 > There was a long discussion among the WG and authors remove the concept > of siblings from RPL because they were confusing and not actually relevant to > the protocol as it's now defined: they were another abstraction that just > make the whole thing more complicated. Reintroducing the concept here > seems contrary to that consensus. [Pascal] The sibling discussion is happening. Note that there was no consensus but a shepherd decision. > > [Pascal] this paragraph was added to clear things up based on your > > comments (and Om's) I could remove the first half though again I do > > not see any arm in it. > > The second half " This specification can be used ... " seems a bit > > more important unless you consider that all metrics can be turned into > > an additive step of rank? >=20 > I don't think it's necessary. All that's needed is the clear statement (which the > draft has) that OF0 ignores metric containers. [Pascal] Mr Hof has similar wording. I find it useful though no designed in his right mind would use step of rank that cannot be added up. So I do not mind either way. > > [Pascal] Note that the stretch is associated to siblings. It is the > > stretch between Rank obtained from the preferred parent and a sibling, > > not the license to go deeper to get an alternate parent, which would > > be a bit greedy. I expected this text to go down the sink with the > > sibling text. What you're doing here changes the meaning of stretch > > considerably. This would be a new behavior and thus a new LC. >=20 > But RPL does not have a concept of siblings! I know you love them but > PLEASE don't try to reintroduce the concept. Doing so is tremendously > confusing. We all agreed to remove siblings. You need to respect that > decision rather than try to push RPL back in the direction you preferred. [Pascal] The question here is the stretch. All I'm saying is that the stretch was defined by OF 0 for the sibling operation. Sibling goes away =3D> = stretch goes away. >=20 > More generally, after reading OF0-07 very carefully, I think you need to re- > read the DIO processing rules in RPL-19. The current OF0 text is based on a > very old version of RPL (makes sense, given it's been around since then) and > is no longer consistent with current descriptions of the protocol. [Pascal] I can do the exercise, no problem. But at the moment I do not see an issue. > > [Pascal] There is no contradiction. This really boils down to 9 is > > useless and can be safely removed. >=20 >=20 > I think removing 9. makes sense. [Pascal] Agreed. I don't see a problem to remove it. Anyone? >=20 > Part of the issue here is that all of the rules are SHOULDs. This means one can > write an OF0 which follows none of them yet still follows the RFC. >=20 > I see two ways of reconciling 7 and 10. >=20 > 1) Tweak the text in 7 to say >=20 > 7. When computing a resulting Rank for this node from a parent Rank > and a Step of Rank from that parent, a parent that results in a significantly > lower Rank than the current preferred parent SHOULD be preferred. >=20 [Pascal] looks good > or merge 7 and 10 >=20 >=20 > 7. The preferred parent that was already in use SHOULD be preferred, > unless there is another element of the parent set which results in a > significantly lower Rank, in which case this parent SHOULD be preferred. >=20 [Pascal] Not as good because the same parent check currently comes after 8 and 9. This brings it up 2 steps. > > Finally this text was reviewed by the group and is normative. > > So it was implemented by those who implemented OF0. We did not get a > > feedback that the order was wrong. > > And since we passed LC, I'm not anxious to make any change there (but > > remove the useless 9). >=20 > I don't think this is the correct way to interpret the process. We are in LC > now. The prior version, which passed LC, said "OF0 is not for wireless." This > version says that OF0 can be used for wireless. So I am giving technical > comments that allow it to make that claim. >=20 > Can someone who has implemented OF0 to follow the rules in Section 4 > speak up and attest to their correctness? They seem to contradict what I > understand distance vector calculations in wireless networks normally do. Of [Pascal] Could you please elaborate?=20 > course, since all of the rules in 4 are SHOULDs, it is possible to write any > algorithm and have it "follow" OF0. That doesn't mean we shouldn't try to > provide guidance on what is the right thing to do in the general case. [Pascal] My implementation follows this logic. It was tested in wired and wireless environments though not on 802.15.4. > > [Pascal] OF0 only requires one backup. But I agree it does not > > preclude having more. And I agree that alt parents are all possible > > backups. But I want to insist that a backup is not necessarily a parent. >=20 > Please read the DIO processing rules of RPL-19. By definition, it may need to > be, because of the rules on MaxRankIncrease. [Pascal]=20 The transition between a version and the next requires to be able to send to a parent on the next version when self has not made the step yet. I'll review the MaxRankIncrease text in that light but I do hope there's no contradiction. > > [Pascal] I do not think we have choice about that: the sections are > > normative and should stay consistent to what they were at LC, unless > > we have an IESG issue. >=20 > Please note as above, we are in LC. The point of this LC is to make sure that > OF0 can be applied to wireless, because of changes in the RPL spec in IESG > review that made OF0 a SHOULD. The fact that it went through LC when it > said it was not intended for wireless is not particularly relevant. [Pascal] LC was terminated on the 10th of March. We are actually fixing the issues that were opened but not resolved at that time. It seems that the shepherd (JP) agrees to reopen the sibling discussion, but we cannot rework the whole doc.=20 And the RFC editor will fix the language, don't worry about that. Pascal ------_=_NextPart_001_01CBE47F.8BA913A7 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from xbh-ams-201.cisco.com ([144.254.75.7]) by xmb-ams-107.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 18:08:46 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Received: from xbh-bgl-411.cisco.com ([72.163.129.201]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 18:08:45 +0100 Received: from xfe-bgl-411.cisco.com ([72.163.129.199]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 22:38:44 +0530 Received: from [10.60.114.226] ([10.60.114.226]) by xfe-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 10 Mar 2011 22:38:43 +0530 Content-class: urn:content-classes:message Subject: Re: [Roll] Working Last Call on draft-ietf-roll-of0-05 Date: Thu, 10 Mar 2011 18:08:42 +0100 Message-ID: <9D77E69E-F909-40B2-BB4B-8075FD27E256@cisco.com> In-Reply-To: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Working Last Call on draft-ietf-roll-of0-05 Thread-Index: AcvfRdEXV13qFGwwR7qz9v9RM4HFzw== References: <6CACEF76-BB4D-4DB8-A144-C4DB6279CAF2@cisco.com> From: "JP Vasseur" To: "Pascal Thubert (pthubert)" Cc: "ROLL WG" Dear all, This terminates the WG LC. Pascal, I think that you answered one of the = comments and asked for clarification on the second one. Could you get in touch = with Phil who commented, make sure that you addressed his point (I think that there = still one unresolved issue) and post the new revision ? Thanks. JP. On Feb 22, 2011, at 9:03 AM, JP Vasseur wrote: Dear all, This document has been stable for quite some time and the latest = revision has addressed all comments received so far. This starts a = 2-week Working Group Last call on draft-ietf-roll-of0-05, that will end = on March 8 at noon ET. Please send your comments to the authors and copy the mailing list. Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------_=_NextPart_001_01CBE47F.8BA913A7-- From jpv@cisco.com Thu Mar 17 03:12:19 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C9C3A6869 for ; Thu, 17 Mar 2011 03:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.483 X-Spam-Level: X-Spam-Status: No, score=-110.483 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uq5vbWvo5y9T for ; Thu, 17 Mar 2011 03:12:18 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 61B3A3A6839 for ; Thu, 17 Mar 2011 03:12:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=297; q=dns/txt; s=iport; t=1300356826; x=1301566426; h=mime-version:subject:from:in-reply-to:date: content-transfer-encoding:message-id:references:to; bh=XcD8nQdOj/E86glG56NZ7bjsY2NxctivRlF2VAHQFXw=; b=F9P6dIYuWUuYdlqkUtrPLWDq8ngccID872WS9soP4JCZBGrHKdhH4qWl 1htLEG2dzPpuNEQr7/cA+5HdGgggeFLkNvg6+f1NfQnx7ADaljOaXfMDA SHYOgXfU4nDsrdqsrcnF0T1mN4hiGtGwuUZ/vCZqCx0Y8xjHz10gjJ/4q Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAJ8gU2tJXG8/2dsb2JhbAClTHeoHZwihWMEhS+HL4NNBg X-IronPort-AV: E=Sophos;i="4.63,198,1299456000"; d="scan'208";a="279029926" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by sj-iport-3.cisco.com with ESMTP; 17 Mar 2011 10:13:46 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by rcdn-core2-1.cisco.com (8.14.3/8.14.3) with ESMTP id p2HADjHR023366 for ; Thu, 17 Mar 2011 10:13:45 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); Thu, 17 Mar 2011 03:13:45 -0700 Received: from [10.2.59.95] ([10.21.123.191]) by xfe-sjc-232.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 17 Mar 2011 03:13:44 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: JP Vasseur In-Reply-To: <55878119-E0DB-4BE2-9FE4-1270409576AD@cisco.com> Date: Thu, 17 Mar 2011 03:13:44 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <55878119-E0DB-4BE2-9FE4-1270409576AD@cisco.com> To: ROLL WG X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 17 Mar 2011 10:13:44.0848 (UTC) FILETIME=[FF81E100:01CBE48B] Subject: Re: [Roll] Agenda slightly updated X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 10:12:19 -0000 + slot added to discuss OF0. On Mar 17, 2011, at 1:00 AM, JP Vasseur wrote: > http://www.ietf.org/proceedings/80/agenda/roll.txt > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Thu Mar 17 09:12:38 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7AD763A69B2 for ; Thu, 17 Mar 2011 09:12:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.292 X-Spam-Level: X-Spam-Status: No, score=-9.292 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JREKL8EF1-gS for ; Thu, 17 Mar 2011 09:12:29 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id F3AAD3A6983 for ; Thu, 17 Mar 2011 09:12:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=30724; q=dns/txt; s=iport; t=1300378436; x=1301588036; h=mime-version:subject:date:message-id:from:to; bh=DeaSW7S2028dZ0wMJDheVdEjsRxrIL0lwp4P9Yf+orM=; b=Nhu9Rw+k2ldLiqQIGPYNrFqdixw6ueBvQI9NfQ7Mh+6tG/4GoPAwu+IO dyrRWMICYIbwP1yFMEXMd8IEZH5NIrFsicsEEkbZZs5kKyiX2o7UUXLIj FVFKYgSOeFk0aWF0D7ivj0mQ0o+L/pUgtcmOpyJ77Wv+leNBJ5svgpBcK w=; X-Files: image001.jpg, image002.gif : 7606, 490 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngCAK/PgU2Q/khNgWdsb2JhbACCC1CVQo0xFAEBCwsmJacwnECFYwSHZoIjhig X-IronPort-AV: E=Sophos;i="4.63,200,1299456000"; d="gif'147?jpg'147,145?scan'147,145,208,217,147,145";a="22144665" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 17 Mar 2011 16:13:55 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2HGDtnc014570; Thu, 17 Mar 2011 16:13:55 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 17:13:55 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CBE4BE.5016DBC7" Date: Thu, 17 Mar 2011 17:13:50 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0423F100@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [Spam] DAO No-Path in a storing mode Thread-Index: Acvkvkv5WMkOvK4mRFulxe9F09JB4w== From: "Pascal Thubert (pthubert)" To: "C Chauvenet" , "M Pouillot" , X-OriginalArrivalTime: 17 Mar 2011 16:13:55.0096 (UTC) FILETIME=[50380980:01CBE4BE] Subject: Re: [Roll] [Spam] DAO No-Path in a storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 16:12:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE4BE.5016DBC7 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBE4BE.5016DBC7" ------_=_NextPart_002_01CBE4BE.5016DBC7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Cedric: =20 When a parent has 2 children for a same target, and it gets a no-path = DAO for that target from one of those children, then it should clear its = adjacency for that child but keep the RIB entry for that target via the = other child. As a result, it still has a route so it must not send a = no-path to its own parent. OTOH, if the node loses its last child for a = given destination, then it should send a no-path DAO to clean up. A = no-path DAO is still a DAO though the information is 'negative'. The = spec leaves some space for an node to be reactive to datapath validation = for that though. =20 Pascal http://www.xtranormal.com/watch/7011357/ = =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = C Chauvenet Sent: Tuesday, March 08, 2011 5:08 PM To: M Pouillot; 'roll@ietf.org' Subject: Re: [Roll] [Spam] DAO No-Path in a storing mode =20 Hi all,=20 =20 As mentionned in the mail below, the no-path DAO message usage in not = very clear in the RPL specification. Though it is important to clarify this because it is an important = feature for reliable and reactive downward routing. =20 Section 9.1.4 clearly states that DAO massages MUST be sent on a link = local address, thus limiting the no-path DAO destination set to one hop = neighboring. But given that this message should advertise that a = downward path is no longer usable, how do you propagate this information = in the upward direction to erase that path ? =20 For instance how do you prevent the DAGroot (located several hop away) = to use a broken downward path if you can send the no-path DAO to you = link local scope only ? =20 Some papers says that the no-path DAO must be sent to the root, but this = seems contradictory with the 9.1.4 section I pointed out (DAO are link = local only in storing mode). =20 I would appreciate that people shed some light on this .. =20 Thanks=20 =20 C=E9dric. =20 =20 De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = Mathieu Pouillot Envoy=E9 : lundi 10 janvier 2011 09:09 =C0 : roll@ietf.org Objet : [Spam] [Roll] DAO No-Path in a storing mode =20 Hello , In the specification, for storing mode, it is specified that a device = should send a DAO no-path to a node which is removed from the DAO parent = set (9.8.4). For me a node is removed from the DAO parent set if it is = unreachable on link-local and so I can't send a DAO no-path to this = node. A solution to inform the old DAO parent should be to send the = No-path on the global address but it is not allowed by the specification = (9.1.4-in storing mode DAO message MUST be link-local-). So only the = lifetime will remove the route from the old DAO parent, that can take = few minutes depends of the DAO lifetime setting. What do you think about that? best regards, Mathieu --=20 =20 Mathieu POUILLOT=20 R&D Engineer=20 m.pouillot@watteco.com =20 Direct line : +33(0)4 98 01 60 05=20 Tel : +33(0)4 98 01 60 05 Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE - France=20 www.watteco.com =20 Before printing think about environment and costs=20 This Message may contain confidential information intended only for the = use of the addressee named above. If you are not the intended recipient = of this message you are hereby notified that any use, dissemination, = distribution or reproduction of this message is prohibited. If you = received this message by mistake, please notify the sender by reply = email immediately. Please conduct your own virus checks before opening = any attachment as Watteco does not guarantee the integrity of this email = or attached files has been maintained nor this communication is free of = viruses, interceptions or interference. Any views expressed in this = message are those of the individual sender and may not necessarily = reflect the views of Watteco. Watteco shall not be responsible nor = liable for the improper and incomplete transmission of the information = contained in this communication nor for any delay in its receipt or = damage to your system. =20 ------_=_NextPart_002_01CBE4BE.5016DBC7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Signature 3

Hi Cedric:

 

When a parent has 2 children for a same target, and it gets a no-path = DAO for that target from one of those children, then it should clear its = adjacency for that child but keep the RIB entry for that target via the = other child. As a result, it still has a route so it must not send a = no-path to its own parent. OTOH, if the node loses its last child for a = given destination, then it should send a no-path DAO to clean up. A = no-path DAO is still a DAO though the information is = ‘negative’. The spec leaves some space for an node to be = reactive to datapath validation for that though.

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of C Chauvenet
Sent: Tuesday, March 08, 2011 5:08 = PM
To: M Pouillot; 'roll@ietf.org'
Subject: Re: = [Roll] [Spam] DAO No-Path in a storing = mode

 

Hi all,

 

As mentionned in the mail below, the no-path DAO message usage in not = very clear in the RPL specification.

Though it is important to clarify this because it is an important = feature for reliable and reactive downward = routing.

 

Section 9.1.4 clearly states that DAO massages MUST be sent on a link = local address, thus limiting the no-path DAO destination set to one hop = neighboring. But given that this message should advertise that a = downward path is no longer usable, how do you propagate this information = in the upward direction to erase that path ?

 

For instance how do you prevent the DAGroot (located several hop = away) to use a broken downward path if you can send the no-path DAO to = you link local scope only ?

 

Some papers says that the no-path DAO must be sent to the root, but = this seems contradictory with the 9.1.4 section I pointed out (DAO are = link local only in storing mode).

 

I would appreciate that people shed some light on this = ..

 

Thanks

 

C=E9dric.

 

 

De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part = de Mathieu Pouillot
Envoy=E9 : lundi 10 janvier 2011 = 09:09
=C0 : roll@ietf.org
Objet : [Spam] = [Roll] DAO No-Path in a storing mode

 

Hello ,

In the = specification, for storing mode, it is specified that a device should = send a DAO no-path to a node which is removed from the DAO parent set = (9.8.4). For me a node is removed from the DAO parent set if it is = unreachable on link-local and so I can't send a DAO no-path to this = node. A solution to inform the old DAO parent should be to send the = No-path on the global address but it is not allowed by the = specification  (9.1.4-in storing mode DAO message MUST be = link-local-). So only the lifetime will remove the route from the old = DAO parent, that can take few minutes depends of the DAO lifetime = setting.
What do you think about that?

best = regards,

Mathieu

--

= 3D"Description:=

= Mathieu POUILLOT =
R&D Engineer

m.pouillot@wat= teco.com=

Direct = line : +33(0)4 98 01 60 05 =

= Tel= : +33(0)4 98 01 60 05
Fax : +33(0)4 = 94 14 10 80

1766 Chemin de la Planquette
83130 LA GARDE = – France
www.watteco.co= m=

3D"Description:= Before printing think about environment = and costs

This Message may contain = confidential information intended only for the use of the addressee = named above. If you are not the intended recipient of this message you = are hereby notified that any use, dissemination, distribution or = reproduction of this message is prohibited. If you received this message = by mistake, please notify the sender by reply email immediately. Please = conduct your own virus checks before opening any attachment as Watteco = does not guarantee the integrity of this email or attached files has = been maintained nor this communication is free of viruses, interceptions = or interference. Any views expressed in this message are those of the = individual sender and may not necessarily reflect the views of Watteco. = Watteco shall not be responsible nor liable for the improper and = incomplete transmission of the information contained in this = communication nor for any delay in its receipt or damage to your = system.

 

------_=_NextPart_002_01CBE4BE.5016DBC7-- ------_=_NextPart_001_01CBE4BE.5016DBC7 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAWgAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAIRwAADmgAABSuAAAdtP/bAIQAAQEBAQEBAQEBAQIBAQECAgIBAQICAgICAgICAgMC AwMDAwIDAwQEBAQEAwUFBQUFBQcHBwcHCAgICAgICAgICAEBAQECAgIFAwMFBwUEBQcICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI/8IAEQgAoAD8AwERAAIR AQMRAf/EAO0AAQACAgMBAQAAAAAAAAAAAAACAwEEBQYHCAkBAQABBQEBAAAAAAAAAAAAAAABAgME BgcFCBAAAQQCAQQDAAICAwAAAAAAAAERAgMEBQYQQBIVMCETIAdQFnCAMREAAgEBBQMIBQoEBgMA AAAAAQIDBAARIRIFMVETQEHRIjKTFDQQYXFCBiCBkaGxUpIjMzVygkNTcPCi0nMkg5QVEgABAwMD AwUAAAAAAAAAAAABABEyEECRICECMVESUHCQYXETAQACAQIEBQQDAQEBAQAAAAEAESExYRBBUXEg MECBkaGx0fHwweFQYHCA/9oADAMBAAIRAxEAAAH9QuIVAAAAAAD27rrnvZjoQhum4bSdymNk2obC NiF5ZCwuhIyfMvz5IAAAAAGD6G7jHLek83Jm4bJsTOxEbBaWlpMkCwA+auAyAMHmGwVcZ6E+javT zuPAAE630f3iFbzU2zbNg2Zm6I2i4sLCRIyTAPnHg8gdazJ+Ue53tXb7lNin27ULPsvCqOQoADnv ae4dejjzoxtm0bJsFxeXFhaTBIkAfPPDpHG3XUOtT8kdByPSMKn6K8i1y+o07XMVoAPRN5j0LeHX TrxtmyXpvReXFpYWEwTMgHgPFZHEbe+jN7j4TzK/qbGp4HDjieOTbUAEqntnW45DNdKNc2i82Jm2 I2C0uJkyQJmQDwvjgdI2SeX2R9De3HmuO6xr87eiQAB2nY3pfQGmdOLjaLi8sLi4sLCRIEzIB4py WQOt7M7DsceM6TOpYctjLTZPTrS+89Z6XG7lusGiWmwWpuRcWFpMmWAEzIB49y0NWp1O5OjecRbd dtuxY7hbiMvc7bv+6x2bYGkdZLS0uLU2IuLSZYSJAmZAB5RzaR1mt5/QkadTJydtuQxW939+O47U gdaIFhYWlpMsLCwkWAEzIAPMufAAAAOw+47XshLgzVLCZMmXEyRMmSJgFgAB55o4AACdTsvvub9d g4k0yZMmSJFpYSJEiRkAsAAOjaeAAzLk/Qc97K+8icYa5IkSJEiRItJEiQMzMogZAAOoauGZbF9v Zjks9ddCk48iZJEjJIySMkiZMAmZAAANawnUtuMyArNUpMmTJIyZMmTJkySJAFgAAAAMESsqIAyD JIGTJkGTJkyACwAAAGsYMAGQDIMgGTJkGQADJkkAAACgAyAAZAMgAAEjIBkAAAAFYAABkAAGTIMg AAAAAAAAAAAAAAAAAAAAAAA//9oACAEBAAEFAvW689brz1uvPW689brz1uvPW689brz1uvPW689b rz1uvPW689brzWaLSzwPQaIv0+oS9NRqSOo1RHU6sTV6wTWa4TXa8TAwRMLDExMUTHxz8aT86zwi MnRhhhhhhhhhhhhumDHwwyxXuQQTonVPgYYYYX6S7mHH65JzbVvrtlr9tQwwwwxGCylFPGKqyf8A oiCCdEE+JhhjbbTD0uFscvN3sn+v0tlfxvim0zqMS9MvEYYYY1lP65xlS8aEQRCPRBhPiYYzMqjB xd5wrL2nHY32ZScg4vteLXf1Vp44+n3PIv8AYqoVwrgwwwxo6OmfL6RBBBhPkYYx8b2nI4W1XH9S 8d/Hacw43Dlei5n46zhcKoVQYYYYSKquLSmPQZE/0uYQTonyMMfryHV7D+v8NNPkNj4lfE+Uw5Ph 8ks9jvmGGGGNVjfpcXz/ADrYRBOiDCfGwwxTP1/K+cZflhb/AGuFqNhqeQ4CXw5bVZhw5frrEyOU 4mII0khXKyWPTHHqMmfnNhBE6IJ0T4mGLbqMeO09bsMPBitmdutTxje2Yen4dZfRgaKOLZo9Hjl+ i0ObbGCRTX4n5IX2fnFhuiDfMwxttRibnFq4Lp6sjE4PrMLG/wBC1sYLwPXSWHEKIrPi1U7cTiOu wjCxPJRVSKTks5MMMJ87DDDDDDDDGNhv1ts81YbsmGGGGGGEgsloxIw622eQw38U+ZhhhhhivElI hXCtBVYnNZDDDdmwx4uJRYpHFI1wh1lNEFVZDDdr+VZ4QT+KyRBZqo3d+SHmKqr1buPs++jdGG71 hhhvkbu2/wAn/9oACAECAAEFAvYXnsLz2F57C89heewvPYXnsLz2F57C89heewvPYXnsLzX3TWn9 JH6SP0kfpI/RTzU81PJTyU8lHHH7PDi1XbU6q+ZLQ5KFlMoL/GMXVEbtaMeVktfp66ek5pE2FULy UWX+Gvq8reyYYhWslwcZKCdjJTkeS3zeWZsI1jDDDDGnq7NhjU0/ZZY6RVi6fjFEGGGGGMerwh2T DGHmpVDAuWcCu2M02lrQYYYYY12O8uzYYY1cmllXeEMWcqy+SyXx+/AjFxCMHWmrwj2bDHiR8orf fOxUSSE65i1TPGRGuRGDGFjePasMJ9C+RJ1V1HUYSJ9mJi9swwwwwwwwxj4vbsMMMMMMJFynGbuG GGGGGIYyqQgidywwwlKkcYjBE7v80PBP+P8A/9oACAEDAAEFAnHHHHHHHHHHHHHHHHHH/wAo3fIn VV75FF75V/7uf//aAAgBAgIGPwKRypHKkcqRypHKkcqRypHKkcqRypHKkcqRypHKDn0AflvtxXRN yvPHin68qsdQtWC+09WEtR5WvlQUJ1tasnPWmy8e+p+1uQnThHkU2hk1u4W9GT6HN+5v3N/vfb+/ X//aAAgBAwIGPwL4gP/aAAgBAQEGPwLyEPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFvIQ90nRby EPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFqZpNHpXdhixp4idvst+ y0n/AK0P+20oGlUwAOA4EXRb9rp+5j6LftlP3MfRb9tp+5j6Lft0HdR9Fv2+Huk6LeRh7tOi3k4u 7Tot5SP8C28tH+BbfoJ+EW/SX6BbsD6Bbsi2zkFKu5F+z0SHex+3khYm5VxZuYCzJDVtqTpgwpIp Khb/AONBk/1W/MoK+FP7nhc4+iFnP1W8VptYlZADldkOKt91gcVPqPylUbWN302VRsWxO61/I3rq wnICFhgQZpJpW7MaDnY2z6ww8Pth0VDfTR/x/wB1vWcNwsFGCr2V3WSmpqaavq3VpBSU8TTScJO0 5C7FF/8Ak2qfi6nqzopMDjTIjEL65FGYNUrIL+HeOoMG578brUlWFyCqijlCbuIge76/kwDmQ5j/ AC+iT14fTyOesqTlhpxe9wvY8wAHOScALVms6gXT4looZKjQqGORuFSMFz8IhcJGkAySM1+3q3Wo E02nNdWaw0aaTRg3cR5Vzi88yqvWY8wFtLFdWx6jT6sGQVEcJhENUi8Th4s16st5U7cLVPxLOt1X 8SNnhY7UoIb1gX2ML5P5rT6P8PMW0+ozRap8Rj9IRnqulMf6jnZnHVXeThZI41yRxgLGm4AXAfJm qDz9VftPoRN+J5Hp1GwzUmjr4+sHMZsxiplPzh39qi0gjkWXhsUluIOVhtBu57a5WVKXj4WmqdI0 y/mZJyZHH/j4Sg+21TpHifBTOUekrguYwyI1+YD2Xj57Vun0KCPxMUOm6fFu8Uy0S3ewPfZIolyR xgLGgwAUYAfJAGJOwWji+6Ot7fQx5hgOR6rLo9FTVQ1hIAlbPMyeFeFWTrRqhMi43gAjHdtt8S6L xmqX40FfJVSfqTPWw5ZZG9bSwsbTS3LTxDNJUPcFG9mNnlkon0uuiytLp0hDNwZuvDKCNqyLj6je Oa2k6YvWg0YGurv+V1aCnX63b5h8rjN2Idn8XoJ5z2eS6VWHCDWIZaCc83FX/tQfZIPntS/D0Lf9 v4mkMDXbVo0Gepf8HV9rC2nzRVjaTq9I1NFSTiLiwyQ1sjRcORAy5ogY72xGW68Wigzz6nq/xCst a1Tw0jEzKTGii9rkvSI8JSeyu22nVyaNVtDqswgpPK352JAv/Owvym1UUglZqep8JHCpgaWWo4rQ 5VRZLxipxe4XY2qPE0VQn/z4km1i7hMKSOQsAXyvjgpbq34WvGI32VFF7NsssS8207z6Mo2JyTPP MsCY9Z2CjAZjt9Vp6WTUUp3Q5o6lZEEkE0Dq6ut/OjZbT6vq2qQahqnDWnWWMCKKGFXHVVC73ZnN 7G/E3bhaKXUalGkanqKWFlnC/l1ShWuu977p5rUtfR1SGqppKPwVVxBnTw9OqRRqW90o2I57zbSt Pi1JWj06oD0K8ZCxmjJa47+3avp5tceE8bxeQzQI9LO0xmDoQgbtP71+26zU9RrzzzVsccGpwiph BrUViyLKEUffu6t2ButcLcZx+Y3ZG4ejDtHZyUUdYCYQ6uQpuvy8x9RGBtQ1OeaR6BYVUM94k4Wb F8MS94Lb7haupIaio4eoRCKpJcFrgrC8G7A3tffvAtDHDWVEMcMvFCZ1IJzxuO0vNwh9douJWTyi IKuVjEQUVY0u7HOIVxtDm1KokWJYoyh4VzQQOkkcZuQdkoMdpsZxqVQknF8RERwepUFQjPjH7wGw 4WiWCSUJD2FLA/1IZd2+AWE0g6vuLv8AQSdgtmPzDlgklHV91N/puHZHK7lF53WzSdZuYcw9OUdn ld79QfXa5Rd6Lza73eUYW7N1us3zC3VW707zbHk/Zt2R8rdy3Z/g5//aAAgBAQMBPyHzhQoUKFCh QoUKFChQq6IF6Zarw+F9tAAPjhT8HhcxNpGBqhiBoUgNDgBoP8+kAYD+HSC0L+fSBaF/LpAtDgDo XsSjk88ABU6+2ve3gqBywwOAIcBDygodEUNA1VdCOiBAIcpge6jZHVjy/RZI8owXoj4gaCSHuqDp AA9ipd+gX4hlbVb4BxwHEOXE4GvjDm+iwTZlnTkFqgLFmYWUJk5a+eG6WqIxAoMAOQcoE/WY09Ng W6qBaqY28UxOQ0FSXUQzESC65Bt4QYg+w1/euFm5in0cBOAghwDlwNeIc/B2TsiIMrWZRsrAtVCB 9bKzrJXYDIoy9A0bD1tQ08p2lqbsmfSuLCZb1Jjz49KHXohd9sYfTBLpNo73JRgUoIaVw2AnZOyd k7JUA5H7f4cMf5qO2DgCGHAIEDSGsOJp4jGAvNLsBJGKMjWo1aheRmQyeOYM6gDZzinVehsLBd2d lLbgD0R0f5BCoDkAtANADHhAE7FdRYL9czqsv14cwvjSECCBwBCHKVDiaeI1QGk+FBF4mwoYzLSI QtRi1wwXRiOFsZYVdlZxasqquyLqUwOjAuVDT9QZczeqfK7meIGDPuFp8a8KX6Xcw6uAMQIIcA5c TiaeMXdzIUHsfY+4irwJr6IemznVeTZZngMiDa3yDGWES7rQza1J0QWHUZwLJtnlNdyrq7C9VFTK oTkog7TKZoXhtlQtmg0lhY0ZlM+cavDPnK9+cIExQIIIHAHl+sFGIHyM0Cu0oFS7jSSD1krQcMVX sx9jNkU8DAEsD6+lCzQd0tazCinGsWD37XZZQjrk7MdWncl0KNaLGBwAjWCmWeuSLkdhYW3LEgoK CchTk/lbw1VyfzhBAQwgIQOIeUWoq4cl4nOR5jNEWhe2HVGebpywmw/Avvol8CCyULTLUlDArkjn EW/lhu+4RnDVXLY+vNqJgWq6lryMi68wNxrwGwW0GKBqx5CZq/gb9tEJlubq7cHDrUjv8AQgg4FS oQh6MAactX9jhpljdot94QQECBAxAgcT0H89d9BKWrignzT14gQJUrgCVwCVXk9s7Z2ztnbC7QWu hKLsMd4M83gAsoJjWOjrxOyVKJUqEOFeCvJBaF+0++jiDrdDSDdz44H2I5a7E7OCpUqVKgVwIeCv I28NJ8RADQrwak56TFGHBUqVKlSuFSuJ56HOPRHMpUrgqVKZUqUcaZXnX1zulcFcSpXhqVK8dSvJ qVK8IVK8muCvR0ymUymUymVwUSj/AKP/2gAIAQIDAT8h/bvzP278z9u/M/bvzP278z9u/M/bvzP2 78z9u/M/bvzP278z9u/M/bvzP278xZRa6zeZvM3mbjN1m/N2b03uBeXlpcvjUqVKlSpUqVKlSpUq UfZ6KpUqVKhdpW+PvALo+5KiUypUqVKmE6ytXoqlSoHC1gNu5+OGrQKrTnzlgdJUqVKnYWfj0oA1 GZg7n+coEzUPAiHJ9nf8eIH2T0oC1yxwqnQiqybKkx+EBrRK7p9KJEK3c6vTwuDvlKAa/YeIGb6f d6cbo5l3zcu8e1DNnb++k5fOO3657xIrGO/4iiu1+0DQ66byjHqasMj6YEys1SAqUGhCMdb+IM6M /WWHqILT7d4AutNMadpQqVOc+nG6IkJ1lIvLh/z/AJ3ioNV7e013/Of5lnS9eALej64A6og56vXA 9IQXHqwvG8oHOaB6vbgHKV/8+//aAAgBAwMBPyG0tLS0tLS0tLS0tLS0tLS0tLS0tly5cuXL/wCZ TL+trirXrYYsvjt9eD/3z/8ATn//2gAMAwEAAhEDEQAAECSSSSSSZWyQojzwhEkkkkklqFAIABII AP8A9xL/AP8AVMBxAIIAANtPvnttAlI2AIAAAG7GFu23xgAgIBAAANkOCNthBhIYIJAAAG5lU222 BoG4BBAAAAAqTyQAMAMJAAAIAPztE74QtIMBAABAAJI3RDSIpI3JJABAALbbbadEAAwIIAAAACSS S+JpIOABJAIAAP8A/kgRASBgAQCiAABt8AAAQSOCSATgAACZAATSSAiSQAQAAAACBAQSCkACQAQA AAAASAQQCQCAAcgAAACSAAQSAAAQCQAAAAAASSAASAQAAAAAAAAAAAAAAAAAAAAAAAD/2gAIAQED AT8Q87Dhw4cOHDhw4cOHDhU3lwqwprjq8GRxgjgNUAhD1QZkAUG/sQEwEwRS7dafihHzm4wWlHLR 7YX2i6wWlFIT2QZO+CGPodH9oaPZi/qfQgL+oaYOwSiqrHSWlpaWlpaWlpaWlpaWjUXpHWKTG4v7 8A5Gu/dDpuwlYwOn8uHjeGw2/M16YESiic00E0+/A1O/gttLbS20ttKw9lEbpgBlVoiz8lyUpJTm aOc+ytXYCGzdorNSFEoNRtK9JbaW2ltpbaW2gJWL7gfvDioP2IfaHgCjsLmbkUndzNKnSPTnRMaJ y9py9pzT+qGpw0+/DS8FZWVgpqsKFTRDRQAyMNRr6NEdK7oESp0IBBVAMA5BHCaYlIDJU5SYE+Rp G2mGQA2AiRc9NgIqF6V86lZWVlZYVmWFgUb+DhnOu7Vf1YOKxAb0QYTcgyQEtIxpmc0/qhqd5ocd K3t4qRLV1VHMdhBjLC4L616GyQAQkB0BJbK0Lj0VNQTH2HSl0fThMuIjYN2DZXAJql6KLNc9S1dX lL0gyREUaLEcgA2PDVYsbbFRPlHtwyNltsPuL8Q3AxsPXNwlBNZoVyhaCu852XUPIicmCZCa+Ol4 uyNYRaxRMFDkuDkdg2ASpDhIJZmLVfBJR568iAJpQkQ7lEC84LJEDnsOq1C86K8oQn3oc3AMAKDB 4fUCMLKigO6ykNJTu/3TwIHIu5aNndtj4QvaYgTkBcpbNIxeJq9pdsHKHFw6PmAMhNLx0vBfaX2l E10hzq5lXjAKKUuAySUHAlQASzfMreBQoWWatZW0Q+opgUGiLzAQosAscLqVZURfaX2l9pfaX2ip ZpbmCfY+VcL6UH0q/bWaVO6xCkyay8dTnFKxLguYLMXOaZU7Q1O/DTx0vB2v1na/Wdr9YVh44Y2X GeoDGWpR5Ukddho3vFE5xc2mBgslKPJaQNmXtTPOYy3VIwjoH8+wVE4vgNmqVKDMXo+5WAsZbT3T F1cAyRYKI5bZaHIiajHJm7167GrtMAoXTTlJ3fpwbMrx0ed7aQnCSnFY6zAr4iYsiaddJ1OU0XQ6 QasSxrHhNDwdk7JiOGadCgrNWArgmOGNblCMLWQtKj4kZYqNvanpb+EkLDXsWLOtJZ2atGzEYDxZ DGO7VZIZlVshdI6W6WNa+XiVO3HUl/8AKNP7gKVGEnKKICg7BoTQRSNlc/k6GOvCxKL+qdfZLc83 Xmyzv0l+E95QprLPfSVOSq0hujTEJtYBoc4Gge0QRTiaHj7DWBCwrJzXUWXcGBKDoa3IyLajFLGr PJ6NhiKhsQhym8VuPSiEuNQtTCBXKtaECok5YRxSCxVAK4GQhBNwH+0vVkx0Gsc8SnFi4LnUeYxr n4FoZC6ORz4VtBamBccWaGh+YB2lFdOcCh0uDPeFIHF6w4uafeafeGp38BoeG8vLy8vLy8vLxnSF J16EuhtzgAAFBoRQKUGVdAly0XDr6v6mCtJg6R6x8yjv1iaxEUSgrmxLtKrgFFfMFp4Dw9s7Z2zt nbO2dsYpoRb/AIbxwwadVPfV34KAq0GVeUUbQfy7QyhV0reZcazLnO0L8oHnDZX80lG6wS6VvKOk BLYDRz4haHi/hmfwzP4Zn8Mz+GYpP0QKvsS1FnevbQ9/iUpB3+4uXgn5gMufuzu/EO5howENEX5u JtQ9sCbw5sMTneFd+NbQHSUdPF3zvj1K+gn7SjqjZ/19IeldQUfL+IDTHOtruueNuOx5d2Zkq0ND twjAzW0DjEvzZWHQQbridwwF0IUu5r4mpAHkBf7P3Zp2kBQDoFeDnp0MsBRV6avvDLSt2X6yu8C6 Fwfad8Cbyqg0uBrOWAGkp6Qoq44mp38tQytE6lehn7TrTu/5MM0Ohj7QfSped0DzzAGhNiXnfNqa YJrgm1K9YFFeA1O/k7z5jfVPvFupcttLzczulesCbyjpxp6S8OtgTeUGh4aYNgxHyby8vO6d07p3 SvWBN5R0lHTxVekt0ndAmuZR0lHTzqekp6Mp6M2JsTam1Nqe1L9Z3TamxKrT/of/2gAIAQIDAT8Q 879+/fv379+/fv379+drLKpXLqrc/fMf9Zn7Jn7ph/rMeq+Wbz5Zvvlm6+ZvPzN9+Zus3JeWl+f/ AP2Ns/sXweJH0Px1o50H2T2YgzHzT5JT4voR1QfLUIToAfHB4kfMvLy8+0AXVegc2DROcjTs5G+s qGC6uCLBoGA7PTZwxdRsnw1Ly8vLxj8lb6vvXAjxPPAKtqDeHmV1ubHT7tWXZpy3iMweVS2eRgiF nSNN245autEtz18IVi88Pu/1wPAeebY13dX4x78H7qd/1BeoQnOc/Bj6yjd4QMBa4IA2oz3cv14c vBfn908hVU2GFvFV0cRgli7oXkDYGjtAuKKgVdxp/wA6mZzwOfkflo+fF/F3S35PjX44EeJ6H2Bo QdzD9H6SptWO5g+NfaYBoWHWg+2XdkjpAIpnCjTFokt1R7XG3Z+xHLIXkpooNrVOpgtvEp6ck1Fi tMY1DNZxKtkP5UonKo1erzeB4D0G5guIC0kxh1w7JcXOXi3PNvnjToe8ogcDRz0e3U5xCrEWKw2V XcTDyojna1OOT9tJRgOORQBVOa0OVZLlGEEqtlotna83SXAraTC2LGx+XgEfSaV4tV/NzU3lpKLe 11p0qsdLesakW7Ppvpiuyy1VRUrn0Trzv7QEaovvra3ru2i7wF289URdeY6aHIgrASurNrDXl116 stXP8of2+kvh4aHXd26dfIv0/wDr4Ww699toFcDHqwFMbZXZ+jkfl416r41o1mWwfX/JTjX34nif RS6C50d3nMfiH415T5N+RtpoQ+IA08V+sr/o1/6v/9oACAEDAwE/ENybk3JuTcm5Nybk3JuTcm5N ybkepNybk3JuQ60XLy0tLS0tly/BiYmJiYmJiYmJiYmJiYj4SPmXLly+A0YOJcuXLly/ER88SwTg OqAvifEEfPrYYXLVcMDxPiPPeFwEobh5t+geCQ8T4j0LpwVKlSvKI+iuXwvySaeguXLly5cuXHx1 L9dXqL/5D5FenfJv/wA7UT0l+Xf/AIv/2Q== ------_=_NextPart_001_01CBE4BE.5016DBC7 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhGAAXANUiADamKSuhHonKgla0TG29ZEmuPiGbEyliIC+HJBp9DZ+inEGqNYLGel22Ury/ uWW5W3+DfODW4NDK0sS7xU2wQmSPXaTVnZDNiN3v2pzSlpTPjbfespjQkXnCcMLjvlKxRsnmxbLc rAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAACIALAAAAAAYABcAAAb/QM9g SCwajwNMwxBoOgOA6BPwDBgYBGh0a0gkDNvwNiDIig+QyQRy0IqpZTfgIBHZRZLDWxrnKu53Dl9v ZGYBXg6AdhgKCghyhVAHEw51incHFFR8WQZ/l4AQBgMMD1AGcQGfoCIRCVQBBA1NqRWsdwpgAFdw ZgiJtxF6VA8UqGYACROKDhF2wlIEBccBCwmrdhKrEK9UDLS+l6vCCwIMs3CmAAi2dwwHFhJs1RYF GwK7fbvsFQgJbf52NbiQAUDBSFEWwEJwAEFCAxc0yBIwC6EYhggURqHA4UEfi2EONAwToIOFD1pA hnkkxskYAQ/AQJk5ZpNNLVdCFNjJs+dOBwo+eS4AEQQAOw== ------_=_NextPart_001_01CBE4BE.5016DBC7-- From mcr@sandelman.ca Thu Mar 17 10:52:19 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B91A93A6AE3 for ; Thu, 17 Mar 2011 10:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.547 X-Spam-Level: X-Spam-Status: No, score=-0.547 tagged_above=-999 required=5 tests=[AWL=1.407, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P4s5w6x3qrgV for ; Thu, 17 Mar 2011 10:52:18 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 655823A6ADF for ; Thu, 17 Mar 2011 10:52:17 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 97F57343F2 for ; Thu, 17 Mar 2011 13:53:45 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 1651498B15 for ; Thu, 17 Mar 2011 13:54:32 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 17 Mar 2011 13:54:31 -0400 Message-ID: <24055.1300384471@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] review of draft-dvir-roll-security-extensions-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 17:52:19 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I read this document in January, and the authors and I had a short VoIP chat about it. I promised to post my thoughts, but life has intervened.=20=20 My first comment is that this is two documents: 3.1 DIO Message Authentication . . . . . . . . . . . . . . . . 5 3.2 Local Key Agreement . . . . . . . . . . . . . . . . . . . 13 I believe that it should be split up into two documents. To first order, 3.1 DIO Message Authentication is a problem statement, it details a limitation in the security model that we have assumed, and then presents a short solution. I'd like to see the threat more clearly outlined. 3.2 Local Key Agreement is a solution to a slightly different problem, and there is some cryptography there which I did not pay enough attention to, in great part because I want to make sure that we know what problem we are trying to solve, and I do not think that 3.1 is solveable with JUST per-peer authentication keys. Creating per-peer authentication keys significantly mitigates some attacks that, but I'm not actually sure which attacks it defends against, because we do not yet have a clear risk assessment of what nodes within a pre-installed or authenticated network can do if they decide to be malicious. (I would have liked to see this analysis in the Security Considerations section of the main RPL document, but I agreed that it could be out of scope for the base spec, which assumes all nodes are trusted) In particular, there is an assumption that for some class of devices it will be possible to to subvert individual devices in some small bounded amount of time (I'm guessing hours to small number of days), and retrieve the important RPL parameters (the RPL pre-installed keys, or the layer-2 security keys) such that fake messages can either be sent out by a rogue node, or that the subverted node can be forced to become a trojan. I'd like to see this assumption made more clear: what are the real attack methods for closed networks operated by a single entity? I do not think, however that this attack being unimportant for many use cases invalidates this work: I am interesting in more open networks (I think that many home networks will be such) where it is impractical to use layer-2 security, and we will rely upon layer-3 RPL security with a combination of unsecured networks with an enrolled system that gets visitors to your home into the pre-installed state. The devices that such visitors bring will only be partially trusted, and will generally be running on untrustworthy devices. To that end, I'm going to actually ignore the bulk of the document as technical details, and focus just on 3.1. Section 3.1 worries about what happens if some node in a DODAG=20 (why does it matter if it's grounded?) starts to send out messages with a malicious intent to disrupt traffic. In The RPL base spec, we assume that nodes are either in the DODAG, or they are not. I'm going to ignore the leaf/router node for now, because we can not yet make this work without assymetric encryption. Section 3.1 is about protecting some critical information using a hash and does not require assymetric encryption. There is a problem with how do nodes bootstrap into getting an authentic h^n(r), and the document punts slightly by suggesting that a digital signature be used. It assumes that we can amortize the cust of verifying this digital signature over n-Version increments.=20=20 How often do version numbers increase,=20 vs how costly is a signature verification,=20 vs how big can we make n? The above are questions that need to be researched, and the answers detailed in applicability statements for different RPL usage. I do not believe that any of our existing MAC functions work because in effect, every node that has the symmetric key preshared key K can send such messages, and we are really back to square one: all nodes are equally trusted. Now, at this point we have authenticated the DIO message. My question is, what other things would be worth authenticating in this fashion?=20=20=20 How much more can we do using mechanisms like the one presented in section 3.1? I'm thinking about if it becomes worth authenticating some or all DIS or DAO messages as well.=20 =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 =20=20=20=20=20=20=20=20=20=20=20=20=20=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATYJK14CLcPvd0N1lAQLgFggAqELQa0RKbt3yoSlAOMPAi1PaPf0BBnPk 0XBsRXxdHob5pzOBXflxz6Zg8brHewesJwDWEzWGPIccK4z2TgjY4uOk7XVmBIsr HAgjnAxT6ha4ALe4MPN+/dSh3GhsACP4NuPvimyoougPWWHbQyX+nTFH9eCD6DjG NDJ4ul9MXDQVfyVYZu1yXtDYrqFI5drjscyvAh9V1uc3Lza+7gbtalmN/lKsK0FC LykwCTNB2v7E4RZWJclpsLdQ1JEZRCXQcddh9rXDb+y5ReqB8UvS8epHbp3FF8sB oC+Fe3t4Sfm3hppmoEeqvleYGAI4R2Gtl7CTeicPehbGkpdANArRaA== =zH/9 -----END PGP SIGNATURE----- --=-=-=-- From m.pouillot@watteco.com Fri Mar 18 03:15:18 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 216973A68B1 for ; Fri, 18 Mar 2011 03:15:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.178 X-Spam-Level: X-Spam-Status: No, score=-1.178 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4HKE9P3LN+SN for ; Fri, 18 Mar 2011 03:15:10 -0700 (PDT) Received: from VA3EHSOBE004.bigfish.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by core3.amsl.com (Postfix) with ESMTP id 7C7843A6A6A for ; Fri, 18 Mar 2011 03:15:09 -0700 (PDT) Received: from mail87-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.8; Fri, 18 Mar 2011 10:16:38 +0000 Received: from mail87-va3 (localhost.localdomain [127.0.0.1]) by mail87-va3-R.bigfish.com (Postfix) with ESMTP id CD022F5033F; Fri, 18 Mar 2011 10:16:37 +0000 (UTC) X-SpamScore: -42 X-BigFish: VPS-42(zzbb2cK1dbaL14ffO9371Pzz1202hzz8275bh8275dh1033ILz2dh54h49h2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB001.red002.local; RD:none; EFVD:NLI Received: from mail87-va3 (localhost.localdomain [127.0.0.1]) by mail87-va3 (MessageSwitch) id 1300443396686378_23542; Fri, 18 Mar 2011 10:16:36 +0000 (UTC) Received: from VA3EHSMHS004.bigfish.com (unknown [10.7.14.240]) by mail87-va3.bigfish.com (Postfix) with ESMTP id A0C51888051; Fri, 18 Mar 2011 10:16:36 +0000 (UTC) Received: from IE2RD2HUB001.red002.local (213.199.187.153) by VA3EHSMHS004.bigfish.com (10.7.99.14) with Microsoft SMTP Server (TLS) id 14.1.225.22; Fri, 18 Mar 2011 10:16:31 +0000 Received: from IE2RD2XVS151.red002.local ([10.43.202.15]) by IE2RD2HUB001.red002.local ([10.33.16.61]) with mapi; Fri, 18 Mar 2011 03:15:53 -0700 From: M Pouillot To: "Pascal Thubert (pthubert)" , C Chauvenet , "roll@ietf.org" Date: Fri, 18 Mar 2011 03:15:59 -0700 Thread-Topic: [Roll] [Spam] DAO No-Path in a storing mode Thread-Index: Acvkvkv5WMkOvK4mRFulxe9F09JB4wAlb75g Message-ID: <555DED900DD42348B2995D1005EF1662025D1B1909@IE2RD2XVS151.red002.local> References: <6A2A459175DABE4BB11DE2026AA50A5D0423F100@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0423F100@XMB-AMS-107.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: multipart/related; boundary="_005_555DED900DD42348B2995D1005EF1662025D1B1909IE2RD2XVS151r_"; type="multipart/alternative" MIME-Version: 1.0 X-OriginatorOrg: watteco.com Subject: Re: [Roll] [Spam] DAO No-Path in a storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 10:15:18 -0000 --_005_555DED900DD42348B2995D1005EF1662025D1B1909IE2RD2XVS151r_ Content-Type: multipart/alternative; boundary="_000_555DED900DD42348B2995D1005EF1662025D1B1909IE2RD2XVS151r_" --_000_555DED900DD42348B2995D1005EF1662025D1B1909IE2RD2XVS151r_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Pascal, Thank you for your answer. Our problem is more on the 9.8.4, where it is sp= ecified that a node should send a No-path DAO to its parent when this is re= moved from the DAO parent set. In the case where the parent is removed from= the DAO parent set because the link is broken, then the node can't send a= nymore frame to it... regards, Mathieu De : Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] Envoy=E9 : jeudi 17 mars 2011 17:14 =C0 : C Chauvenet; M Pouillot; roll@ietf.org Objet : RE: [Roll] [Spam] DAO No-Path in a storing mode Hi Cedric: When a parent has 2 children for a same target, and it gets a no-path DAO f= or that target from one of those children, then it should clear its adjacen= cy for that child but keep the RIB entry for that target via the other chil= d. As a result, it still has a route so it must not send a no-path to its o= wn parent. OTOH, if the node loses its last child for a given destination, = then it should send a no-path DAO to clean up. A no-path DAO is still a DAO= though the information is 'negative'. The spec leaves some space for an no= de to be reactive to datapath validation for that though. Pascal http://www.xtranormal.com/watch/7011357/ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of C C= hauvenet Sent: Tuesday, March 08, 2011 5:08 PM To: M Pouillot; 'roll@ietf.org' Subject: Re: [Roll] [Spam] DAO No-Path in a storing mode Hi all, As mentionned in the mail below, the no-path DAO message usage in not very = clear in the RPL specification. Though it is important to clarify this because it is an important feature f= or reliable and reactive downward routing. Section 9.1.4 clearly states that DAO massages MUST be sent on a link local= address, thus limiting the no-path DAO destination set to one hop neighbor= ing. But given that this message should advertise that a downward path is n= o longer usable, how do you propagate this information in the upward direct= ion to erase that path ? For instance how do you prevent the DAGroot (located several hop away) to u= se a broken downward path if you can send the no-path DAO to you link local= scope only ? Some papers says that the no-path DAO must be sent to the root, but this se= ems contradictory with the 9.1.4 section I pointed out (DAO are link local = only in storing mode). I would appreciate that people shed some light on this .. Thanks C=E9dric. De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de Mat= hieu Pouillot Envoy=E9 : lundi 10 janvier 2011 09:09 =C0 : roll@ietf.org Objet : [Spam] [Roll] DAO No-Path in a storing mode Hello , In the specification, for storing mode, it is specified that a device shoul= d send a DAO no-path to a node which is removed from the DAO parent set (9.= 8.4). For me a node is removed from the DAO parent set if it is unreachable= on link-local and so I can't send a DAO no-path to this node. A solution t= o inform the old DAO parent should be to send the No-path on the global add= ress but it is not allowed by the specification (9.1.4-in storing mode DAO= message MUST be link-local-). So only the lifetime will remove the route f= rom the old DAO parent, that can take few minutes depends of the DAO lifeti= me setting. What do you think about that? best regards, Mathieu -- [cid:image001.jpg@01CBE55C.ED59FA40] Mathieu POUILLOT R&D Engineer m.pouillot@watteco.com Direct line : +33(0)4 98 01 60 05 Tel : +33(0)4 98 01 60 05 Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE - France www.watteco.com [cid:image002.gif@01CBE55C.ED59FA40]Before printing think about environment= and costs This Message may contain confidential information intended only for the use= of the addressee named above. If you are not the intended recipient of thi= s message you are hereby notified that any use, dissemination, distribution= or reproduction of this message is prohibited. If you received this messag= e by mistake, please notify the sender by reply email immediately. Please c= onduct your own virus checks before opening any attachment as Watteco does = not guarantee the integrity of this email or attached files has been mainta= ined nor this communication is free of viruses, interceptions or interferen= ce. Any views expressed in this message are those of the individual sender = and may not necessarily reflect the views of Watteco. Watteco shall not be = responsible nor liable for the improper and incomplete transmission of the = information contained in this communication nor for any delay in its receip= t or damage to your system. --_000_555DED900DD42348B2995D1005EF1662025D1B1909IE2RD2XVS151r_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Signature 3

Hi Pascal,

 = ;

Thank you for your answer. Ou= r problem is more on the 9.8.4, where it is specified that a node should se= nd a No-path DAO to its parent when this is removed from the DAO parent set= . In the case where the parent is removed from the DAO parent set=A0 becaus= e the link is broken, then the node can't send anymore frame to it…

 

regards,

 

Mathieu=

 <= /p>

De : Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]
Envoy=E9&= nbsp;: jeudi 17 mars 2011 17:14
=C0 : C Chauvenet; M Pou= illot; roll@ietf.org
Objet : RE: [Roll] [Spam] DAO No-Path i= n a storing mode

 

Hi Cedric:

 

When a parent has 2 child= ren for a same target, and it gets a no-path DAO for that target from one o= f those children, then it should clear its adjacency for that child but kee= p the RIB entry for that target via the other child. As a result, it still = has a route so it must not send a no-path to its own parent. OTOH, if the n= ode loses its last child for a given destination, then it should send a no-= path DAO to clean up. A no-path DAO is still a DAO though the information i= s ‘negative’. The spec leaves some space for an node to be reac= tive to datapath validation for that though.

 

 

From: roll-bounces@ietf.or= g [mailto:roll-bounces@ietf.org] On Behalf Of C Chauvenet
Sent= : Tuesday, March 08, 2011 5:08 PM
To: M Pouillot; 'roll@ietf.= org'
Subject: Re: [Roll] [Spam] DAO No-Path in a storing mode

=  

Hi all,

 

As mentionned in the = mail below, the no-path DAO message usage in not very clear in the RPL spec= ification.

Th= ough it is important to clarify this because it is an important feature for= reliable and reactive downward routing.

 

Section 9.1.4 clearly states that DAO massages MUST b= e sent on a link local address, thus limiting the no-path DAO destination s= et to one hop neighboring. But given that this message should advertise tha= t a downward path is no longer usable, how do you propagate this informatio= n in the upward direction to erase that path ?

 

For instance how do you prevent the DAGroot (lo= cated several hop away) to use a broken downward path if you can send the n= o-path DAO to you link local scope only ?

 

Some papers says that the no-path DAO must be sent t= o the root, but this seems contradictory with the 9.1.4 section I pointed o= ut (DAO are link local only in storing mode).

 

I would appreciate that people shed some light o= n this ..

 

Thanks

 

C=E9dric.

=  

 

De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la pa= rt de Mathieu Pouillot
Envoy=E9 : lundi 10 janvier 2011 = 09:09
=C0 : roll@ietf.org
Objet : [Spam] [Rol= l] DAO No-Path in a storing mode

 

Hello ,

In the specification, for stor= ing mode, it is specified that a device should send a DAO no-path to a node= which is removed from the DAO parent set (9.8.4). For me a node is removed= from the DAO parent set if it is unreachable on link-local and so I can't = send a DAO no-path to this node. A solution to inform the old DAO parent sh= ould be to send the No-path on the global address but it is not allowed by = the specification  (9.1.4-in storing mode DAO message MUST be link-loc= al-). So only the lifetime will remove the route from the old DAO parent, t= hat can take few minutes depends of the DAO lifetime setting.
Wha= t do you think about that?

best regards,

Mathieu

--

3D"Description:Before printing think about= environment and costs

3D"Description:

Mathieu POUILLOT <= /span>
R&D Engineer

m.pouillot@watteco.com

Direct line : +33(0= )4 98 01 60 05

Tel : +33(0)4 98 01 60 05
Fax : +33(0)4 94 14 10 80

1766 Chemin = de la Planquette
83130 LA GARDE – France
www.watteco.com

This Message may contain confidential informa= tion intended only for the use of the addressee named above. If you are not= the intended recipient of this message you are hereby notified that any us= e, dissemination, distribution or reproduction of this message is prohibite= d. If you received this message by mistake, please notify the sender by rep= ly email immediately. Please conduct your own virus checks before opening a= ny attachment as Watteco does not guarantee the integrity of this email or = attached files has been maintained nor this communication is free of viruse= s, interceptions or interference. Any views expressed in this message are t= hose of the individual sender and may not necessarily reflect the views of = Watteco. Watteco shall not be responsible nor liable for the improper and i= ncomplete transmission of the information contained in this communication n= or for any delay in its receipt or damage to your system.

&nbs= p;

= --_000_555DED900DD42348B2995D1005EF1662025D1B1909IE2RD2XVS151r_-- --_005_555DED900DD42348B2995D1005EF1662025D1B1909IE2RD2XVS151r_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=7606; creation-date="Fri, 18 Mar 2011 03:15:51 GMT"; modification-date="Fri, 18 Mar 2011 03:15:51 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAWgAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAIRwAADmgAABSuAAAdtP/bAIQAAQEBAQEBAQEBAQIBAQECAgIBAQICAgICAgICAgMC AwMDAwIDAwQEBAQEAwUFBQUFBQcHBwcHCAgICAgICAgICAEBAQECAgIFAwMFBwUEBQcICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI/8IAEQgAoAD8AwERAAIR AQMRAf/EAO0AAQACAgMBAQAAAAAAAAAAAAACAwEEBQYHCAkBAQABBQEBAAAAAAAAAAAAAAABAgME BgcFCBAAAQQCAQQDAAICAwAAAAAAAAERAgMEBQYQQBIVMCETIAdQFnCAMREAAgEBBQMIBQoEBgMA AAAAAQIDBAARIRIFMVETQEHRIjKTFDQQYXFCBiCBkaGxUpIjMzVygkNTcPCi0nMkg5QVEgABAwMD AwUAAAAAAAAAAAABABEyEECRICECMVESUHCQYXETAQACAQIEBQQDAQEBAQAAAAEAESExYRBBUXEg MECBkaGx0fHwweFQYHCA/9oADAMBAAIRAxEAAAH9QuIVAAAAAAD27rrnvZjoQhum4bSdymNk2obC NiF5ZCwuhIyfMvz5IAAAAAGD6G7jHLek83Jm4bJsTOxEbBaWlpMkCwA+auAyAMHmGwVcZ6E+javT zuPAAE630f3iFbzU2zbNg2Zm6I2i4sLCRIyTAPnHg8gdazJ+Ue53tXb7lNin27ULPsvCqOQoADnv ae4dejjzoxtm0bJsFxeXFhaTBIkAfPPDpHG3XUOtT8kdByPSMKn6K8i1y+o07XMVoAPRN5j0LeHX TrxtmyXpvReXFpYWEwTMgHgPFZHEbe+jN7j4TzK/qbGp4HDjieOTbUAEqntnW45DNdKNc2i82Jm2 I2C0uJkyQJmQDwvjgdI2SeX2R9De3HmuO6xr87eiQAB2nY3pfQGmdOLjaLi8sLi4sLCRIEzIB4py WQOt7M7DsceM6TOpYctjLTZPTrS+89Z6XG7lusGiWmwWpuRcWFpMmWAEzIB49y0NWp1O5OjecRbd dtuxY7hbiMvc7bv+6x2bYGkdZLS0uLU2IuLSZYSJAmZAB5RzaR1mt5/QkadTJydtuQxW939+O47U gdaIFhYWlpMsLCwkWAEzIAPMufAAAAOw+47XshLgzVLCZMmXEyRMmSJgFgAB55o4AACdTsvvub9d g4k0yZMmSJFpYSJEiRkAsAAOjaeAAzLk/Qc97K+8icYa5IkSJEiRItJEiQMzMogZAAOoauGZbF9v Zjks9ddCk48iZJEjJIySMkiZMAmZAAANawnUtuMyArNUpMmTJIyZMmTJkySJAFgAAAAMESsqIAyD JIGTJkGTJkyACwAAAGsYMAGQDIMgGTJkGQADJkkAAACgAyAAZAMgAAEjIBkAAAAFYAABkAAGTIMg AAAAAAAAAAAAAAAAAAAAAAA//9oACAEBAAEFAvW689brz1uvPW689brz1uvPW689brz1uvPW689b rz1uvPW689brzWaLSzwPQaIv0+oS9NRqSOo1RHU6sTV6wTWa4TXa8TAwRMLDExMUTHxz8aT86zwi MnRhhhhhhhhhhhhumDHwwyxXuQQTonVPgYYYYX6S7mHH65JzbVvrtlr9tQwwwwxGCylFPGKqyf8A oiCCdEE+JhhjbbTD0uFscvN3sn+v0tlfxvim0zqMS9MvEYYYY1lP65xlS8aEQRCPRBhPiYYzMqjB xd5wrL2nHY32ZScg4vteLXf1Vp44+n3PIv8AYqoVwrgwwwxo6OmfL6RBBBhPkYYx8b2nI4W1XH9S 8d/Hacw43Dlei5n46zhcKoVQYYYYSKquLSmPQZE/0uYQTonyMMfryHV7D+v8NNPkNj4lfE+Uw5Ph 8ks9jvmGGGGNVjfpcXz/ADrYRBOiDCfGwwxTP1/K+cZflhb/AGuFqNhqeQ4CXw5bVZhw5frrEyOU 4mII0khXKyWPTHHqMmfnNhBE6IJ0T4mGLbqMeO09bsMPBitmdutTxje2Yen4dZfRgaKOLZo9Hjl+ i0ObbGCRTX4n5IX2fnFhuiDfMwxttRibnFq4Lp6sjE4PrMLG/wBC1sYLwPXSWHEKIrPi1U7cTiOu wjCxPJRVSKTks5MMMJ87DDDDDDDDGNhv1ts81YbsmGGGGGGEgsloxIw622eQw38U+ZhhhhhivElI hXCtBVYnNZDDDdmwx4uJRYpHFI1wh1lNEFVZDDdr+VZ4QT+KyRBZqo3d+SHmKqr1buPs++jdGG71 hhhvkbu2/wAn/9oACAECAAEFAvYXnsLz2F57C89heewvPYXnsLz2F57C89heewvPYXnsLzX3TWn9 JH6SP0kfpI/RTzU81PJTyU8lHHH7PDi1XbU6q+ZLQ5KFlMoL/GMXVEbtaMeVktfp66ek5pE2FULy UWX+Gvq8reyYYhWslwcZKCdjJTkeS3zeWZsI1jDDDDGnq7NhjU0/ZZY6RVi6fjFEGGGGGMerwh2T DGHmpVDAuWcCu2M02lrQYYYYY12O8uzYYY1cmllXeEMWcqy+SyXx+/AjFxCMHWmrwj2bDHiR8orf fOxUSSE65i1TPGRGuRGDGFjePasMJ9C+RJ1V1HUYSJ9mJi9swwwwwwwwxj4vbsMMMMMMJFynGbuG GGGGGIYyqQgidywwwlKkcYjBE7v80PBP+P8A/9oACAEDAAEFAnHHHHHHHHHHHHHHHHHH/wAo3fIn VV75FF75V/7uf//aAAgBAgIGPwKRypHKkcqRypHKkcqRypHKkcqRypHKkcqRypHKDn0AflvtxXRN yvPHin68qsdQtWC+09WEtR5WvlQUJ1tasnPWmy8e+p+1uQnThHkU2hk1u4W9GT6HN+5v3N/vfb+/ X//aAAgBAwIGPwL4gP/aAAgBAQEGPwLyEPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFvIQ90nRby EPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFqZpNHpXdhixp4idvst+ y0n/AK0P+20oGlUwAOA4EXRb9rp+5j6LftlP3MfRb9tp+5j6Lft0HdR9Fv2+Huk6LeRh7tOi3k4u 7Tot5SP8C28tH+BbfoJ+EW/SX6BbsD6Bbsi2zkFKu5F+z0SHex+3khYm5VxZuYCzJDVtqTpgwpIp Khb/AONBk/1W/MoK+FP7nhc4+iFnP1W8VptYlZADldkOKt91gcVPqPylUbWN302VRsWxO61/I3rq wnICFhgQZpJpW7MaDnY2z6ww8Pth0VDfTR/x/wB1vWcNwsFGCr2V3WSmpqaavq3VpBSU8TTScJO0 5C7FF/8Ak2qfi6nqzopMDjTIjEL65FGYNUrIL+HeOoMG578brUlWFyCqijlCbuIge76/kwDmQ5j/ AC+iT14fTyOesqTlhpxe9wvY8wAHOScALVms6gXT4looZKjQqGORuFSMFz8IhcJGkAySM1+3q3Wo E02nNdWaw0aaTRg3cR5Vzi88yqvWY8wFtLFdWx6jT6sGQVEcJhENUi8Th4s16st5U7cLVPxLOt1X 8SNnhY7UoIb1gX2ML5P5rT6P8PMW0+ozRap8Rj9IRnqulMf6jnZnHVXeThZI41yRxgLGm4AXAfJm qDz9VftPoRN+J5Hp1GwzUmjr4+sHMZsxiplPzh39qi0gjkWXhsUluIOVhtBu57a5WVKXj4WmqdI0 y/mZJyZHH/j4Sg+21TpHifBTOUekrguYwyI1+YD2Xj57Vun0KCPxMUOm6fFu8Uy0S3ewPfZIolyR xgLGgwAUYAfJAGJOwWji+6Ot7fQx5hgOR6rLo9FTVQ1hIAlbPMyeFeFWTrRqhMi43gAjHdtt8S6L xmqX40FfJVSfqTPWw5ZZG9bSwsbTS3LTxDNJUPcFG9mNnlkon0uuiytLp0hDNwZuvDKCNqyLj6je Oa2k6YvWg0YGurv+V1aCnX63b5h8rjN2Idn8XoJ5z2eS6VWHCDWIZaCc83FX/tQfZIPntS/D0Lf9 v4mkMDXbVo0Gepf8HV9rC2nzRVjaTq9I1NFSTiLiwyQ1sjRcORAy5ogY72xGW68Wigzz6nq/xCst a1Tw0jEzKTGii9rkvSI8JSeyu22nVyaNVtDqswgpPK352JAv/Owvym1UUglZqep8JHCpgaWWo4rQ 5VRZLxipxe4XY2qPE0VQn/z4km1i7hMKSOQsAXyvjgpbq34WvGI32VFF7NsssS8207z6Mo2JyTPP MsCY9Z2CjAZjt9Vp6WTUUp3Q5o6lZEEkE0Dq6ut/OjZbT6vq2qQahqnDWnWWMCKKGFXHVVC73ZnN 7G/E3bhaKXUalGkanqKWFlnC/l1ShWuu977p5rUtfR1SGqppKPwVVxBnTw9OqRRqW90o2I57zbSt Pi1JWj06oD0K8ZCxmjJa47+3avp5tceE8bxeQzQI9LO0xmDoQgbtP71+26zU9RrzzzVsccGpwiph BrUViyLKEUffu6t2ButcLcZx+Y3ZG4ejDtHZyUUdYCYQ6uQpuvy8x9RGBtQ1OeaR6BYVUM94k4Wb F8MS94Lb7haupIaio4eoRCKpJcFrgrC8G7A3tffvAtDHDWVEMcMvFCZ1IJzxuO0vNwh9douJWTyi IKuVjEQUVY0u7HOIVxtDm1KokWJYoyh4VzQQOkkcZuQdkoMdpsZxqVQknF8RERwepUFQjPjH7wGw 4WiWCSUJD2FLA/1IZd2+AWE0g6vuLv8AQSdgtmPzDlgklHV91N/puHZHK7lF53WzSdZuYcw9OUdn ld79QfXa5Rd6Lza73eUYW7N1us3zC3VW707zbHk/Zt2R8rdy3Z/g5//aAAgBAQMBPyHzhQoUKFCh QoUKFChQq6IF6Zarw+F9tAAPjhT8HhcxNpGBqhiBoUgNDgBoP8+kAYD+HSC0L+fSBaF/LpAtDgDo XsSjk88ABU6+2ve3gqBywwOAIcBDygodEUNA1VdCOiBAIcpge6jZHVjy/RZI8owXoj4gaCSHuqDp AA9ipd+gX4hlbVb4BxwHEOXE4GvjDm+iwTZlnTkFqgLFmYWUJk5a+eG6WqIxAoMAOQcoE/WY09Ng W6qBaqY28UxOQ0FSXUQzESC65Bt4QYg+w1/euFm5in0cBOAghwDlwNeIc/B2TsiIMrWZRsrAtVCB 9bKzrJXYDIoy9A0bD1tQ08p2lqbsmfSuLCZb1Jjz49KHXohd9sYfTBLpNo73JRgUoIaVw2AnZOyd k7JUA5H7f4cMf5qO2DgCGHAIEDSGsOJp4jGAvNLsBJGKMjWo1aheRmQyeOYM6gDZzinVehsLBd2d lLbgD0R0f5BCoDkAtANADHhAE7FdRYL9czqsv14cwvjSECCBwBCHKVDiaeI1QGk+FBF4mwoYzLSI QtRi1wwXRiOFsZYVdlZxasqquyLqUwOjAuVDT9QZczeqfK7meIGDPuFp8a8KX6Xcw6uAMQIIcA5c TiaeMXdzIUHsfY+4irwJr6IemznVeTZZngMiDa3yDGWES7rQza1J0QWHUZwLJtnlNdyrq7C9VFTK oTkog7TKZoXhtlQtmg0lhY0ZlM+cavDPnK9+cIExQIIIHAHl+sFGIHyM0Cu0oFS7jSSD1krQcMVX sx9jNkU8DAEsD6+lCzQd0tazCinGsWD37XZZQjrk7MdWncl0KNaLGBwAjWCmWeuSLkdhYW3LEgoK CchTk/lbw1VyfzhBAQwgIQOIeUWoq4cl4nOR5jNEWhe2HVGebpywmw/Avvol8CCyULTLUlDArkjn EW/lhu+4RnDVXLY+vNqJgWq6lryMi68wNxrwGwW0GKBqx5CZq/gb9tEJlubq7cHDrUjv8AQgg4FS oQh6MAactX9jhpljdot94QQECBAxAgcT0H89d9BKWrignzT14gQJUrgCVwCVXk9s7Z2ztnbC7QWu hKLsMd4M83gAsoJjWOjrxOyVKJUqEOFeCvJBaF+0++jiDrdDSDdz44H2I5a7E7OCpUqVKgVwIeCv I28NJ8RADQrwak56TFGHBUqVKlSuFSuJ56HOPRHMpUrgqVKZUqUcaZXnX1zulcFcSpXhqVK8dSvJ qVK8IVK8muCvR0ymUymUymVwUSj/AKP/2gAIAQIDAT8h/bvzP278z9u/M/bvzP278z9u/M/bvzP2 78z9u/M/bvzP278z9u/M/bvzP278xZRa6zeZvM3mbjN1m/N2b03uBeXlpcvjUqVKlSpUqVKlSpUq UfZ6KpUqVKhdpW+PvALo+5KiUypUqVKmE6ytXoqlSoHC1gNu5+OGrQKrTnzlgdJUqVKnYWfj0oA1 GZg7n+coEzUPAiHJ9nf8eIH2T0oC1yxwqnQiqybKkx+EBrRK7p9KJEK3c6vTwuDvlKAa/YeIGb6f d6cbo5l3zcu8e1DNnb++k5fOO3657xIrGO/4iiu1+0DQ66byjHqasMj6YEys1SAqUGhCMdb+IM6M /WWHqILT7d4AutNMadpQqVOc+nG6IkJ1lIvLh/z/AJ3ioNV7e013/Of5lnS9eALej64A6og56vXA 9IQXHqwvG8oHOaB6vbgHKV/8+//aAAgBAwMBPyG0tLS0tLS0tLS0tLS0tLS0tLS0tly5cuXL/wCZ TL+trirXrYYsvjt9eD/3z/8ATn//2gAMAwEAAhEDEQAAECSSSSSSZWyQojzwhEkkkkklqFAIABII AP8A9xL/AP8AVMBxAIIAANtPvnttAlI2AIAAAG7GFu23xgAgIBAAANkOCNthBhIYIJAAAG5lU222 BoG4BBAAAAAqTyQAMAMJAAAIAPztE74QtIMBAABAAJI3RDSIpI3JJABAALbbbadEAAwIIAAAACSS S+JpIOABJAIAAP8A/kgRASBgAQCiAABt8AAAQSOCSATgAACZAATSSAiSQAQAAAACBAQSCkACQAQA AAAASAQQCQCAAcgAAACSAAQSAAAQCQAAAAAASSAASAQAAAAAAAAAAAAAAAAAAAAAAAD/2gAIAQED AT8Q87Dhw4cOHDhw4cOHDhU3lwqwprjq8GRxgjgNUAhD1QZkAUG/sQEwEwRS7dafihHzm4wWlHLR 7YX2i6wWlFIT2QZO+CGPodH9oaPZi/qfQgL+oaYOwSiqrHSWlpaWlpaWlpaWlpaWjUXpHWKTG4v7 8A5Gu/dDpuwlYwOn8uHjeGw2/M16YESiic00E0+/A1O/gttLbS20ttKw9lEbpgBlVoiz8lyUpJTm aOc+ytXYCGzdorNSFEoNRtK9JbaW2ltpbaW2gJWL7gfvDioP2IfaHgCjsLmbkUndzNKnSPTnRMaJ y9py9pzT+qGpw0+/DS8FZWVgpqsKFTRDRQAyMNRr6NEdK7oESp0IBBVAMA5BHCaYlIDJU5SYE+Rp G2mGQA2AiRc9NgIqF6V86lZWVlZYVmWFgUb+DhnOu7Vf1YOKxAb0QYTcgyQEtIxpmc0/qhqd5ocd K3t4qRLV1VHMdhBjLC4L616GyQAQkB0BJbK0Lj0VNQTH2HSl0fThMuIjYN2DZXAJql6KLNc9S1dX lL0gyREUaLEcgA2PDVYsbbFRPlHtwyNltsPuL8Q3AxsPXNwlBNZoVyhaCu852XUPIicmCZCa+Ol4 uyNYRaxRMFDkuDkdg2ASpDhIJZmLVfBJR568iAJpQkQ7lEC84LJEDnsOq1C86K8oQn3oc3AMAKDB 4fUCMLKigO6ykNJTu/3TwIHIu5aNndtj4QvaYgTkBcpbNIxeJq9pdsHKHFw6PmAMhNLx0vBfaX2l E10hzq5lXjAKKUuAySUHAlQASzfMreBQoWWatZW0Q+opgUGiLzAQosAscLqVZURfaX2l9pfaX2ip ZpbmCfY+VcL6UH0q/bWaVO6xCkyay8dTnFKxLguYLMXOaZU7Q1O/DTx0vB2v1na/Wdr9YVh44Y2X GeoDGWpR5Ukddho3vFE5xc2mBgslKPJaQNmXtTPOYy3VIwjoH8+wVE4vgNmqVKDMXo+5WAsZbT3T F1cAyRYKI5bZaHIiajHJm7167GrtMAoXTTlJ3fpwbMrx0ed7aQnCSnFY6zAr4iYsiaddJ1OU0XQ6 QasSxrHhNDwdk7JiOGadCgrNWArgmOGNblCMLWQtKj4kZYqNvanpb+EkLDXsWLOtJZ2atGzEYDxZ DGO7VZIZlVshdI6W6WNa+XiVO3HUl/8AKNP7gKVGEnKKICg7BoTQRSNlc/k6GOvCxKL+qdfZLc83 Xmyzv0l+E95QprLPfSVOSq0hujTEJtYBoc4Gge0QRTiaHj7DWBCwrJzXUWXcGBKDoa3IyLajFLGr PJ6NhiKhsQhym8VuPSiEuNQtTCBXKtaECok5YRxSCxVAK4GQhBNwH+0vVkx0Gsc8SnFi4LnUeYxr n4FoZC6ORz4VtBamBccWaGh+YB2lFdOcCh0uDPeFIHF6w4uafeafeGp38BoeG8vLy8vLy8vLxnSF J16EuhtzgAAFBoRQKUGVdAly0XDr6v6mCtJg6R6x8yjv1iaxEUSgrmxLtKrgFFfMFp4Dw9s7Z2zt nbO2dsYpoRb/AIbxwwadVPfV34KAq0GVeUUbQfy7QyhV0reZcazLnO0L8oHnDZX80lG6wS6VvKOk BLYDRz4haHi/hmfwzP4Zn8Mz+GYpP0QKvsS1FnevbQ9/iUpB3+4uXgn5gMufuzu/EO5howENEX5u JtQ9sCbw5sMTneFd+NbQHSUdPF3zvj1K+gn7SjqjZ/19IeldQUfL+IDTHOtruueNuOx5d2Zkq0ND twjAzW0DjEvzZWHQQbridwwF0IUu5r4mpAHkBf7P3Zp2kBQDoFeDnp0MsBRV6avvDLSt2X6yu8C6 Fwfad8Cbyqg0uBrOWAGkp6Qoq44mp38tQytE6lehn7TrTu/5MM0Ohj7QfSped0DzzAGhNiXnfNqa YJrgm1K9YFFeA1O/k7z5jfVPvFupcttLzczulesCbyjpxp6S8OtgTeUGh4aYNgxHyby8vO6d07p3 SvWBN5R0lHTxVekt0ndAmuZR0lHTzqekp6Mp6M2JsTam1Nqe1L9Z3TamxKrT/of/2gAIAQIDAT8Q 879+/fv379+/fv379+drLKpXLqrc/fMf9Zn7Jn7ph/rMeq+Wbz5Zvvlm6+ZvPzN9+Zus3JeWl+f/ AP2Ns/sXweJH0Px1o50H2T2YgzHzT5JT4voR1QfLUIToAfHB4kfMvLy8+0AXVegc2DROcjTs5G+s qGC6uCLBoGA7PTZwxdRsnw1Ly8vLxj8lb6vvXAjxPPAKtqDeHmV1ubHT7tWXZpy3iMweVS2eRgiF nSNN245autEtz18IVi88Pu/1wPAeebY13dX4x78H7qd/1BeoQnOc/Bj6yjd4QMBa4IA2oz3cv14c vBfn908hVU2GFvFV0cRgli7oXkDYGjtAuKKgVdxp/wA6mZzwOfkflo+fF/F3S35PjX44EeJ6H2Bo QdzD9H6SptWO5g+NfaYBoWHWg+2XdkjpAIpnCjTFokt1R7XG3Z+xHLIXkpooNrVOpgtvEp6ck1Fi tMY1DNZxKtkP5UonKo1erzeB4D0G5guIC0kxh1w7JcXOXi3PNvnjToe8ogcDRz0e3U5xCrEWKw2V XcTDyojna1OOT9tJRgOORQBVOa0OVZLlGEEqtlotna83SXAraTC2LGx+XgEfSaV4tV/NzU3lpKLe 11p0qsdLesakW7Ppvpiuyy1VRUrn0Trzv7QEaovvra3ru2i7wF289URdeY6aHIgrASurNrDXl116 stXP8of2+kvh4aHXd26dfIv0/wDr4Ww699toFcDHqwFMbZXZ+jkfl416r41o1mWwfX/JTjX34nif RS6C50d3nMfiH415T5N+RtpoQ+IA08V+sr/o1/6v/9oACAEDAwE/ENybk3JuTcm5Nybk3JuTcm5N ybkepNybk3JuQ60XLy0tLS0tly/BiYmJiYmJiYmJiYmJiYj4SPmXLly+A0YOJcuXLly/ER88SwTg OqAvifEEfPrYYXLVcMDxPiPPeFwEobh5t+geCQ8T4j0LpwVKlSvKI+iuXwvySaeguXLly5cuXHx1 L9dXqL/5D5FenfJv/wA7UT0l+Xf/AIv/2Q== --_005_555DED900DD42348B2995D1005EF1662025D1B1909IE2RD2XVS151r_ Content-Type: image/gif; name="image002.gif" Content-Description: image002.gif Content-Disposition: inline; filename="image002.gif"; size=490; creation-date="Fri, 18 Mar 2011 03:15:52 GMT"; modification-date="Fri, 18 Mar 2011 03:15:52 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhGAAXANUiADamKSuhHonKgla0TG29ZEmuPiGbEyliIC+HJBp9DZ+inEGqNYLGel22Ury/ uWW5W3+DfODW4NDK0sS7xU2wQmSPXaTVnZDNiN3v2pzSlpTPjbfespjQkXnCcMLjvlKxRsnmxbLc rAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAACIALAAAAAAYABcAAAb/QM9g SCwajwNMwxBoOgOA6BPwDBgYBGh0a0gkDNvwNiDIig+QyQRy0IqpZTfgIBHZRZLDWxrnKu53Dl9v ZGYBXg6AdhgKCghyhVAHEw51incHFFR8WQZ/l4AQBgMMD1AGcQGfoCIRCVQBBA1NqRWsdwpgAFdw ZgiJtxF6VA8UqGYACROKDhF2wlIEBccBCwmrdhKrEK9UDLS+l6vCCwIMs3CmAAi2dwwHFhJs1RYF GwK7fbvsFQgJbf52NbiQAUDBSFEWwEJwAEFCAxc0yBIwC6EYhggURqHA4UEfi2EONAwToIOFD1pA hnkkxskYAQ/AQJk5ZpNNLVdCFNjJs+dOBwo+eS4AEQQAOw== --_005_555DED900DD42348B2995D1005EF1662025D1B1909IE2RD2XVS151r_-- From pthubert@cisco.com Fri Mar 18 03:50:07 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B74AF3A67CC for ; Fri, 18 Mar 2011 03:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.252 X-Spam-Level: X-Spam-Status: No, score=-9.252 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7HaZIf5zi+6f for ; Fri, 18 Mar 2011 03:49:58 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 9F9B03A68B1 for ; Fri, 18 Mar 2011 03:49:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=38849; q=dns/txt; s=iport; t=1300445486; x=1301655086; h=mime-version:subject:date:message-id:in-reply-to: references:from:to; bh=Mw6PFv3eJhYbpT1thRcl/wBmx932dV1C5rHRzEL/XCg=; b=bbRZjSpEXzI8F/BbmIxD3KyHg5pvzRRkx7ijDFMK6ItQhVFbG+gsmvY7 i0HKKVwBKGjsmZQTRLJ2KENkVkgT4OKi0peBLv2s8eOGSv0NhaOnP7WuD YyDSO9C9Db5HLI6puNEZWlrRlb05QHu9zwsBh3VCULeu77aVAXmE8GO2j E=; X-Files: image001.jpg, image002.gif : 7606, 490 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYCADrWgk2Q/khNgWdsb2JhbACCEFCVVo0xFAEBFiYlpkqcDoVjBIdogiOGLQ X-IronPort-AV: E=Sophos;i="4.63,204,1299456000"; d="gif'147?jpg'147,145?scan'147,145,208,217,147,145";a="22256989" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 18 Mar 2011 10:51:24 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p2IApOLS006169; Fri, 18 Mar 2011 10:51:24 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 18 Mar 2011 11:51:24 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CBE55A.6CCB99A7" Date: Fri, 18 Mar 2011 11:51:21 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0423F41F@XMB-AMS-107.cisco.com> In-Reply-To: <555DED900DD42348B2995D1005EF1662025D1B1909@IE2RD2XVS151.red002.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] [Spam] DAO No-Path in a storing mode Thread-Index: Acvkvkv5WMkOvK4mRFulxe9F09JB4wAlb75gAAE7GUA= References: <6A2A459175DABE4BB11DE2026AA50A5D0423F100@XMB-AMS-107.cisco.com> <555DED900DD42348B2995D1005EF1662025D1B1909@IE2RD2XVS151.red002.local> From: "Pascal Thubert (pthubert)" To: "M Pouillot" , "C Chauvenet" , X-OriginalArrivalTime: 18 Mar 2011 10:51:24.0869 (UTC) FILETIME=[6CFF7750:01CBE55A] Subject: Re: [Roll] [Spam] DAO No-Path in a storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Mar 2011 10:50:07 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBE55A.6CCB99A7 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CBE55A.6CCB99A7" ------_=_NextPart_002_01CBE55A.6CCB99A7 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bonjour Mathieu: =20 There are multiple causes for removing a parent. In the case of a broken link, depending on the medium, there's a chance = that the other end hears but you don't know. So it may make sense to = give it a try but maybe not insist. Nevertheless, the SHOULD is not a MUST for a number of reasons; people = in particular insisted that in a number of constrained cases, a path = that's not being used should not cost in control, even to break it = down; so being reactive to traffic might be what you really want. - if the path is still used and the child can no more reach the target = or does not want to serve that ex-parent anymore, then the child can use = the datapath reactive action based on the HbH header. - if the child can still reach the destination and agrees to serve that = ex-parent for that packet, it can forward the packet still schedule a = nopath DAO to clean up the parent states. =20 Cheers, =20 Pascal http://www.xtranormal.com/watch/7011357/ =20 From: M Pouillot [mailto:m.pouillot@watteco.com]=20 Sent: Friday, March 18, 2011 11:16 AM To: Pascal Thubert (pthubert); C Chauvenet; roll@ietf.org Subject: RE: [Roll] [Spam] DAO No-Path in a storing mode =20 Hi Pascal,=20 =20 Thank you for your answer. Our problem is more on the 9.8.4, where it is = specified that a node should send a No-path DAO to its parent when this = is removed from the DAO parent set. In the case where the parent is = removed from the DAO parent set because the link is broken, then the = node can't send anymore frame to it... =20 regards, =20 Mathieu =20 De : Pascal Thubert (pthubert) [mailto:pthubert@cisco.com]=20 Envoy=E9 : jeudi 17 mars 2011 17:14 =C0 : C Chauvenet; M Pouillot; roll@ietf.org Objet : RE: [Roll] [Spam] DAO No-Path in a storing mode =20 Hi Cedric: =20 When a parent has 2 children for a same target, and it gets a no-path = DAO for that target from one of those children, then it should clear its = adjacency for that child but keep the RIB entry for that target via the = other child. As a result, it still has a route so it must not send a = no-path to its own parent. OTOH, if the node loses its last child for a = given destination, then it should send a no-path DAO to clean up. A = no-path DAO is still a DAO though the information is 'negative'. The = spec leaves some space for an node to be reactive to datapath validation = for that though. =20 Pascal http://www.xtranormal.com/watch/7011357/ = =20 =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = C Chauvenet Sent: Tuesday, March 08, 2011 5:08 PM To: M Pouillot; 'roll@ietf.org' Subject: Re: [Roll] [Spam] DAO No-Path in a storing mode =20 Hi all,=20 =20 As mentionned in the mail below, the no-path DAO message usage in not = very clear in the RPL specification. Though it is important to clarify this because it is an important = feature for reliable and reactive downward routing. =20 Section 9.1.4 clearly states that DAO massages MUST be sent on a link = local address, thus limiting the no-path DAO destination set to one hop = neighboring. But given that this message should advertise that a = downward path is no longer usable, how do you propagate this information = in the upward direction to erase that path ? =20 For instance how do you prevent the DAGroot (located several hop away) = to use a broken downward path if you can send the no-path DAO to you = link local scope only ? =20 Some papers says that the no-path DAO must be sent to the root, but this = seems contradictory with the 9.1.4 section I pointed out (DAO are link = local only in storing mode). =20 I would appreciate that people shed some light on this .. =20 Thanks=20 =20 C=E9dric. =20 =20 De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = Mathieu Pouillot Envoy=E9 : lundi 10 janvier 2011 09:09 =C0 : roll@ietf.org Objet : [Spam] [Roll] DAO No-Path in a storing mode =20 Hello , In the specification, for storing mode, it is specified that a device = should send a DAO no-path to a node which is removed from the DAO parent = set (9.8.4). For me a node is removed from the DAO parent set if it is = unreachable on link-local and so I can't send a DAO no-path to this = node. A solution to inform the old DAO parent should be to send the = No-path on the global address but it is not allowed by the specification = (9.1.4-in storing mode DAO message MUST be link-local-). So only the = lifetime will remove the route from the old DAO parent, that can take = few minutes depends of the DAO lifetime setting. What do you think about that? best regards, Mathieu --=20 =20 Mathieu POUILLOT=20 R&D Engineer=20 m.pouillot@watteco.com =20 Direct line : +33(0)4 98 01 60 05=20 Tel : +33(0)4 98 01 60 05 Fax : +33(0)4 94 14 10 80 1766 Chemin de la Planquette 83130 LA GARDE - France=20 www.watteco.com =20 Before printing think about environment and costs=20 This Message may contain confidential information intended only for the = use of the addressee named above. If you are not the intended recipient = of this message you are hereby notified that any use, dissemination, = distribution or reproduction of this message is prohibited. If you = received this message by mistake, please notify the sender by reply = email immediately. Please conduct your own virus checks before opening = any attachment as Watteco does not guarantee the integrity of this email = or attached files has been maintained nor this communication is free of = viruses, interceptions or interference. Any views expressed in this = message are those of the individual sender and may not necessarily = reflect the views of Watteco. Watteco shall not be responsible nor = liable for the improper and incomplete transmission of the information = contained in this communication nor for any delay in its receipt or = damage to your system. =20 ------_=_NextPart_002_01CBE55A.6CCB99A7 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Signature 3

Bonjour Mathieu:

 

There are multiple causes for removing a = parent.

In the case of a broken link, depending on the medium, there’s = a chance that the other end hears but you don’t know. So it may = make sense to give it a try but maybe not = insist.

Nevertheless, the SHOULD is not a MUST for a number of reasons; = people in particular insisted that in a number of constrained cases, a = path that’s not being used should not cost in control, even to=A0 = break it down; so being reactive to traffic might be what you really = want.

- if the path is still used and the child can no more reach the = target or does not want to serve that ex-parent anymore, then the child = can use the datapath reactive action based on the HbH = header.

- if the child can still reach the destination and agrees to serve = that ex-parent for that packet, it can forward the packet still schedule = a nopath DAO to clean up the parent states.

 

Cheers,

 

 

From: M Pouillot [mailto:m.pouillot@watteco.com]
Sent: = Friday, March 18, 2011 11:16 AM
To: Pascal Thubert (pthubert); = C Chauvenet; roll@ietf.org
Subject: RE: [Roll] [Spam] DAO = No-Path in a storing mode

 

Hi Pascal,

 

Thank you for your answer. Our problem is more on the 9.8.4, where it = is specified that a node should send a No-path DAO to its parent when = this is removed from the DAO parent set. In the case where the parent is = removed from the DAO parent set  because the link is broken, then = the node can't send anymore frame to it…

 

regards,

 

Mathieu

 

De : Pascal Thubert (pthubert) [mailto:pthubert@cisco.com] =
Envoy=E9 : jeudi 17 mars 2011 17:14
=C0 : = C Chauvenet; M Pouillot; roll@ietf.org
Objet : RE: [Roll] = [Spam] DAO No-Path in a storing mode

 

Hi Cedric:

 

When a parent has 2 children for a same target, and it gets a no-path = DAO for that target from one of those children, then it should clear its = adjacency for that child but keep the RIB entry for that target via the = other child. As a result, it still has a route so it must not send a = no-path to its own parent. OTOH, if the node loses its last child for a = given destination, then it should send a no-path DAO to clean up. A = no-path DAO is still a DAO though the information is = ‘negative’. The spec leaves some space for an node to be = reactive to datapath validation for that though.

 

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of C Chauvenet
Sent: Tuesday, March 08, 2011 5:08 = PM
To: M Pouillot; 'roll@ietf.org'
Subject: Re: = [Roll] [Spam] DAO No-Path in a storing = mode

 

Hi all,

 

As mentionned in the mail below, the no-path DAO message usage in not = very clear in the RPL specification.

Though it is important to clarify this because it is an important = feature for reliable and reactive downward = routing.

 

Section 9.1.4 clearly states that DAO massages MUST be sent on a link = local address, thus limiting the no-path DAO destination set to one hop = neighboring. But given that this message should advertise that a = downward path is no longer usable, how do you propagate this information = in the upward direction to erase that path ?

 

For instance how do you prevent the DAGroot (located several hop = away) to use a broken downward path if you can send the no-path DAO to = you link local scope only ?

 

Some papers says that the no-path DAO must be sent to the root, but = this seems contradictory with the 9.1.4 section I pointed out (DAO are = link local only in storing mode).

 

I would appreciate that people shed some light on this = ..

 

Thanks

 

C=E9dric.

 

 

De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part = de Mathieu Pouillot
Envoy=E9 : lundi 10 janvier 2011 = 09:09
=C0 : roll@ietf.org
Objet : [Spam] = [Roll] DAO No-Path in a storing mode

 

Hello ,

In the = specification, for storing mode, it is specified that a device should = send a DAO no-path to a node which is removed from the DAO parent set = (9.8.4). For me a node is removed from the DAO parent set if it is = unreachable on link-local and so I can't send a DAO no-path to this = node. A solution to inform the old DAO parent should be to send the = No-path on the global address but it is not allowed by the = specification  (9.1.4-in storing mode DAO message MUST be = link-local-). So only the lifetime will remove the route from the old = DAO parent, that can take few minutes depends of the DAO lifetime = setting.
What do you think about that?

best = regards,

Mathieu

--

= 3D"Description:

= Mathieu POUILLOT =
R&D Engineer

m.pouillot@wat= teco.com=

Direct = line : +33(0)4 98 01 60 05 =

= Tel= : +33(0)4 98 01 60 05
Fax : +33(0)4 = 94 14 10 80

1766 Chemin de la Planquette
83130 LA GARDE = – France
www.watteco.co= m=

3D"Description:= Before printing think about environment = and costs

This Message may contain = confidential information intended only for the use of the addressee = named above. If you are not the intended recipient of this message you = are hereby notified that any use, dissemination, distribution or = reproduction of this message is prohibited. If you received this message = by mistake, please notify the sender by reply email immediately. Please = conduct your own virus checks before opening any attachment as Watteco = does not guarantee the integrity of this email or attached files has = been maintained nor this communication is free of viruses, interceptions = or interference. Any views expressed in this message are those of the = individual sender and may not necessarily reflect the views of Watteco. = Watteco shall not be responsible nor liable for the improper and = incomplete transmission of the information contained in this = communication nor for any delay in its receipt or damage to your = system.

 

------_=_NextPart_002_01CBE55A.6CCB99A7-- ------_=_NextPart_001_01CBE55A.6CCB99A7 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAWgAA/+4AJkFkb2JlAGTAAAAAAQMA FQQDBgoNAAAIRwAADmgAABSuAAAdtP/bAIQAAQEBAQEBAQEBAQIBAQECAgIBAQICAgICAgICAgMC AwMDAwIDAwQEBAQEAwUFBQUFBQcHBwcHCAgICAgICAgICAEBAQECAgIFAwMFBwUEBQcICAgICAgI CAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgI/8IAEQgAoAD8AwERAAIR AQMRAf/EAO0AAQACAgMBAQAAAAAAAAAAAAACAwEEBQYHCAkBAQABBQEBAAAAAAAAAAAAAAABAgME BgcFCBAAAQQCAQQDAAICAwAAAAAAAAERAgMEBQYQQBIVMCETIAdQFnCAMREAAgEBBQMIBQoEBgMA AAAAAQIDBAARIRIFMVETQEHRIjKTFDQQYXFCBiCBkaGxUpIjMzVygkNTcPCi0nMkg5QVEgABAwMD AwUAAAAAAAAAAAABABEyEECRICECMVESUHCQYXETAQACAQIEBQQDAQEBAQAAAAEAESExYRBBUXEg MECBkaGx0fHwweFQYHCA/9oADAMBAAIRAxEAAAH9QuIVAAAAAAD27rrnvZjoQhum4bSdymNk2obC NiF5ZCwuhIyfMvz5IAAAAAGD6G7jHLek83Jm4bJsTOxEbBaWlpMkCwA+auAyAMHmGwVcZ6E+javT zuPAAE630f3iFbzU2zbNg2Zm6I2i4sLCRIyTAPnHg8gdazJ+Ue53tXb7lNin27ULPsvCqOQoADnv ae4dejjzoxtm0bJsFxeXFhaTBIkAfPPDpHG3XUOtT8kdByPSMKn6K8i1y+o07XMVoAPRN5j0LeHX TrxtmyXpvReXFpYWEwTMgHgPFZHEbe+jN7j4TzK/qbGp4HDjieOTbUAEqntnW45DNdKNc2i82Jm2 I2C0uJkyQJmQDwvjgdI2SeX2R9De3HmuO6xr87eiQAB2nY3pfQGmdOLjaLi8sLi4sLCRIEzIB4py WQOt7M7DsceM6TOpYctjLTZPTrS+89Z6XG7lusGiWmwWpuRcWFpMmWAEzIB49y0NWp1O5OjecRbd dtuxY7hbiMvc7bv+6x2bYGkdZLS0uLU2IuLSZYSJAmZAB5RzaR1mt5/QkadTJydtuQxW939+O47U gdaIFhYWlpMsLCwkWAEzIAPMufAAAAOw+47XshLgzVLCZMmXEyRMmSJgFgAB55o4AACdTsvvub9d g4k0yZMmSJFpYSJEiRkAsAAOjaeAAzLk/Qc97K+8icYa5IkSJEiRItJEiQMzMogZAAOoauGZbF9v Zjks9ddCk48iZJEjJIySMkiZMAmZAAANawnUtuMyArNUpMmTJIyZMmTJkySJAFgAAAAMESsqIAyD JIGTJkGTJkyACwAAAGsYMAGQDIMgGTJkGQADJkkAAACgAyAAZAMgAAEjIBkAAAAFYAABkAAGTIMg AAAAAAAAAAAAAAAAAAAAAAA//9oACAEBAAEFAvW689brz1uvPW689brz1uvPW689brz1uvPW689b rz1uvPW689brzWaLSzwPQaIv0+oS9NRqSOo1RHU6sTV6wTWa4TXa8TAwRMLDExMUTHxz8aT86zwi MnRhhhhhhhhhhhhumDHwwyxXuQQTonVPgYYYYX6S7mHH65JzbVvrtlr9tQwwwwxGCylFPGKqyf8A oiCCdEE+JhhjbbTD0uFscvN3sn+v0tlfxvim0zqMS9MvEYYYY1lP65xlS8aEQRCPRBhPiYYzMqjB xd5wrL2nHY32ZScg4vteLXf1Vp44+n3PIv8AYqoVwrgwwwxo6OmfL6RBBBhPkYYx8b2nI4W1XH9S 8d/Hacw43Dlei5n46zhcKoVQYYYYSKquLSmPQZE/0uYQTonyMMfryHV7D+v8NNPkNj4lfE+Uw5Ph 8ks9jvmGGGGNVjfpcXz/ADrYRBOiDCfGwwxTP1/K+cZflhb/AGuFqNhqeQ4CXw5bVZhw5frrEyOU 4mII0khXKyWPTHHqMmfnNhBE6IJ0T4mGLbqMeO09bsMPBitmdutTxje2Yen4dZfRgaKOLZo9Hjl+ i0ObbGCRTX4n5IX2fnFhuiDfMwxttRibnFq4Lp6sjE4PrMLG/wBC1sYLwPXSWHEKIrPi1U7cTiOu wjCxPJRVSKTks5MMMJ87DDDDDDDDGNhv1ts81YbsmGGGGGGEgsloxIw622eQw38U+ZhhhhhivElI hXCtBVYnNZDDDdmwx4uJRYpHFI1wh1lNEFVZDDdr+VZ4QT+KyRBZqo3d+SHmKqr1buPs++jdGG71 hhhvkbu2/wAn/9oACAECAAEFAvYXnsLz2F57C89heewvPYXnsLz2F57C89heewvPYXnsLzX3TWn9 JH6SP0kfpI/RTzU81PJTyU8lHHH7PDi1XbU6q+ZLQ5KFlMoL/GMXVEbtaMeVktfp66ek5pE2FULy UWX+Gvq8reyYYhWslwcZKCdjJTkeS3zeWZsI1jDDDDGnq7NhjU0/ZZY6RVi6fjFEGGGGGMerwh2T DGHmpVDAuWcCu2M02lrQYYYYY12O8uzYYY1cmllXeEMWcqy+SyXx+/AjFxCMHWmrwj2bDHiR8orf fOxUSSE65i1TPGRGuRGDGFjePasMJ9C+RJ1V1HUYSJ9mJi9swwwwwwwwxj4vbsMMMMMMJFynGbuG GGGGGIYyqQgidywwwlKkcYjBE7v80PBP+P8A/9oACAEDAAEFAnHHHHHHHHHHHHHHHHHH/wAo3fIn VV75FF75V/7uf//aAAgBAgIGPwKRypHKkcqRypHKkcqRypHKkcqRypHKkcqRypHKDn0AflvtxXRN yvPHin68qsdQtWC+09WEtR5WvlQUJ1tasnPWmy8e+p+1uQnThHkU2hk1u4W9GT6HN+5v3N/vfb+/ X//aAAgBAwIGPwL4gP/aAAgBAQEGPwLyEPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFvIQ90nRby EPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFvIQ90nRbyEPdJ0W8hD3SdFqZpNHpXdhixp4idvst+ y0n/AK0P+20oGlUwAOA4EXRb9rp+5j6LftlP3MfRb9tp+5j6Lft0HdR9Fv2+Huk6LeRh7tOi3k4u 7Tot5SP8C28tH+BbfoJ+EW/SX6BbsD6Bbsi2zkFKu5F+z0SHex+3khYm5VxZuYCzJDVtqTpgwpIp Khb/AONBk/1W/MoK+FP7nhc4+iFnP1W8VptYlZADldkOKt91gcVPqPylUbWN302VRsWxO61/I3rq wnICFhgQZpJpW7MaDnY2z6ww8Pth0VDfTR/x/wB1vWcNwsFGCr2V3WSmpqaavq3VpBSU8TTScJO0 5C7FF/8Ak2qfi6nqzopMDjTIjEL65FGYNUrIL+HeOoMG578brUlWFyCqijlCbuIge76/kwDmQ5j/ AC+iT14fTyOesqTlhpxe9wvY8wAHOScALVms6gXT4looZKjQqGORuFSMFz8IhcJGkAySM1+3q3Wo E02nNdWaw0aaTRg3cR5Vzi88yqvWY8wFtLFdWx6jT6sGQVEcJhENUi8Th4s16st5U7cLVPxLOt1X 8SNnhY7UoIb1gX2ML5P5rT6P8PMW0+ozRap8Rj9IRnqulMf6jnZnHVXeThZI41yRxgLGm4AXAfJm qDz9VftPoRN+J5Hp1GwzUmjr4+sHMZsxiplPzh39qi0gjkWXhsUluIOVhtBu57a5WVKXj4WmqdI0 y/mZJyZHH/j4Sg+21TpHifBTOUekrguYwyI1+YD2Xj57Vun0KCPxMUOm6fFu8Uy0S3ewPfZIolyR xgLGgwAUYAfJAGJOwWji+6Ot7fQx5hgOR6rLo9FTVQ1hIAlbPMyeFeFWTrRqhMi43gAjHdtt8S6L xmqX40FfJVSfqTPWw5ZZG9bSwsbTS3LTxDNJUPcFG9mNnlkon0uuiytLp0hDNwZuvDKCNqyLj6je Oa2k6YvWg0YGurv+V1aCnX63b5h8rjN2Idn8XoJ5z2eS6VWHCDWIZaCc83FX/tQfZIPntS/D0Lf9 v4mkMDXbVo0Gepf8HV9rC2nzRVjaTq9I1NFSTiLiwyQ1sjRcORAy5ogY72xGW68Wigzz6nq/xCst a1Tw0jEzKTGii9rkvSI8JSeyu22nVyaNVtDqswgpPK352JAv/Owvym1UUglZqep8JHCpgaWWo4rQ 5VRZLxipxe4XY2qPE0VQn/z4km1i7hMKSOQsAXyvjgpbq34WvGI32VFF7NsssS8207z6Mo2JyTPP MsCY9Z2CjAZjt9Vp6WTUUp3Q5o6lZEEkE0Dq6ut/OjZbT6vq2qQahqnDWnWWMCKKGFXHVVC73ZnN 7G/E3bhaKXUalGkanqKWFlnC/l1ShWuu977p5rUtfR1SGqppKPwVVxBnTw9OqRRqW90o2I57zbSt Pi1JWj06oD0K8ZCxmjJa47+3avp5tceE8bxeQzQI9LO0xmDoQgbtP71+26zU9RrzzzVsccGpwiph BrUViyLKEUffu6t2ButcLcZx+Y3ZG4ejDtHZyUUdYCYQ6uQpuvy8x9RGBtQ1OeaR6BYVUM94k4Wb F8MS94Lb7haupIaio4eoRCKpJcFrgrC8G7A3tffvAtDHDWVEMcMvFCZ1IJzxuO0vNwh9douJWTyi IKuVjEQUVY0u7HOIVxtDm1KokWJYoyh4VzQQOkkcZuQdkoMdpsZxqVQknF8RERwepUFQjPjH7wGw 4WiWCSUJD2FLA/1IZd2+AWE0g6vuLv8AQSdgtmPzDlgklHV91N/puHZHK7lF53WzSdZuYcw9OUdn ld79QfXa5Rd6Lza73eUYW7N1us3zC3VW707zbHk/Zt2R8rdy3Z/g5//aAAgBAQMBPyHzhQoUKFCh QoUKFChQq6IF6Zarw+F9tAAPjhT8HhcxNpGBqhiBoUgNDgBoP8+kAYD+HSC0L+fSBaF/LpAtDgDo XsSjk88ABU6+2ve3gqBywwOAIcBDygodEUNA1VdCOiBAIcpge6jZHVjy/RZI8owXoj4gaCSHuqDp AA9ipd+gX4hlbVb4BxwHEOXE4GvjDm+iwTZlnTkFqgLFmYWUJk5a+eG6WqIxAoMAOQcoE/WY09Ng W6qBaqY28UxOQ0FSXUQzESC65Bt4QYg+w1/euFm5in0cBOAghwDlwNeIc/B2TsiIMrWZRsrAtVCB 9bKzrJXYDIoy9A0bD1tQ08p2lqbsmfSuLCZb1Jjz49KHXohd9sYfTBLpNo73JRgUoIaVw2AnZOyd k7JUA5H7f4cMf5qO2DgCGHAIEDSGsOJp4jGAvNLsBJGKMjWo1aheRmQyeOYM6gDZzinVehsLBd2d lLbgD0R0f5BCoDkAtANADHhAE7FdRYL9czqsv14cwvjSECCBwBCHKVDiaeI1QGk+FBF4mwoYzLSI QtRi1wwXRiOFsZYVdlZxasqquyLqUwOjAuVDT9QZczeqfK7meIGDPuFp8a8KX6Xcw6uAMQIIcA5c TiaeMXdzIUHsfY+4irwJr6IemznVeTZZngMiDa3yDGWES7rQza1J0QWHUZwLJtnlNdyrq7C9VFTK oTkog7TKZoXhtlQtmg0lhY0ZlM+cavDPnK9+cIExQIIIHAHl+sFGIHyM0Cu0oFS7jSSD1krQcMVX sx9jNkU8DAEsD6+lCzQd0tazCinGsWD37XZZQjrk7MdWncl0KNaLGBwAjWCmWeuSLkdhYW3LEgoK CchTk/lbw1VyfzhBAQwgIQOIeUWoq4cl4nOR5jNEWhe2HVGebpywmw/Avvol8CCyULTLUlDArkjn EW/lhu+4RnDVXLY+vNqJgWq6lryMi68wNxrwGwW0GKBqx5CZq/gb9tEJlubq7cHDrUjv8AQgg4FS oQh6MAactX9jhpljdot94QQECBAxAgcT0H89d9BKWrignzT14gQJUrgCVwCVXk9s7Z2ztnbC7QWu hKLsMd4M83gAsoJjWOjrxOyVKJUqEOFeCvJBaF+0++jiDrdDSDdz44H2I5a7E7OCpUqVKgVwIeCv I28NJ8RADQrwak56TFGHBUqVKlSuFSuJ56HOPRHMpUrgqVKZUqUcaZXnX1zulcFcSpXhqVK8dSvJ qVK8IVK8muCvR0ymUymUymVwUSj/AKP/2gAIAQIDAT8h/bvzP278z9u/M/bvzP278z9u/M/bvzP2 78z9u/M/bvzP278z9u/M/bvzP278xZRa6zeZvM3mbjN1m/N2b03uBeXlpcvjUqVKlSpUqVKlSpUq UfZ6KpUqVKhdpW+PvALo+5KiUypUqVKmE6ytXoqlSoHC1gNu5+OGrQKrTnzlgdJUqVKnYWfj0oA1 GZg7n+coEzUPAiHJ9nf8eIH2T0oC1yxwqnQiqybKkx+EBrRK7p9KJEK3c6vTwuDvlKAa/YeIGb6f d6cbo5l3zcu8e1DNnb++k5fOO3657xIrGO/4iiu1+0DQ66byjHqasMj6YEys1SAqUGhCMdb+IM6M /WWHqILT7d4AutNMadpQqVOc+nG6IkJ1lIvLh/z/AJ3ioNV7e013/Of5lnS9eALej64A6og56vXA 9IQXHqwvG8oHOaB6vbgHKV/8+//aAAgBAwMBPyG0tLS0tLS0tLS0tLS0tLS0tLS0tly5cuXL/wCZ TL+trirXrYYsvjt9eD/3z/8ATn//2gAMAwEAAhEDEQAAECSSSSSSZWyQojzwhEkkkkklqFAIABII AP8A9xL/AP8AVMBxAIIAANtPvnttAlI2AIAAAG7GFu23xgAgIBAAANkOCNthBhIYIJAAAG5lU222 BoG4BBAAAAAqTyQAMAMJAAAIAPztE74QtIMBAABAAJI3RDSIpI3JJABAALbbbadEAAwIIAAAACSS S+JpIOABJAIAAP8A/kgRASBgAQCiAABt8AAAQSOCSATgAACZAATSSAiSQAQAAAACBAQSCkACQAQA AAAASAQQCQCAAcgAAACSAAQSAAAQCQAAAAAASSAASAQAAAAAAAAAAAAAAAAAAAAAAAD/2gAIAQED AT8Q87Dhw4cOHDhw4cOHDhU3lwqwprjq8GRxgjgNUAhD1QZkAUG/sQEwEwRS7dafihHzm4wWlHLR 7YX2i6wWlFIT2QZO+CGPodH9oaPZi/qfQgL+oaYOwSiqrHSWlpaWlpaWlpaWlpaWjUXpHWKTG4v7 8A5Gu/dDpuwlYwOn8uHjeGw2/M16YESiic00E0+/A1O/gttLbS20ttKw9lEbpgBlVoiz8lyUpJTm aOc+ytXYCGzdorNSFEoNRtK9JbaW2ltpbaW2gJWL7gfvDioP2IfaHgCjsLmbkUndzNKnSPTnRMaJ y9py9pzT+qGpw0+/DS8FZWVgpqsKFTRDRQAyMNRr6NEdK7oESp0IBBVAMA5BHCaYlIDJU5SYE+Rp G2mGQA2AiRc9NgIqF6V86lZWVlZYVmWFgUb+DhnOu7Vf1YOKxAb0QYTcgyQEtIxpmc0/qhqd5ocd K3t4qRLV1VHMdhBjLC4L616GyQAQkB0BJbK0Lj0VNQTH2HSl0fThMuIjYN2DZXAJql6KLNc9S1dX lL0gyREUaLEcgA2PDVYsbbFRPlHtwyNltsPuL8Q3AxsPXNwlBNZoVyhaCu852XUPIicmCZCa+Ol4 uyNYRaxRMFDkuDkdg2ASpDhIJZmLVfBJR568iAJpQkQ7lEC84LJEDnsOq1C86K8oQn3oc3AMAKDB 4fUCMLKigO6ykNJTu/3TwIHIu5aNndtj4QvaYgTkBcpbNIxeJq9pdsHKHFw6PmAMhNLx0vBfaX2l E10hzq5lXjAKKUuAySUHAlQASzfMreBQoWWatZW0Q+opgUGiLzAQosAscLqVZURfaX2l9pfaX2ip ZpbmCfY+VcL6UH0q/bWaVO6xCkyay8dTnFKxLguYLMXOaZU7Q1O/DTx0vB2v1na/Wdr9YVh44Y2X GeoDGWpR5Ukddho3vFE5xc2mBgslKPJaQNmXtTPOYy3VIwjoH8+wVE4vgNmqVKDMXo+5WAsZbT3T F1cAyRYKI5bZaHIiajHJm7167GrtMAoXTTlJ3fpwbMrx0ed7aQnCSnFY6zAr4iYsiaddJ1OU0XQ6 QasSxrHhNDwdk7JiOGadCgrNWArgmOGNblCMLWQtKj4kZYqNvanpb+EkLDXsWLOtJZ2atGzEYDxZ DGO7VZIZlVshdI6W6WNa+XiVO3HUl/8AKNP7gKVGEnKKICg7BoTQRSNlc/k6GOvCxKL+qdfZLc83 Xmyzv0l+E95QprLPfSVOSq0hujTEJtYBoc4Gge0QRTiaHj7DWBCwrJzXUWXcGBKDoa3IyLajFLGr PJ6NhiKhsQhym8VuPSiEuNQtTCBXKtaECok5YRxSCxVAK4GQhBNwH+0vVkx0Gsc8SnFi4LnUeYxr n4FoZC6ORz4VtBamBccWaGh+YB2lFdOcCh0uDPeFIHF6w4uafeafeGp38BoeG8vLy8vLy8vLxnSF J16EuhtzgAAFBoRQKUGVdAly0XDr6v6mCtJg6R6x8yjv1iaxEUSgrmxLtKrgFFfMFp4Dw9s7Z2zt nbO2dsYpoRb/AIbxwwadVPfV34KAq0GVeUUbQfy7QyhV0reZcazLnO0L8oHnDZX80lG6wS6VvKOk BLYDRz4haHi/hmfwzP4Zn8Mz+GYpP0QKvsS1FnevbQ9/iUpB3+4uXgn5gMufuzu/EO5howENEX5u JtQ9sCbw5sMTneFd+NbQHSUdPF3zvj1K+gn7SjqjZ/19IeldQUfL+IDTHOtruueNuOx5d2Zkq0ND twjAzW0DjEvzZWHQQbridwwF0IUu5r4mpAHkBf7P3Zp2kBQDoFeDnp0MsBRV6avvDLSt2X6yu8C6 Fwfad8Cbyqg0uBrOWAGkp6Qoq44mp38tQytE6lehn7TrTu/5MM0Ohj7QfSped0DzzAGhNiXnfNqa YJrgm1K9YFFeA1O/k7z5jfVPvFupcttLzczulesCbyjpxp6S8OtgTeUGh4aYNgxHyby8vO6d07p3 SvWBN5R0lHTxVekt0ndAmuZR0lHTzqekp6Mp6M2JsTam1Nqe1L9Z3TamxKrT/of/2gAIAQIDAT8Q 879+/fv379+/fv379+drLKpXLqrc/fMf9Zn7Jn7ph/rMeq+Wbz5Zvvlm6+ZvPzN9+Zus3JeWl+f/ AP2Ns/sXweJH0Px1o50H2T2YgzHzT5JT4voR1QfLUIToAfHB4kfMvLy8+0AXVegc2DROcjTs5G+s qGC6uCLBoGA7PTZwxdRsnw1Ly8vLxj8lb6vvXAjxPPAKtqDeHmV1ubHT7tWXZpy3iMweVS2eRgiF nSNN245autEtz18IVi88Pu/1wPAeebY13dX4x78H7qd/1BeoQnOc/Bj6yjd4QMBa4IA2oz3cv14c vBfn908hVU2GFvFV0cRgli7oXkDYGjtAuKKgVdxp/wA6mZzwOfkflo+fF/F3S35PjX44EeJ6H2Bo QdzD9H6SptWO5g+NfaYBoWHWg+2XdkjpAIpnCjTFokt1R7XG3Z+xHLIXkpooNrVOpgtvEp6ck1Fi tMY1DNZxKtkP5UonKo1erzeB4D0G5guIC0kxh1w7JcXOXi3PNvnjToe8ogcDRz0e3U5xCrEWKw2V XcTDyojna1OOT9tJRgOORQBVOa0OVZLlGEEqtlotna83SXAraTC2LGx+XgEfSaV4tV/NzU3lpKLe 11p0qsdLesakW7Ppvpiuyy1VRUrn0Trzv7QEaovvra3ru2i7wF289URdeY6aHIgrASurNrDXl116 stXP8of2+kvh4aHXd26dfIv0/wDr4Ww699toFcDHqwFMbZXZ+jkfl416r41o1mWwfX/JTjX34nif RS6C50d3nMfiH415T5N+RtpoQ+IA08V+sr/o1/6v/9oACAEDAwE/ENybk3JuTcm5Nybk3JuTcm5N ybkepNybk3JuQ60XLy0tLS0tly/BiYmJiYmJiYmJiYmJiYj4SPmXLly+A0YOJcuXLly/ER88SwTg OqAvifEEfPrYYXLVcMDxPiPPeFwEobh5t+geCQ8T4j0LpwVKlSvKI+iuXwvySaeguXLly5cuXHx1 L9dXqL/5D5FenfJv/wA7UT0l+Xf/AIv/2Q== ------_=_NextPart_001_01CBE55A.6CCB99A7 Content-Type: image/gif; name="image002.gif" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image002.gif Content-Location: image002.gif R0lGODlhGAAXANUiADamKSuhHonKgla0TG29ZEmuPiGbEyliIC+HJBp9DZ+inEGqNYLGel22Ury/ uWW5W3+DfODW4NDK0sS7xU2wQmSPXaTVnZDNiN3v2pzSlpTPjbfespjQkXnCcMLjvlKxRsnmxbLc rAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACH5BAEAACIALAAAAAAYABcAAAb/QM9g SCwajwNMwxBoOgOA6BPwDBgYBGh0a0gkDNvwNiDIig+QyQRy0IqpZTfgIBHZRZLDWxrnKu53Dl9v ZGYBXg6AdhgKCghyhVAHEw51incHFFR8WQZ/l4AQBgMMD1AGcQGfoCIRCVQBBA1NqRWsdwpgAFdw ZgiJtxF6VA8UqGYACROKDhF2wlIEBccBCwmrdhKrEK9UDLS+l6vCCwIMs3CmAAi2dwwHFhJs1RYF GwK7fbvsFQgJbf52NbiQAUDBSFEWwEJwAEFCAxc0yBIwC6EYhggURqHA4UEfi2EONAwToIOFD1pA hnkkxskYAQ/AQJk5ZpNNLVdCFNjJs+dOBwo+eS4AEQQAOw== ------_=_NextPart_001_01CBE55A.6CCB99A7-- From pal@cs.stanford.edu Sat Mar 19 15:45:09 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44D183A6A29 for ; Sat, 19 Mar 2011 15:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.549 X-Spam-Level: X-Spam-Status: No, score=-6.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1kpXF9CrZPwU for ; Sat, 19 Mar 2011 15:45:08 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 917453A68FE for ; Sat, 19 Mar 2011 15:45:08 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Q14ut-0001AT-LH; Sat, 19 Mar 2011 15:46:39 -0700 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0423EE17@XMB-AMS-107.cisco.com> Date: Sat, 19 Mar 2011 15:46:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <44CE3F17-3A2C-4DBB-8C03-C83A4FE61464@cs.stanford.edu> References: <20110314094501.1366.59375.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D041A22B7@XMB-AMS-107.cisco.com> <9F3EA16A-3390-4FEE-9EA3-96018FBB7CF2@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0423EE17@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: d568c20fab0e2ccae07d583947984559 Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Mar 2011 22:45:09 -0000 On Mar 17, 2011, at 1:44 AM, Pascal Thubert (pthubert) wrote: > [Pascal] LC was terminated on the 10th of March. We are actually = fixing > the issues that were opened but not resolved at that time. > It seems that the shepherd (JP) agrees to reopen the sibling = discussion, > but we cannot rework the whole doc.=20 > And the RFC editor will fix the language, don't worry about that. >=20 > Pascal I thought JP re-opened the last call until the 21st because the changes = between -05 and -07 were very significant? Here's the message: On Mar 14, 2011, at 8:50 AM, JP Vasseur wrote: > Dear Working Group, >=20 > Since some of changes took place at the very last minute, I would like = to start another WG Last Call on the > revision 07 of draft-ietf-roll-of0 that end on March 21 at noon ET. = Please send your comments to the Author > and copy the mailing list. >=20 > Thanks. >=20 > JP. Phil= From pthubert@cisco.com Mon Mar 21 00:50:19 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1EA33A67E3 for ; Mon, 21 Mar 2011 00:50:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.426 X-Spam-Level: X-Spam-Status: No, score=-10.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7uhJ7H7BVWKj for ; Mon, 21 Mar 2011 00:50:18 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 008CB3A67DF for ; Mon, 21 Mar 2011 00:50:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1328; q=dns/txt; s=iport; t=1300693910; x=1301903510; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=axrPKFI1VNjmD+3Ztn6rAn5FYeibLCTVVBwsqbIeQ6I=; b=ItwHBHc6wpohcuDgejnZVzRyYfbYs/LAFmxHnCenPuxousfg9O55znTv 2mPTRMDkK3eDc8G36HvJviAlWSVfvyK5QO8YDgiBmJis9d5s98lqjVniB lo/ZIzLBLK+YlcGef0Vgh1kwViWgC0z4++E7//rsNyFk7JL44oLbL9s7b E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIAAMufhk2Q/khMgWdsb2JhbACYMY05FAEBFiYlpCebIIVjBJA+iHI X-IronPort-AV: E=Sophos;i="4.63,218,1299456000"; d="scan'208";a="80015138" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 21 Mar 2011 07:51:49 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2L7pnJR010501; Mon, 21 Mar 2011 07:51:49 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Mar 2011 08:51:49 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Mon, 21 Mar 2011 08:51:45 +0100 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D0423F7F6@XMB-AMS-107.cisco.com> In-Reply-To: <44CE3F17-3A2C-4DBB-8C03-C83A4FE61464@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] I-D Action:draft-ietf-roll-of0-07.txt Thread-Index: Acvmh4UjTUZfPnKSTXyoanTsM8UWYwBFTwIA References: <20110314094501.1366.59375.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D041A22B7@XMB-AMS-107.cisco.com> <9F3EA16A-3390-4FEE-9EA3-96018FBB7CF2@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0423EE17@XMB-AMS-107.cisco.com> <44CE3F17-3A2C-4DBB-8C03-C83A4FE61464@cs.stanford.edu> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 21 Mar 2011 07:51:49.0743 (UTC) FILETIME=[D5C2F7F0:01CBE79C] Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 07:50:19 -0000 Sorry Phil, I had missed that. Back to the discussion then. Pascal http://www.xtranormal.com/watch/7011357/ > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Saturday, March 19, 2011 11:47 PM > To: Pascal Thubert (pthubert) > Cc: ROLL WG > Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-07.txt >=20 >=20 > On Mar 17, 2011, at 1:44 AM, Pascal Thubert (pthubert) wrote: >=20 > > [Pascal] LC was terminated on the 10th of March. We are actually > > fixing the issues that were opened but not resolved at that time. > > It seems that the shepherd (JP) agrees to reopen the sibling > > discussion, but we cannot rework the whole doc. > > And the RFC editor will fix the language, don't worry about that. > > > > Pascal >=20 > I thought JP re-opened the last call until the 21st because the changes > between -05 and -07 were very significant? Here's the message: >=20 > On Mar 14, 2011, at 8:50 AM, JP Vasseur wrote: >=20 > > Dear Working Group, > > > > Since some of changes took place at the very last minute, I would like > > to start another WG Last Call on the revision 07 of > > draft-ietf-roll-of0 that end on March 21 at noon ET. Please send your > comments to the Author and copy the mailing list. > > > > Thanks. > > > > JP. >=20 > Phil From antonio.grilo@inov.pt Mon Mar 21 06:10:07 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C4743A684F for ; Mon, 21 Mar 2011 06:10:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5Zlt5VDrtx7 for ; Mon, 21 Mar 2011 06:10:06 -0700 (PDT) Received: from lmv.inov.pt (lmv.inov.pt [146.193.64.2]) by core3.amsl.com (Postfix) with ESMTP id 159AD3A684E for ; Mon, 21 Mar 2011 06:10:05 -0700 (PDT) Received: from localhost (indico.inov.pt [146.193.64.7]) by lmv.inov.pt (8.13.1/8.13.1) with ESMTP id p2LDBQnV007500 for ; Mon, 21 Mar 2011 13:11:26 GMT Received: from gtout2.inov.pt (gtout2.inov.pt [146.193.64.1]) by webmail.inov.pt (Horde MIME library) with HTTP; Mon, 21 Mar 2011 13:11:26 +0000 Message-ID: <20110321131126.nsqi7zfzzksos8g0@webmail.inov.pt> Date: Mon, 21 Mar 2011 13:11:26 +0000 From: antonio.grilo@inov.pt To: roll@ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (lmv.inov.pt [146.193.64.2]); Mon, 21 Mar 2011 13:11:26 +0000 (WET) X-INOV-EmailServer-Information: Please contact the Email service provider for more information X-INOV-EmailServer: Found to be clean X-INOV-EmailServer-From: antonio.grilo@inov.pt Subject: [Roll] Questions on draft-dvir-roll-security-extensions-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Mar 2011 13:10:07 -0000 Dear BME colleagues, I have two questions which are probably misinterpretations or otherwise have to do with some assumptions that I have not found explicit enough in the draft: - 3.1 DIO Message Authentication In step 3, the DODAG root authenticates the message. However, if this is not done using asymmetric crypto, any compromised node can propagate false DIO messages locally calculated based on a locally generated random number r2. I failed to understand how the nodes receiving these messages (which are in fact authenticated by the compromised node using a common key) can be sure that it was really the DODAG Root to generate them. For new nodes joining the network, we have the same problem. - 3.2 Local Key Agreement The definition of a time T, seems to imply that the network cannot accept new nodes after T. However, from the algorithm you present, I think that this is not the case, right? Although the nodes delete the preshared key after T, it is enough that each node 'u' retains Ku in order to derive more pairwise keys, right? Best regards, Ant=F3nio From Adrian.Farrel@huawei.com Tue Mar 22 13:17:56 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5025628C13D for ; Tue, 22 Mar 2011 13:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZbGKyDSkbnfy for ; Tue, 22 Mar 2011 13:17:55 -0700 (PDT) Received: from usaga03-in.huawei.com (usaga03-in.huawei.com [206.16.17.220]) by core3.amsl.com (Postfix) with ESMTP id A886B28C12E for ; Tue, 22 Mar 2011 13:17:55 -0700 (PDT) Received: from huawei.com (usaga03-in [172.18.4.17]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LIH00LQE74GHY@usaga03-in.huawei.com> for roll@ietf.org; Tue, 22 Mar 2011 15:19:29 -0500 (CDT) Received: from 950129200 (customer62200.101.kt.cust.t-mobile.co.uk [178.101.242.247]) by usaga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LIH005AU740ND@usaga03-in.huawei.com> for roll@ietf.org; Tue, 22 Mar 2011 15:19:28 -0500 (CDT) Date: Tue, 22 Mar 2011 20:19:13 +0000 From: Adrian Farrel To: roll@ietf.org Message-id: <02c701cbe8ce$70d8bb30$528a3190$@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Outlook 14.0 Content-type: text/plain; charset=us-ascii Content-language: en-gb Content-transfer-encoding: 7BIT Thread-index: AcvozmbNje6NbnaPTiyc0jkH2nKFkQ== Cc: roll-chairs@tools.ietf.org Subject: [Roll] ROLL Milestones updated X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Adrian.Farrel@huawei.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 20:17:56 -0000 Hi ROLL WG, After discussion with your chairs, I have authorised some additional milestones in your charter for applicability work. This work was already mentioned in your charter, but previously had no explicit milestones. Given that a lot of the discussion with IESG over the RPL spec has focused on applicability, this work is very timely. Adrian From pal@cs.stanford.edu Wed Mar 23 10:32:44 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21F6B3A693B for ; Wed, 23 Mar 2011 10:32:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PUteR25Y3r7l for ; Wed, 23 Mar 2011 10:32:42 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 8EB393A693A for ; Wed, 23 Mar 2011 10:32:42 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.103]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Q2Rwm-0001di-AL; Wed, 23 Mar 2011 10:34:16 -0700 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D0423F7F6@XMB-AMS-107.cisco.com> Date: Wed, 23 Mar 2011 10:34:15 -0700 Content-Transfer-Encoding: 7bit Message-Id: <2B13A01A-7F03-47D7-AC9D-8941D1061AC3@cs.stanford.edu> References: <20110314094501.1366.59375.idtracker@localhost> <6A2A459175DABE4BB11DE2026AA50A5D041A22B7@XMB-AMS-107.cisco.com> <9F3EA16A-3390-4FEE-9EA3-96018FBB7CF2@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0423EE17@XMB-AMS-107.cisco.com> <44CE3F17-3A2C-4DBB-8C03-C83A4FE61464@cs.stanford.edu> <6A2A459175DABE4BB11DE2026AA50A5D0423F7F6@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1082) X-Scan-Signature: 58355bea2820b4cf9b9c8322cdf0b49d Cc: ROLL WG Subject: Re: [Roll] I-D Action:draft-ietf-roll-of0-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 17:32:44 -0000 On Mar 21, 2011, at 12:51 AM, Pascal Thubert (pthubert) wrote: > Sorry Phil, I had missed that. Back to the discussion then. > > Pascal > http://www.xtranormal.com/watch/7011357/ OK, can you pick up the on the comments I made? Phil From holczer@crysys.hu Fri Mar 25 05:25:21 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD44C3A696A for ; Fri, 25 Mar 2011 05:25:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.296 X-Spam-Level: X-Spam-Status: No, score=0.296 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yo5G5vpbOMxW for ; Fri, 25 Mar 2011 05:25:20 -0700 (PDT) Received: from shamir.crysys.hit.bme.hu (shamir.crysys.hit.bme.hu [152.66.249.135]) by core3.amsl.com (Postfix) with ESMTP id 4FE7C3A69AB for ; Fri, 25 Mar 2011 05:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crysys.hu; s=shamir; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=LKaCPcQi6Kye3u1ahplIiZtv8Yscil/hYQSH55ZFWUs=; b=W53zHxPETQZct8aFdlSbmFVK107qUuNtuGEmXJ5fD3RSXG0KP5usm8LdOtUMcF3ZpusI6M/5D7HglT395J2af7iS8q2zhYY3rf8mDRCYzo0jzjcTyc1KL4y+krGxYjjAwJ/STEYf0qd8akjjfntquAgNcKTM+X8sCfa3g8iN1rk=; Received: from ip10-105-55.ebizlab.hit.bme.hu ([10.105.1.55] helo=localhost ident=amavis) by shamir.crysys.hit.bme.hu with esmtp (Exim 4.72) (envelope-from ) id 1Q363I-0007Qx-JP; Fri, 25 Mar 2011 13:23:40 +0100 X-Virus-Scanned: by amavis-dc Received: from shamir.crysys.hit.bme.hu ([10.105.1.254]) by localhost (seeve.etl.hu [10.105.1.55]) (amavisd-new, port 10023) with ESMTP id LxVZPbRG8woB; Fri, 25 Mar 2011 13:23:34 +0100 (CET) Received: from ip10-105-210.ebizlab.hit.bme.hu ([10.105.1.210]) by shamir.crysys.hit.bme.hu with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Q363C-0007Qq-Gf; Fri, 25 Mar 2011 13:23:34 +0100 Message-ID: <4D8C8945.4040108@crysys.hu> Date: Fri, 25 Mar 2011 13:23:33 +0100 From: =?ISO-8859-1?Q?Tam=E1s_Holczer?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: roll@ietf.org References: <20110321131126.nsqi7zfzzksos8g0@webmail.inov.pt> In-Reply-To: <20110321131126.nsqi7zfzzksos8g0@webmail.inov.pt> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Questions on draft-dvir-roll-security-extensions-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 12:25:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Antonio, thank you for commenting our draft. The answers can be found inline On 2011.03.21. 14:11, antonio.grilo@inov.pt wrote: > Dear BME colleagues, > > I have two questions which are probably misinterpretations or otherwise > have to do with some assumptions that I have not found explicit enough > in the draft: > > - 3.1 DIO Message Authentication > In step 3, the DODAG root authenticates the message. However, if this is > not done using asymmetric crypto, any compromised node can propagate > false DIO messages locally calculated based on a locally generated > random number r2. I failed to understand how the nodes receiving these > messages (which are in fact authenticated by the compromised node using > a common key) can be sure that it was really the DODAG Root to generate > them. For new nodes joining the network, we have the same problem. Possibly it is not clear from the text, that this key K is the same as in section 3.2, meaning that it must be deleted after a small time. We assume that it is not compromised before this safe time period. It can be used to authenticate the first hash value received by the node. This is not a suggested method, because it is impossible to reload the hash chain after deleting K. This solution can be used for short or pregiven lifetime networks. We will clarify this in the next version of the draft. > > - 3.2 Local Key Agreement > The definition of a time T, seems to imply that the network cannot > accept new nodes after T. However, from the algorithm you present, I > think that this is not the case, right? Although the nodes delete the > preshared key after T, it is enough that each node 'u' retains Ku in > order to derive more pairwise keys, right? You are right, it is enough if the new (joining) node has the preshared initial key K, and the neighbors own their key Ku. > > Best regards, > António > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > Best regards, Tamás - -- Tamas Holczer Assistant Research Fellow Laboratory of Cryptography and System Security (CrySyS) Budapest University of Technology and Economics (BME) URL: http://www.crysys.hu/members/tholczer/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFNjIlF0S3k5mFYongRAgNXAKCVrBW3txdzgWG6mUpp4QP97UaOPQCfclFK bMEsECXBaYG0Vz0SRD+obRU= =GWiN -----END PGP SIGNATURE----- From holczer@crysys.hu Fri Mar 25 05:48:50 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 242613A69AB for ; Fri, 25 Mar 2011 05:48:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.296 X-Spam-Level: X-Spam-Status: No, score=0.296 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_HU=1.35, HOST_EQ_HU=1.245, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39QS-1tsw0fX for ; Fri, 25 Mar 2011 05:48:48 -0700 (PDT) Received: from shamir.crysys.hit.bme.hu (shamir.crysys.hit.bme.hu [152.66.249.135]) by core3.amsl.com (Postfix) with ESMTP id E552F3A688F for ; Fri, 25 Mar 2011 05:48:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=crysys.hu; s=shamir; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:References:Subject:CC:To:MIME-Version:From:Date:Message-ID; bh=7hYSQCKP8263HK6ZYeDt8QkXkdSO5SKLsSR6Lo2/GdM=; b=HMOSU3d4fO/H87JCHDSx5jMyYTaqNgWMw2mLukJqzNg90qgE1ZQ3LCQ28XlDwVs/Uow9xZ3wIdopBkGt5S3JrxGs41oQF2ry7XrZ+Sh4/rjSvAZBwHasWXhXrkuRrrQvKDDVyR/f94kKJIbj/rxTt/XPx884FMIP6YbpTdFEJNo=; Received: from ip10-105-55.ebizlab.hit.bme.hu ([10.105.1.55] helo=localhost ident=amavis) by shamir.crysys.hit.bme.hu with esmtp (Exim 4.72) (envelope-from ) id 1Q36Q0-0007pd-Jw; Fri, 25 Mar 2011 13:47:08 +0100 X-Virus-Scanned: by amavis-dc Received: from shamir.crysys.hit.bme.hu ([10.105.1.254]) by localhost (seeve.etl.hu [10.105.1.55]) (amavisd-new, port 10023) with ESMTP id KUP0c6L3w1TU; Fri, 25 Mar 2011 13:47:02 +0100 (CET) Received: from ip10-105-210.ebizlab.hit.bme.hu ([10.105.1.210]) by shamir.crysys.hit.bme.hu with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Q36Pu-0007pL-79; Fri, 25 Mar 2011 13:47:02 +0100 Message-ID: <4D8C8EC5.5020705@crysys.hu> Date: Fri, 25 Mar 2011 13:47:01 +0100 From: =?windows-1252?Q?Tam=E1s_Holczer?= User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: roll@ietf.org References: <24055.1300384471@marajade.sandelman.ca> In-Reply-To: <24055.1300384471@marajade.sandelman.ca> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [Roll] review of draft-dvir-roll-security-extensions-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Mar 2011 12:48:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Michael, On 2011.03.17. 18:54, Michael Richardson wrote: > > I read this document in January, and the authors and I had a short VoIP > chat about it. I promised to post my thoughts, but life has > intervened. > > My first comment is that this is two documents: > 3.1 DIO Message Authentication . . . . . . . . . . . . . . . . 5 > 3.2 Local Key Agreement . . . . . . . . . . . . . . . . . . . 13 > > I believe that it should be split up into two documents. > We will consider it for the next version/s. > To first order, 3.1 DIO Message Authentication is a problem statement, > it details a limitation in the security model that we have assumed, and > then presents a short solution. I'd like to see the threat more clearly > outlined. > We will try to clarify the threats and attacker model in the next version of the draft. Mainly we are interested what can a compromised node do. The source of the compromise can be logical [1] or physical [2]. The motivation to authenticate the version number in the DIO message is the following: - DIO is mandatory - energy consumption - has network wide influence - all traffic can be hijacked We will try to describe the motivation in the next version of the draft. The motivation for the key exchange is the following: - elegant and efficient solution - assumption is quite realistic for LLNs - RPL sec framework mentions pairwise keys, but no specific algorithm is given Actually many other solutions for the key exchange can be implemented, it is only one suggestion. > 3.2 Local Key Agreement is a solution to a slightly different problem, > and there is some cryptography there which I did not pay enough > attention to, in great part because I want to make sure that we know > what problem we are trying to solve, and I do not think that 3.1 is > solveable with JUST per-peer authentication keys. Creating per-peer > authentication keys significantly mitigates some attacks that, but I'm > not actually sure which attacks it defends against, because we do not > yet have a clear risk assessment of what nodes within a pre-installed or > authenticated network can do if they decide to be malicious. > > (I would have liked to see this analysis in the Security Considerations > section of the main RPL document, but I agreed that it could be out of > scope for the base spec, which assumes all nodes are trusted) > Our two extensions are independent, section 3.2 is not intended to solve the question of section 3.1 and vice versa. > > In particular, there is an assumption that for some class of devices it > will be possible to to subvert individual devices in some small bounded > amount of time (I'm guessing hours to small number of days), and > retrieve the important RPL parameters (the RPL pre-installed keys, > or the layer-2 security keys) such that fake messages can either be sent > out by a rogue node, or that the subverted node can be forced to become > a trojan. > > > I'd like to see this assumption made more clear: what are the real > attack methods for closed networks operated by a single entity? > We will try to clarify the threats and attacker model in the next version of the draft. Mainly we are interested what can a compromised node do. The source of the compromise can be logical [1] or physical [2]. > > I do not think, however that this attack being unimportant for many use > cases invalidates this work: I am interesting in more open networks (I > think that many home networks will be such) where it is impractical to > use layer-2 security, and we will rely upon layer-3 RPL security with a > combination of unsecured networks with an enrolled system that gets > visitors to your home into the pre-installed state. The devices that > such visitors bring will only be partially trusted, and will generally > be running on untrustworthy devices. > > > To that end, I'm going to actually ignore the bulk of the document as > technical details, and focus just on 3.1. > > > Section 3.1 worries about what happens if some node in a DODAG > (why does it matter if it's grounded?) starts to send out messages with > a malicious intent to disrupt traffic. > > > In The RPL base spec, we assume that nodes are either in the DODAG, or > they are not. I'm going to ignore the leaf/router node for now, because we > can not yet make this work without assymetric encryption. > > Section 3.1 is about protecting some critical information using a hash > and does not require assymetric encryption. There is a problem with how > do nodes bootstrap into getting an authentic h^n(r), and the document > punts slightly by suggesting that a digital signature be used. It > assumes that we can amortize the cust of verifying this digital > signature over n-Version increments. > > How often do version numbers increase, > vs how costly is a signature verification, > vs how big can we make n? How often do the version number increase: out of scope of this draft (application depended). For a normal node (Micaz) it is very costly to digitally sign and verify, therefore we are using it only for bootstrapping or infrequently to reload the hash chain. It is a question of a trade-off between memory, computation of the DODAG root and the cost of a signature verification [OptHash]. Note that using the version authentication, only the root can increase the version number, so it can control the exhaustion of the chain. Possibly, we will be able to give some guidelines after analyzing the performance of our RPL implementation. > > The above are questions that need to be researched, and the answers > detailed in applicability statements for different RPL usage. > > I do not believe that any of our existing MAC functions work because > in effect, every node that has the symmetric key preshared key K > can send such messages, and we are really back to square one: all nodes > are equally trusted. > Possibly it is not clear from the text, that this key K is the same as in section 3.2, meaning that it must be deleted after a small time. We assume that it is not compromised before this safe time period. It can be used to authenticate the first hash value received by the node. This is not a suggested method, because it is impossible to reload the hash chain after deleting K. This solution can be used for short or pre given lifetime networks. We will clarify this in the next version of the draft. > Now, at this point we have authenticated the DIO message. > My question is, what other things would be worth authenticating in this > fashion? > > How much more can we do using mechanisms like the one presented in > section 3.1? I'm thinking about if it becomes worth authenticating some > or all DIS or DAO messages as well. > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll [1] A.Francillon and C.Castelluccia: Code Injection Attacks on Harvard-Architecture Devices [2] Ross Anderson, Markus Kuhn: Tamper Resistance – A Cautionary Note [OptHash] Don, C., and M. Jakobsson, "Almost Optimal Hash Sequence Traversal", Fourth Conference on Financial Cryptography, 2002. Best regards, Tamás - -- Tamas Holczer Assistant Research Fellow Laboratory of Cryptography and System Security (CrySyS) Budapest University of Technology and Economics (BME) URL: http://www.crysys.hu/members/tholczer/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFNjI7E0S3k5mFYongRAhxNAJ4yDU9YBumXAAWrFHm0fADK5rN3+gCeKeHj Q5WboRw5U1SiXMTBYovgVKM= =2shU -----END PGP SIGNATURE----- From jpv@cisco.com Sat Mar 26 12:08:56 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8B5B3A63D3 for ; Sat, 26 Mar 2011 12:08:56 -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=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5BxHGqdh2pW for ; Sat, 26 Mar 2011 12:08:55 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 8F5583A6804 for ; Sat, 26 Mar 2011 12:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=243; q=dns/txt; s=iport; t=1301166632; x=1302376232; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=FJEgauxWDkz9RRuZm2rWZ86XUef8+id6lY6b8cAoTQY=; b=PsYKL28A/YCYorVflZdb6R7UUsP5u9h2L7l5VgMnt6mOeKa1d+4DMKq8 tgRcL3p10B43Waasp6DLjuKJysnbeZDzOjhSkP7FJGAws2yjAheYgbHhg 4KyfFNV/u4zEdIaWMfdPoFp+pRurRaVbPejDNXKr4muncoCijv047CH1a A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuIEAKc5jk2Q/khMgWdsb2JhbAClZhQBARYmJaZum1iFaQSMdoNa X-IronPort-AV: E=Sophos;i="4.63,248,1299456000"; d="scan'208";a="80931887" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 26 Mar 2011 19:10:31 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2QJAVaQ013574 for ; Sat, 26 Mar 2011 19:10:31 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Mar 2011 20:10:30 +0100 Received: from dhcp-4202.meeting.ietf.org ([10.61.71.178]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 Mar 2011 20:10:27 +0100 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 26 Mar 2011 20:10:27 +0100 Message-Id: <3CF149C9-AB97-4578-9743-F89EDFDDDFC1@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 26 Mar 2011 19:10:27.0954 (UTC) FILETIME=[77C5A520:01CBEBE9] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18036.001 X-TM-AS-Result: No--6.048800-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] Slides please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Mar 2011 19:08:56 -0000 Dear all, If you have a slot during our ROLL WG meeting please send me your slides = no later than Tuesday 6pm CET. The agenda is quite full, and I'd like to make = sure that slides are available before the meeting. Thanks. JP.= From mcr@sandelman.ca Mon Mar 28 04:49:30 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D43013A67E6 for ; Mon, 28 Mar 2011 04:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.274 X-Spam-Level: X-Spam-Status: No, score=-1.274 tagged_above=-999 required=5 tests=[AWL=0.680, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e26jVoWvsovH for ; Mon, 28 Mar 2011 04:49:29 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 9C47E3A6817 for ; Mon, 28 Mar 2011 04:49:29 -0700 (PDT) Received: from marajade.sandelman.ca (dhcp-164d.meeting.ietf.org [130.129.22.77]) by relay.sandelman.ca (Postfix) with ESMTPS id 5013F3411F; Mon, 28 Mar 2011 07:51:06 -0400 (EDT) Received: from marajade.sandelman.ca (marajade.sandelman.ca [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id B88D398B18; Mon, 28 Mar 2011 13:52:01 +0200 (CEST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <20110321131126.nsqi7zfzzksos8g0@webmail.inov.pt> References: <20110321131126.nsqi7zfzzksos8g0@webmail.inov.pt> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Mon, 28 Mar 2011 13:52:01 +0200 Message-ID: <9946.1301313121@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] Questions on draft-dvir-roll-security-extensions-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 11:49:30 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "antonio" =3D=3D antonio grilo writes: antonio> - 3.1 DIO Message Authentication In step 3, the DODAG root antonio> authenticates the message. However, if this is not done antonio> using asymmetric crypto, any compromised node can propagate antonio> false DIO messages locally calculated based on a locally antonio> generated random number r2. I failed to understand how the antonio> nodes receiving these messages (which are in fact antonio> authenticated by the compromised node using a common key) antonio> can be sure that it was really the DODAG Root to generate antonio> them. For new nodes joining the network, we have the same antonio> problem. If there is symmetric authentication in use, then it is not possible for a node to be sure that a real DODAG root sent out a hash chain root. If the key K was known to be secure when the hash chain root was sent out, then a node would continue to trust the real DODAG root, but new ones could arrive. More specifically, a compromise of K does not compromise previously authenticated hash chain roots. Asymmetric authentication solves this problem, and 3.1 reduces the frequency that you have to do asymmetric operations quite significantly, with the hope that this might make some use of assymetric authentication more useful. =2D-=20 ] He who is tired of Weird Al is tired of life! | firewall= s [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net archit= ect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device dri= ver[ Kyoto Plus: watch the video then sign the petition.=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQEVAwUATZB2YYCLcPvd0N1lAQLGtgf/XI09Sqdu1ojXEYqXk9L7CdYBuzvrWXZv AclXrsOoQXrDLyqMAdbXEWccX/IQyjtVKYIDfCgjM55tJJu4Ev9GaF71NKEguKBt KaNDC50XCW7WX/U+/5h8WxfZ+Y+z6JD6KaswD9RkbjnkzhszeZpq//bOkxlP5OC4 mSP9lzyN1iQ3rWyKLnCMIp0sf8twnKEH2wkSqWD2fHjOhTzd2cG2dJgSWqZ74Emt nTZqmvRbnFtQ/icU3XvyeeloR4EPK2SsgFqhF7qsl4n1A+12/rMhIZQhElUDmuVZ ds3ymV7CLSL/tCwH7NIBg9Un6V/oMLhlQiXCMBh5aF4GWiXh/jkf+g== =FsPp -----END PGP SIGNATURE----- --=-=-=-- From zehn.cao@gmail.com Mon Mar 28 04:49:40 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68AB23A67E6; Mon, 28 Mar 2011 04:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.732 X-Spam-Level: X-Spam-Status: No, score=-3.732 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uz1jFwOw+K7S; Mon, 28 Mar 2011 04:49:39 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 7D80D3A67B0; Mon, 28 Mar 2011 04:49:39 -0700 (PDT) Received: by iwn39 with SMTP id 39so3490781iwn.31 for ; Mon, 28 Mar 2011 04:51:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=KfZSbhgxJgv2IsC8JMl1g1O/82u6ryvqdt89szk0D/E=; b=meSliyKHiW4dUtYwLcOR9qrL6sIH2qhrSettFh3yle2n04HlxwfO3YW838vzQSyyTh cw2faDQ8zybDj3TVAF8FPRZJ5EvMklkfLvzYYHRFEwNJ7IvfkMZ45LxpIOtx9M8bqjUU 78th5GwOHJ3BwIN18ejS7r96x2T9/CU8rtJQI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=m2ucGcSIbzVsgVz0YY4ivTtQ7aHzFI6pQCXrXHDhfomYGPOyQeKbTzvgrBWJRq8f1P OJpD58dAIZ4kyGJUjOiKMMQbpivTaawfabR7VjozbMT8ocMubZKaz74s0WOOr8goeQ31 LTVwDXZ/plr7H1htwJ4aGWP7Bwc+JUG+0ufmc= MIME-Version: 1.0 Received: by 10.42.137.5 with SMTP id w5mr6333753ict.210.1301313076939; Mon, 28 Mar 2011 04:51:16 -0700 (PDT) Received: by 10.42.163.6 with HTTP; Mon, 28 Mar 2011 04:51:16 -0700 (PDT) Date: Mon, 28 Mar 2011 13:51:16 +0200 Message-ID: From: Zhen Cao To: lwip@ietf.org, 6lowpan WG <6lowpan@ietf.org>, core , roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: Jari Arkko Subject: [Roll] LWIG Meeting Room Changed to Barcelona/Berlin X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 11:49:40 -0000 Hi All, I just got a last minute notice from the session planner that the LWIG meeting room has been changed to "Barcelona/Berlin" which is on the Lobby level. Time NOT changed. Sorry for the inconvenience. -- Best regards, Zhen From pal@cs.stanford.edu Mon Mar 28 10:55:38 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751243A6A2C for ; Mon, 28 Mar 2011 10:55:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qQY0bPI-yt-H for ; Mon, 28 Mar 2011 10:55:37 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id C57033A67D1 for ; Mon, 28 Mar 2011 10:55:37 -0700 (PDT) Received: from [88.103.5.85] (helo=[192.168.1.32]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Q4Ggk-0000ZN-6i for roll@ietf.org; Mon, 28 Mar 2011 10:57:15 -0700 From: Philip Levis Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Mar 2011 10:56:46 -0700 Message-Id: <9F9E6516-BAD5-46FD-978B-29DE1234783A@cs.stanford.edu> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Scan-Signature: 9f3c248a972b2d7af50d43d52b81e7b3 Subject: [Roll] OF0 algorithm: implementer feedback wanted X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 17:55:38 -0000 Pascal and I have been discussing the suggested algorithm in OF0 = (sections 4 and 5). We're wondering if anyone can provide some = experiences in whether the order of the set of rules is close to their = approach, whether it needs to be less restrictive, or provide greater = guidance on a good basic way to do things. Time is of the essence here, = as he'd like to get these experiences into -08. Thanks! Phil= From wwwrun@rfc-editor.org Tue Mar 29 01:53:25 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 892B03A687E; Tue, 29 Mar 2011 01:53:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.116 X-Spam-Level: X-Spam-Status: No, score=-102.116 tagged_above=-999 required=5 tests=[AWL=-0.116, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RpZm7p+GFVRc; Tue, 29 Mar 2011 01:53:24 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:1112:1::2f]) by core3.amsl.com (Postfix) with ESMTP id 01A8B3A6930; Tue, 29 Mar 2011 01:53:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 693DBE0784; Tue, 29 Mar 2011 01:54:34 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20110329085434.693DBE0784@rfc-editor.org> Date: Tue, 29 Mar 2011 01:54:34 -0700 (PDT) Cc: roll@ietf.org, rfc-editor@rfc-editor.org Subject: [Roll] RFC 6206 on The Trickle Algorithm X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 08:53:25 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6206 Title: The Trickle Algorithm Author: P. Levis, T. Clausen, J. Hui, O. Gnawali, J. Ko Status: Standards Track Stream: IETF Date: March 2011 Mailbox: pal@cs.stanford.edu, T.Clausen@computer.org, jhui@archrock.com, gnawali@cs.stanford.edu, jgko@cs.jhu.edu Pages: 13 Characters: 30283 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-roll-trickle-08.txt URL: http://www.rfc-editor.org/rfc/rfc6206.txt The Trickle algorithm allows nodes in a lossy shared medium (e.g., low-power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allow Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use. [STANDARDS-TRACK] This document is a product of the Routing Over Low power and Lossy networks Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From jpv@cisco.com Tue Mar 29 22:10:41 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B95A33A6AB0 for ; Tue, 29 Mar 2011 22:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.931 X-Spam-Level: X-Spam-Status: No, score=-109.931 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNStc9zvHKSe for ; Tue, 29 Mar 2011 22:10:36 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id DB0FC3A6AD4 for ; Tue, 29 Mar 2011 22:10:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=10708; q=dns/txt; s=iport; t=1301461927; x=1302671527; h=from:mime-version:subject:date:references:cc:to: message-id; bh=k4ZKAl82Fd2Rrc6SwOjHrBXerdIzozDtc8KEQrKpgyw=; b=jmMf/SKBFsk5I/vpvB+ctLw3kWsYJDZ+9hvLCOTQ6Z5WK34H/bdBOpnr lTymv0xmxqTNdOAWccCV0LfgUAxebcmzYvDjqpJBzJ1VwMX37gaMsoqv6 yWoHG+3C2ZkXtufkFc9bSmNFKIZZTU0o6YTu8eGD3WtPxy8Op0i7MbDW2 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvoEAOW6kk2Q/khMgWdsb2JhbACeWAGGeRQBARYmJYh5liqcW4VqBI0Fg1s X-IronPort-AV: E=Sophos;i="4.63,266,1299456000"; d="scan'208,217";a="81398598" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 30 Mar 2011 05:12:01 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2U5C1M3030600; Wed, 30 Mar 2011 05:12:01 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 07:12:01 +0200 Received: from dhcp-4639.meeting.ietf.org ([10.61.88.82]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 07:12:00 +0200 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-17-1032173164 Date: Wed, 30 Mar 2011 07:12:00 +0200 References: <20110329085434.693DBE0784@rfc-editor.org> To: ROLL WG Message-Id: X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 30 Mar 2011 05:12:00.0671 (UTC) FILETIME=[FFF272F0:01CBEE98] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18042.004 X-TM-AS-Result: No--34.968900-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: Adrian Farrel Subject: [Roll] Fwd: RFC 6206 on The Trickle Algorithm X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 05:10:41 -0000 --Apple-Mail-17-1032173164 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Congratulation to the editors, authors and the whole WG ! JP. Begin forwarded message: > From: rfc-editor@rfc-editor.org > Date: March 29, 2011 10:54:34 AM GMT+02:00 > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: roll@ietf.org, rfc-editor@rfc-editor.org > Subject: [Roll] RFC 6206 on The Trickle Algorithm >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 6206 >=20 > Title: The Trickle Algorithm=20 > Author: P. Levis, T. Clausen, > J. Hui, O. Gnawali, > J. Ko > Status: Standards Track > Stream: IETF > Date: March 2011 > Mailbox: pal@cs.stanford.edu,=20 > T.Clausen@computer.org,=20 > jhui@archrock.com, =20 > gnawali@cs.stanford.edu,=20 > jgko@cs.jhu.edu > Pages: 13 > Characters: 30283 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-roll-trickle-08.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc6206.txt >=20 > The Trickle algorithm allows nodes in a lossy shared medium (e.g., > low-power and lossy networks) to exchange information in a highly > robust, energy efficient, simple, and scalable manner. Dynamically > adjusting transmission windows allows Trickle to spread new > information on the scale of link-layer transmission times while > sending only a few messages per hour when information does not > change. A simple suppression mechanism and transmission point > selection allow Trickle's communication rate to scale logarithmically > with density. This document describes the Trickle algorithm and > considerations in its use. [STANDARDS-TRACK] >=20 > This document is a product of the Routing Over Low power and Lossy = networks Working Group of the IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see = http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-17-1032173164 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Date: March 29, 2011 10:54:34 AM = GMT+02:00
Subject: [Roll] RFC 6206 on The Trickle = Algorithm


A new Request for Comments is = now available in online RFC libraries.


=        RFC 6206

=        Title: =      The Trickle Algorithm
=        Author: =     P. Levis, T. Clausen,
=             &n= bsp;      J. Hui, O. Gnawali,
=             &n= bsp;      J. Ko
=        Status: =     Standards Track
=        Stream: =     IETF
=        Date: =       March 2011
=        Mailbox:    pal@cs.stanford.edu,
=             &n= bsp;      T.Clausen@computer.org,
=             &n= bsp;      jhui@archrock.com,  
=             &n= bsp;      gnawali@cs.stanford.edu, =
=             &n= bsp;      jgko@cs.jhu.edu
=        Pages: =      13
=        Characters: 30283
=        Updates/Obsoletes/SeeAlso: =   None

       I-D = Tag:    draft-ietf-roll-trickle-08.txt

=        URL: =        http://www.rfc-editor.o= rg/rfc/rfc6206.txt

The Trickle algorithm allows nodes in a = lossy shared medium (e.g.,
low-power and lossy networks) to exchange = information in a highly
robust, energy efficient, simple, and = scalable manner.  Dynamically
adjusting transmission windows = allows Trickle to spread new
information on the scale of link-layer = transmission times while
sending only a few messages per hour when = information does not
change.  A simple suppression mechanism and = transmission point
selection allow Trickle's communication rate to = scale logarithmically
with density.  This document describes the = Trickle algorithm and
considerations in its use. =  [STANDARDS-TRACK]

This document is a product of the Routing = Over Low power and Lossy networks Working Group of the IETF.

This = is now a Proposed Standard Protocol.

STANDARDS TRACK: This = document specifies an Internet standards track
protocol for the = Internet community,and requests discussion and suggestions
for = improvements.  Please refer to the current edition of the = Internet
Official Protocol Standards (STD 1) for the standardization = state and
status of this protocol.  Distribution of this memo is = unlimited.

This announcement is sent to the IETF-Announce and = rfc-dist lists.
To subscribe or unsubscribe, see
 http://www.iet= f.org/mailman/listinfo/ietf-announce
 http://ma= ilman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching = the RFC series, see http://www.rfc-editor.or= g/rfcsearch.html.
For downloading RFCs, see http://www.rfc-editor.org/rfc.= html.

Requests for special distribution should be addressed = to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org. =  Unless
specifically noted otherwise on the RFC itself, all RFCs = are for
unlimited distribution.


The RFC Editor = Team
Association Management Solutions, = LLC


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

= --Apple-Mail-17-1032173164-- From iesg-secretary@ietf.org Tue Mar 29 23:01:14 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 173B03A6A8C; Tue, 29 Mar 2011 23:01:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qlYIrgwru0s5; Tue, 29 Mar 2011 23:01:12 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 094E63A6B0A; Tue, 29 Mar 2011 23:01:12 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110330060112.21264.93784.idtracker@localhost> Date: Tue, 29 Mar 2011 23:01:12 -0700 Cc: roll mailing list , roll chair , RFC Editor Subject: [Roll] Protocol Action: 'RPL: IPv6 Routing Protocol for Low power and Lossy Networks' to Proposed Standard (draft-ietf-roll-rpl-19.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 06:01:14 -0000 The IESG has approved the following document: - 'RPL: IPv6 Routing Protocol for Low power and Lossy Networks' (draft-ietf-roll-rpl-19.txt) as a Proposed Standard This document is the product of the Routing Over Low power and Lossy networks Working Group. The IESG contact persons are Adrian Farrel and Stewart Bryant. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-roll-rpl/ Technical Summary Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnects are constrained: LLN routers typically operate with constraints on (any subset of) processing power, memory and energy (battery), and their interconnects are characterized by (any subset of) high loss rates, low data rates and instability. LLNs are comprised of anything from a few dozen and up to thousands of routers, and support point-to-point traffic (between devices inside the LLN), point-to-multipoint traffic (from a central control point to a subset of devices inside the LLN) and multipoint- to-point traffic (from devices inside the LLN towards a central control point). The latter is especially common, as it represents all forms for sensor data acquisition and meter reading. The document specifies the IPv6 Routing Protocol for LLNs (RPL), which provides a mechanism whereby multipoint-to-point traffic from devices inside the LLN towards a central control point, as well as point-to- multipoint traffic from the central control point to the devices inside the LLN, is supported. Support for point-to-point traffic is also available. RPL was designed with the objective to meet the requirements spelled out in [RFC5867], [RFC5826], [RFC5673], and [RFC5548]. Working Group Summary Considering that there were a number of discussed items, several decisions had to be made that required WG consensus. All decisions were driven by good/excellent consensus. Very few decisions were made with only a rough consensus (extensions to carry MTU, SLLA options or support of siblings). That being said, the document has been written so as to allow for future extensions including the ones listed above, which was seen an acceptable approach. Considerable amounts of WG time were spent discussing the IPR claims associated with this document and there is WG consensus to proceed with the -11 version of this document considering the modifications made to the document since the IPR disclosures were filed and considering the license terms published. Document Quality Good. During the course of the design of this document, a number of implementations have been reported (more than 10) and two interoperability events took place under the control of the IPSO (IP for Smart Object) alliance and the Zigbee alliance. Interoperability results were shared on the ROLL WG mailing list, concerns have been addressed and all issues known so far have been fixed. Personnel David Culler (culler@eecs.berkeley.edu) is the Document Shepherd. Adrian Farrel (adrian.farrel@huawei.com) is the Responsible AD. RFC Editor Note Section 9.4 *Second* bullet list. Bullet 2 OLD If the 'L' flag is cleared, indicating a subnet operation, and the 'R' flag is set, indicating that the parent provides its own address in the PIO, then the parent MUST advertise that address as a DAO target. NEW If the 'L' flag is cleared and the 'R' flag is set, indicating that the parent provides its own address in the PIO, then the parent MUST advertise that address as a DAO target. END --- Section 6.7.10 New final paragraph in the section NEW If the only desired effect of a received PIO in a DIO is to provide the global address of the parent node to the receiving node then the sender resets the 'A' and 'L' bits and sets the 'R' bit. Upon receipt, the RPL will not autoconfigure an address or a connected route from the prefix [RFC4862]. As in all cases, when the 'L' bit is not set, the RPL node MAY include the prefix in PIOs it sends to its children. END --- Section 12, paragraph 1 OLD This section describes further a multicast routing operation over an IPv6 RPL network, and specifically how unicast DAOs can be used to relay group registrations up. The same DODAG construct can used to forward unicast and multicast traffic. The registration uses DAO messages that are identical to unicast except for the type of address that is transported. The main difference is that the multicast traffic going down is copied to all the children that have registered to the multicast group whereas unicast traffic is passed to one child only. NEW This section describes a multicast routing operation over an IPv6 RPL network, and specifically how unicast DAOs can be used to relay group registrations. The same DODAG construct can used to forward unicast and multicast traffic. This section is limited to a description of how group registrations may be exchanged and how the forwarding infrastructure operates. It does not provide a full description of multicast with in an LLN and, in particular, does not describe the generation of DODAGs specifically targeted at multicast nor the details of operating RPL for multicast - that will be the subject of further specifications. The multicast group registration uses DAO messages that are identical to unicast except for the type of address that is transported. The main difference is that the multicast traffic going down is copied to all the children that have registered to the multicast group whereas unicast traffic is passed to one child only. END From Internet-Drafts@ietf.org Tue Mar 29 23:15:06 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D0F23A6AD5; Tue, 29 Mar 2011 23:15:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.58 X-Spam-Level: X-Spam-Status: No, score=-102.58 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B15pQmhxHT5A; Tue, 29 Mar 2011 23:15:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCD633A67F8; Tue, 29 Mar 2011 23:15:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110330061501.26984.42612.idtracker@localhost> Date: Tue, 29 Mar 2011 23:15:01 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-of0-08.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 06:15:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : RPL Objective Function 0 Author(s) : P. Thubert Filename : draft-ietf-roll-of0-08.txt Pages : 17 Date : 2011-03-29 The Routing Protocol for Low Power and Lossy Networks defines a generic Distance Vector protocol for Low Power and Lossy Networks. That generic protocol requires a specific Objective Function to establish a desired routing topology. This specification defines a basic Objective Function that operates solely with the protocol elements defined in the generic protocol specification.Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-of0-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-of0-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-29230817.I-D@ietf.org> --NextPart-- From jpv@cisco.com Wed Mar 30 03:05:50 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8B7AF28C0E2 for ; Wed, 30 Mar 2011 03:05:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.237 X-Spam-Level: X-Spam-Status: No, score=-110.237 tagged_above=-999 required=5 tests=[AWL=0.362, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lyp+k4UNtP9q for ; Wed, 30 Mar 2011 03:05:49 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 5D74D3A68AB for ; Wed, 30 Mar 2011 03:05:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=134; q=dns/txt; s=iport; t=1301479648; x=1302689248; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=PW1E2XX1SOkKVQxIFg73rn4T1GEg5SyUnkTD3JO9SoA=; b=hdgp/XD3XyKLETubPlwL0RFhBxiuTKleCR418qrZ1C3UL37WovCZpwR/ +1D6PRhsAJy3VJ6TyZq1fYySdnoOuKGdGPKcWZa2G5geA8xP7La0toOQC pMJoqmz7a5Z5DpLo3kdzBQ5cfHUEjbUkhM3VK1+sIlXrOwP1wUl3458S0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvgDAG8Ak02Q/khLgWdsb2JhbAClTRQBARYmJYhymE6cUYVqBI0Gg1s X-IronPort-AV: E=Sophos;i="4.63,267,1299456000"; d="scan'208";a="23771020" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 30 Mar 2011 10:07:27 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2UA7RtU026854 for ; Wed, 30 Mar 2011 10:07:27 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 12:07:27 +0200 Received: from dhcp-1263.meeting.ietf.org ([10.61.102.84]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 30 Mar 2011 12:07:27 +0200 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Mar 2011 12:07:25 +0200 Message-Id: To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 30 Mar 2011 10:07:27.0315 (UTC) FILETIME=[45D9AA30:01CBEEC2] Subject: [Roll] Slides please X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 10:05:50 -0000 Dear all, Thanks to send us your slides if you have a slot tomorrow in our = meeting, many are missing. Many Thanks ! JP.= From rstruik.ext@gmail.com Wed Mar 30 08:07:04 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A095C3A6B28 for ; Wed, 30 Mar 2011 08:07:04 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id COO3x7RhR4KR for ; Wed, 30 Mar 2011 08:07:02 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 3BB833A6847 for ; Wed, 30 Mar 2011 08:07:02 -0700 (PDT) Received: by gwb20 with SMTP id 20so622567gwb.31 for ; Wed, 30 Mar 2011 08:08:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:x-enigmail-version:content-type; bh=LpqE1eDrRbF8q0nQdjtr3sA19ITwkq/lpMIyaLXYV70=; b=vjcFhTEy93MeFX2S3JceVHCbJKrR5p9hpFJOGdqZM0OtROeeV82bhawteD0g518YoS PHQUpZjKnFfn1d1kl1J13+vB6mtftLZAorCAN4NLsSAwvONaoVT3bjRm9HKClPyronDw i0jZyHvDm1065dZb8DVAXEa3C80GZG0aXMiOM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type; b=h6RY44x1wCE4ApOCXfEO+L7JjYwyftmhNg3il8yX49dnriGbWgbxBBTLr/k8WHp+HO mDPbF8lr41UKofQDcc3pMYAMInPlnqdQxX/471wkfcskxsAWP60bLPrOoF97EOATCfL5 mxP688iLmVOBsfW0dE7z1N//aIo4+nTBw0Qo4= Received: by 10.150.251.21 with SMTP id y21mr1763369ybh.273.1301497720841; Wed, 30 Mar 2011 08:08:40 -0700 (PDT) Received: from [192.168.1.103] (CPE0013100e2c51-CM00186851d6f6.cpe.net.cable.rogers.com [99.231.117.243]) by mx.google.com with ESMTPS id 51sm80031yhl.40.2011.03.30.08.08.38 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 30 Mar 2011 08:08:39 -0700 (PDT) Message-ID: <4D93476F.8030204@gmail.com> Date: Wed, 30 Mar 2011 11:08:31 -0400 From: Rene Struik User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9 MIME-Version: 1.0 To: QIU Ying , roll@ietf.org X-Enigmail-Version: 1.1.1 Content-Type: multipart/alternative; boundary="------------070901010802020703010900" Subject: [Roll] some brief comments on draft-qiu-roll-kemp-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 15:07:04 -0000 This is a multi-part message in MIME format. --------------070901010802020703010900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Qiu: Please find below some initial comments on your draft-qiu-roll-kemp-00. I hope you have a good discussion at the roll meeting at IETF-80. Best regards, Rene == [initial comments on draft-qiu-roll-kemp-00] Section 3: This section referesto a probabilistic key pre-distribution scheme based on secret keys. a) Obviously, there are trade-offs between size of the key set and probability that one is able to establish a shared key. It would be helpful to have some insight in the number of keys that need to be stored so that a shared key can be derived (e.g., with network of size 100, 1000, 10000). b) It would be good to have some insight into how compromise of a few nodes may impact the security of key establishment with two non-compromised nodes. Section 4.1: This section describes a basic protocol where a base station B acts as inline CA and assists a sensor node N and router R in establishing a session key. a) The protocol assumes that each sensor, router shares a secret key with the base station. Thus, one seems to consider a single trust domain. What about the scenario where on has multiple trust domains (e.g., when one procures sensors from different vendors)? b) How does the sensor N know which base station B to talk to? c) The base station B checks revocation of sensor node N. It seems useful to also check revocation of router R and arbitrage on whether secure and authentic channel between node {N,R} should be established. d) The message appv needs to be authenticated, since otherwise any incoming message may trigger a key update with router R. e) What prevents an adversary from replaying past (sensor node, request) pairs and triggering traffic flows and key updates with routers this way? f) The protocol does not provide for key confirmation, so state changes on the router (triggered key update K_NR with purported sensor node N) may not be temporary, but may linger for quite a while. This, in conjunction with potential replay attacks, may trigger consumption of keying material related storage. g) The protocol's communication pattern is circular (sensor - base station - router - sensor). Given the sleepy nature of networks and desire to minimize having to keep status information, having the communication flow between two nodes (sensor - base station) may be preferred. This could then be followed by communication flow between two nodes (sensor - router) based on successful completion of first transaction. In other words, this corresponds with inline CA (base station) interacting with one node (sensor) only, whereafter sensor interacts with router based on distributed keying material by CA. This may also minimize necessity to propagate state and prevent replay scenarios. General remarks: a) It may be useful to analyze the proper working of the protocol if the underlying single-hop communications would be secured (e.g., using 802.15.4-2006 security with a network-wide key), so as to have potential restrictions surfacing. b) It seems that use of public-key based techniques may aleviate some of the restrictions w.r.t. single trust domain and initial set-up. Anno 2011, implementation cost (code size, communication overhead, computational latency, and energy consumption) does not seem to be a roadblock for considering this for all but most mundane devices. == -------- Original Message -------- Subject: RE: [Roll] FW: New Version Notification fordraft-qiu-6lowpan-secure-router-01 Date: Thu, 28 Oct 2010 19:46:15 +0800 From: QIU Ying To: 'Childress, Steve' , 'Rene Struik' CC: , <6lowpan@ietf.org>, "'Zhou Jianying'" , "'Bao Feng'" Hi, Rene and Steve Thanks for your comments. First of all, one thing needs to clarify: each node shares a secret key with its neighbour as well as the base station, respectively. You are right that the current version does not describe the issue of multiple trust domains. If these multiple domains are managed by one base station (key centre), the proposed protocol can simplify be employed on this scenario. If these multiple domains have their own base station, there are 2 sub-scenarios: 1) if the sensor node know its destination base station, the current protocol can be use without any change, but extend the node's cache table to store the secret between node and these base stations. 2) if the sensor node cannot decide which base station is its destination, we need to modify the req message. One possible solution could let the req message carry a catenation of all of MACs with generated by the secret between the node and the basestaion, respectively. But I do not think it is a good solution because the req message would be longer and cost much more transit energy. Since the node has different keys with its neighbours respectively, one compromised router would not affect the entire system but its neighbour nodes. In the section 5, we briefed the security analysis. In fact, the protocol is similar with the well-known Kerberos protocol. Our protocol tries to reduce the handshake messages. Steve, could you please provide more information on your project? Regards and Thanks Qiu Ying > -----Original Message----- > From: Childress, Steve [mailto:STEVE.CHILDRESS@saic.com] > Sent: Thursday, October 28, 2010 4:12 AM > To: Rene Struik; QIU Ying > Cc: roll@ietf.org; 6lowpan@ietf.org > Subject: RE: [Roll] FW: New Version Notification fordraft-qiu-6lowpan- > secure-router-01 > > On: "What about the scenario where one has multiple trust domains (e.g., > when one procures sensors from > different vendors)?" > > This is the nature of our current project and implementation, using > 802.15.4 sans full NWK layer. > > Steve Childress > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Rene Struik > Sent: Wednesday, October 27, 2010 6:18 AM > To: QIU Ying > Cc: roll@ietf.org; 6lowpan@ietf.org > Subject: Re: [Roll] FW: New Version Notification > fordraft-qiu-6lowpan-secure-router-01 > > Hi Qiu: > > Thanks for your draft. > > Your draft seems to suggest a single trust domain, where each node > shares a secret key with the base station. What about the scenario where > > one has multiple trust domains (e.g., when one procures sensors from > different vendors)? Doesn't the security fall apart if a router gets > compromised? What prevents an adversary from replaying past (sensor > node, request) pairs and triggering traffic flows and key updates with > routers this way? > > Do you have a paper that provides a more formal analysis of the security > > properties provided by the protocol you suggest? > > Best regards, Rene > > On 27/10/2010 6:22 AM, QIU Ying wrote: > > http://tools.ietf.org/id/draft-qiu-6lowpan-secure-router-01.txt > > > > The title of the draft had been changed to "Lightweight Key > Establishment and Management Protocol in Dynamic Sensor Networks (KEMP)" > instead of "Lightweight Secure Router Protocol" in order to make the > work more clearly. It will be presented at ROLL WG. > > > > > Any comments are appreciated. > > > > Regards > > QIU Ying -- email: rstruik.ext@gmail.com Skype: rstruik cell: +1 (647) 867-5658 USA Google voice: +1 (415) 690-7363 --------------070901010802020703010900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear Qiu:

Please find below some initial comments on your draft-qiu-roll-kemp-00.

I hope you have a good discussion at the roll meeting at IETF-80.

Best regards, Rene

==

[initial comments  on draft-qiu-roll-kemp-00]

Section 3:
This section referesto a probabilistic key pre-distribution scheme based on secret keys.
a) Obviously, there are trade-offs between size of the key set and probability that one is able to establish a shared key. It would be helpful to have some insight in the number of keys that need to be stored so that a shared key can be derived (e.g., with network of size 100, 1000, 10000).
b) It would be good to have some insight into how compromise of a few nodes may impact the security of key establishment with two non-compromised nodes.

Section 4.1:
This section describes a basic protocol where a base station B acts as inline CA and assists a sensor node N and router R in establishing a session key.
a) The protocol assumes that each sensor, router shares a secret key with the base station. Thus, one seems to consider a single trust domain. What about the scenario where on has multiple trust domains (e.g., when one procures sensors from different vendors)?
b) How does the sensor N know which base station B to talk to?
c) The base station B checks revocation of sensor node N. It seems useful to also check revocation of router R and arbitrage on whether secure and authentic channel between node {N,R} should be established.
d) The message appv needs to be authenticated, since otherwise any incoming message may trigger a key update with router R.
e) What prevents an adversary from replaying past (sensor node, request) pairs and triggering traffic flows and key updates with routers this way?
f) The protocol does not provide for key confirmation, so state changes on the router (triggered key update K_NR with purported sensor node N) may not be temporary, but may linger for quite a while. This, in conjunction with potential replay attacks, may trigger consumption of keying material related storage.
g) The protocol's communication pattern is circular (sensor - base station - router - sensor). Given the sleepy nature of networks and desire to minimize having to keep status information, having the communication flow between two nodes (sensor - base station) may be preferred. This could then be followed by communication flow between two nodes (sensor - router) based on successful completion of first transaction. In other words, this corresponds with inline CA (base station) interacting with one node (sensor) only, whereafter sensor interacts with router based on distributed keying material by CA. This may also minimize necessity to propagate state and prevent replay scenarios.

General remarks:
a) It may be useful to analyze the proper working of the protocol if the underlying single-hop communications would be secured (e.g., using 802.15.4-2006 security with a network-wide key), so as to have potential restrictions surfacing.
b) It seems that use of public-key based techniques may aleviate some of the restrictions w.r.t. single trust domain and initial set-up. Anno 2011, implementation cost (code size, communication overhead, computational latency, and energy consumption) does not seem to be a roadblock for considering this for all but most mundane devices.

==

-------- Original Message --------
Subject: RE: [Roll] FW: New Version Notification fordraft-qiu-6lowpan-secure-router-01
Date: Thu, 28 Oct 2010 19:46:15 +0800
From: QIU Ying <qiuying@i2r.a-star.edu.sg>
To: 'Childress, Steve' <STEVE.CHILDRESS@saic.com>, 'Rene Struik' <rstruik.ext@gmail.com>
CC: <roll@ietf.org>, <6lowpan@ietf.org>, "'Zhou Jianying'" <jyzhou@i2r.a-star.edu.sg>, "'Bao Feng'" <baofeng@i2r.a-star.edu.sg> 


Hi, Rene and Steve

Thanks for your comments.

First of all, one thing needs to clarify: each node shares a secret key with
its neighbour as well as the base station, respectively.

You are right that the current version does not describe the issue of
multiple trust domains.

If these multiple domains are managed by one base station (key centre), the
proposed protocol can simplify be employed on this scenario.
 
If these multiple domains have their own base station, there are 2
sub-scenarios:
1) if the sensor node know its destination base station, the current
protocol can be use without any change, but extend the node's cache table to
store the secret between node and these base stations.
2) if the sensor node cannot decide which base station is its destination,
we need to modify the req message. One possible solution could let the req
message carry a catenation of all of MACs with generated by the secret
between the node and the basestaion, respectively. But I do not think it is
a good solution because the req message would be longer and cost much more
transit energy.    

Since the node has different keys with its neighbours respectively, one
compromised router would not affect the entire system but its neighbour
nodes.

In the section 5, we briefed the security analysis. In fact, the protocol is
similar with the well-known Kerberos protocol. Our protocol tries to reduce
the handshake messages.
  

Steve, could you please provide more information on your project?

Regards and Thanks
Qiu Ying


> -----Original Message-----
> From: Childress, Steve [mailto:STEVE.CHILDRESS@saic.com]
> Sent: Thursday, October 28, 2010 4:12 AM
> To: Rene Struik; QIU Ying
> Cc: roll@ietf.org; 6lowpan@ietf.org
> Subject: RE: [Roll] FW: New Version Notification fordraft-qiu-6lowpan-
> secure-router-01
> 
> On: "What about the scenario where one has multiple trust domains (e.g.,
> when one procures sensors from
> different vendors)?"
> 
> This is the nature of our current project and implementation, using
> 802.15.4 sans full NWK layer.
> 
> Steve Childress
> 
> 
> -----Original Message-----
> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of
> Rene Struik
> Sent: Wednesday, October 27, 2010 6:18 AM
> To: QIU Ying
> Cc: roll@ietf.org; 6lowpan@ietf.org
> Subject: Re: [Roll] FW: New Version Notification
> fordraft-qiu-6lowpan-secure-router-01
> 
> Hi Qiu:
> 
> Thanks for your draft.
> 
> Your draft seems to suggest a single trust domain, where each node
> shares a secret key with the base station. What about the scenario where
> 
> one has multiple trust domains (e.g., when one procures sensors from
> different vendors)? Doesn't the security fall apart if a router gets
> compromised? What prevents an adversary from replaying past (sensor
> node, request) pairs and triggering traffic flows and key updates with
> routers this way?
> 
> Do you have a paper that provides a more formal analysis of the security
> 
> properties provided by the protocol you suggest?
> 
> Best regards, Rene
> 
> On 27/10/2010 6:22 AM, QIU Ying wrote:
> > http://tools.ietf.org/id/draft-qiu-6lowpan-secure-router-01.txt
> >
> > The title of the draft had been changed to "Lightweight Key
> Establishment and Management Protocol in Dynamic Sensor Networks (KEMP)"
> instead of "Lightweight Secure Router Protocol" in order to make the
> work more clearly. It will be presented at ROLL WG.
> 
> >
> > Any comments are appreciated.
> >
> > Regards
> > QIU Ying
-- 
email: rstruik.ext@gmail.com
Skype: rstruik
cell: +1 (647) 867-5658
USA Google voice: +1 (415) 690-7363
--------------070901010802020703010900-- From jpv@cisco.com Thu Mar 31 02:03:59 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C696728C188 for ; Thu, 31 Mar 2011 02:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.529 X-Spam-Level: X-Spam-Status: No, score=-110.529 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByoxVPtYtbUc for ; Thu, 31 Mar 2011 02:03:59 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id DB67028C10F for ; Thu, 31 Mar 2011 02:03:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=2; q=dns/txt; s=iport; t=1301562338; x=1302771938; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=frcCV1k9oG9oKj3dpUqdJg1PxRT2RSN/XKdLCPjaYaY=; b=MQxY5XUE+qrhtG0fL9AxQChnTWjMVa1+/0Z7jirGiN53ljf65iCVYMUF dmJGTTXe1NYN95hVDexcGL4bANuUMShopd6Hti9xLUOCKIiNO9VrAm+wJ XLG3ApixBK5sT5m8qkRavXtx6kDMumBY++BnOvAYZLp3W2mH8rE1CQKj/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAJFDlE2rRDoH/2dsb2JhbACHBJ5Ld4hymVqcB4VrBI0Rg1s X-IronPort-AV: E=Sophos;i="4.63,274,1299456000"; d="scan'208";a="286381017" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 31 Mar 2011 09:05:38 +0000 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p2V95Tpv023808 for ; Thu, 31 Mar 2011 09:05:37 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, 31 Mar 2011 17:05:28 +0800 Received: from dhcp-1263.meeting.ietf.org ([10.61.102.187]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 17:05:27 +0800 From: JP Vasseur Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 31 Mar 2011 11:05:26 +0200 Message-Id: <31C5813F-62CE-4510-B7B2-6FD720029A8C@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 31 Mar 2011 09:05:28.0246 (UTC) FILETIME=[C7868560:01CBEF82] Subject: [Roll] Still slides missing ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 09:03:59 -0000 From taurus.wf@gmail.com Thu Mar 31 05:59:27 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC51B3A6B13 for ; Thu, 31 Mar 2011 05:59:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 64KajDslOU8T for ; Thu, 31 Mar 2011 05:59:27 -0700 (PDT) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 0CBA33A6B12 for ; Thu, 31 Mar 2011 05:59:26 -0700 (PDT) Received: by ywi6 with SMTP id 6so1080482ywi.31 for ; Thu, 31 Mar 2011 06:01:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=CUQ/KrUlGHKmRteVIIiJW7zePpqpVIpuXAPMRBGX3co=; b=X8XhxRGMijf616B5QOX3gJaLqXPkBTDdSpIpUjzQTbd1quUKoQScOYxOJ2qnviMULC p4NYAM3ZcTeh2jlPgmcILk6FY5yTSMDGUGZ9NA5ABMTPh7tXO8JA+Zdc9X2vOgScMEfQ QqpgwjRbVz0kBvBvgLyrKN/qTxi7c0D70bl5w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=OzGsYnaVczrQQW57acfSyuTBQzDMLMAk+2F04ecDQieaMtOhnssbcin5apZV5L5mcv hDXX4KtUEwzWf6Kdu1lx8B6y3nFhq2Y2Bvsit22diztBzcixtl9Fcr1IAhebmw8UtWIB r19H/NACBE6JXy3GTkJ1yJEcTQPGNnCFVR0C4= MIME-Version: 1.0 Received: by 10.236.182.230 with SMTP id o66mr216923yhm.24.1301576466457; Thu, 31 Mar 2011 06:01:06 -0700 (PDT) Received: by 10.236.105.241 with HTTP; Thu, 31 Mar 2011 06:01:06 -0700 (PDT) Date: Thu, 31 Mar 2011 15:01:06 +0200 Message-ID: From: feng wang To: roll@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: [Roll] Propose to modify LLN in draft-ietf-roll-terminology-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 12:59:28 -0000 hi all, Here I have a suggestion to synchronize the terminology of LLN with ROLL Charter. As what has been described in current ROLL WG Charter: =93Low power and Lossy networks (LLNs) are made up of many embedded devices with limited power, memory, and processing resources. They are interconnected by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, wired or other low power PLC (Powerline Communication) links. =94 However, In the ongoing terminology draft, draft-ietf-roll-terminology-05, it only says that: =93Low power and Lossy networks (LLNs) are typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links, such as IEEE 802.15.4, Low Power WiFi.=94 Bluetooth is missed here. As we know in new Bluetooth 4.0, which also includes of low energy use cases as BTLE. And a new I-D draft about IPv6 over BTLE also starting in 6LoWPAN WG. So here I propose to modify LLN terminology in the terminology-05 draft, to add Bluetooth in. Thanks, -- Wang Feng. Shawn From abr@sdesigns.dk Thu Mar 31 06:35:32 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2299A3A6B3D for ; Thu, 31 Mar 2011 06:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=-0.512, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T-n5C0lepvrQ for ; Thu, 31 Mar 2011 06:35:31 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 2A2753A6B13 for ; Thu, 31 Mar 2011 06:35:30 -0700 (PDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBEFA8.BC00ED37" Date: Thu, 31 Mar 2011 15:32:46 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01AD48B7@zensys17.zensys.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re-announcement: RPL Applicability Statement for home & building Thread-Index: AcvumRJbgihzKKB3Rz+/9wq74CIYeQBDwzPh References: <20110329085434.693DBE0784@rfc-editor.org> From: "Anders Brandt" To: "ROLL WG" Subject: [Roll] Re-announcement: RPL Applicability Statement for home & building X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 13:35:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CBEFA8.BC00ED37 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As requested during the ROLL WG Meeting: http://tools.ietf.org/html/draft-brandt-roll-rpl-applicability-home-build= ing-01 This document was the starting point for the RPL P2P design team for addressing the requirements of building and home control domains. =20 Thanks, Anders ------_=_NextPart_001_01CBEFA8.BC00ED37 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=

As requested during the ROLL WG Meeting:

=0A=

http://tools.ietf.org/html/draft-brandt-roll-rpl-applicab= ility-home-building-01

=0A=

This document was the starting point for the RPL P2P design = team
for addressing the requirements of building and home control = domains.

=0A=

 

=0A=

Thanks,
  Anders

------_=_NextPart_001_01CBEFA8.BC00ED37-- From ulrich@herberg.name Thu Mar 31 06:39:51 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E27183A6AB2 for ; Thu, 31 Mar 2011 06:39:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.226 X-Spam-Level: X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[AWL=0.750, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FSYx0qBz7uJ for ; Thu, 31 Mar 2011 06:39:50 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id ABD743A69A3 for ; Thu, 31 Mar 2011 06:39:50 -0700 (PDT) Received: by vws12 with SMTP id 12so2159736vws.31 for ; Thu, 31 Mar 2011 06:41:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=OzU663clchmYBIx2dagyf/3c6nzPWHZ4FFrl53EjUe8=; b=FssPzFTOPzahyUzpEhxiHt4TNZ9ScCWrDJqKncxqiG8M2y3S8DWhDOT2waOwhrRAcy qkxkvp+6+kAbPtkdqfYmhiOL6DfU+mJHI667xXQdY1nQglRhjwOLMeV5MF8pBZs2fpV/ 66qPcC1HZHxh2TW6upkPQO5N+qgMiGd2TEiRo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=JQ/B3PDasLpb2zGQlViKSB4uo2e8Nc9AXif0H23ab56YsLswcvqK6jbWHPjZf13glq 33CPIOKZ8uh4WRZfcBd6oF/LoJErh9alYbac+yI8jfM8/vSMardkQuQIsYD7JXiQkQO7 g5ugKQkXvHnO/4sIM1dkUz5G5cW2cuU9zcdSE= MIME-Version: 1.0 Received: by 10.220.180.12 with SMTP id bs12mr737231vcb.63.1301578889652; Thu, 31 Mar 2011 06:41:29 -0700 (PDT) Received: by 10.220.71.142 with HTTP; Thu, 31 Mar 2011 06:41:29 -0700 (PDT) In-Reply-To: <31C5813F-62CE-4510-B7B2-6FD720029A8C@cisco.com> References: <31C5813F-62CE-4510-B7B2-6FD720029A8C@cisco.com> Date: Thu, 31 Mar 2011 15:41:29 +0200 Message-ID: From: Ulrich Herberg To: JP Vasseur Content-Type: multipart/alternative; boundary=90e6ba4fc29e5d6c6c049fc7734d Cc: ROLL WG Subject: Re: [Roll] Still slides missing ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 13:39:52 -0000 --90e6ba4fc29e5d6c6c049fc7734d Content-Type: text/plain; charset=ISO-8859-1 Unfortunately, several slide sets have not been uploaded. I would like to access them, since I participate remotely. Ulrich On Thu, Mar 31, 2011 at 11:05 AM, JP Vasseur wrote: > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --90e6ba4fc29e5d6c6c049fc7734d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Unfortunately, several slide sets have not been uploaded. I would like to a= ccess them, since I participate remotely.

Ulrich

On Thu, Mar 31, 2011 at 11:05 AM, = JP Vasseur <jpv@cisco= .com> wrote:

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

--90e6ba4fc29e5d6c6c049fc7734d-- From prvs=0641fba07=mukul@uwm.edu Thu Mar 31 06:46:58 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 07E993A6B10 for ; Thu, 31 Mar 2011 06:46:58 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpMSVpeOpsAy for ; Thu, 31 Mar 2011 06:46:57 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 347973A6AEA for ; Thu, 31 Mar 2011 06:46:57 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 31 Mar 2011 08:48:36 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 8354E2B3EF7; Thu, 31 Mar 2011 08:45:44 -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 Vni+w+dVhT6T; Thu, 31 Mar 2011 08:45:44 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 341552B3EF3; Thu, 31 Mar 2011 08:45:44 -0500 (CDT) Date: Thu, 31 Mar 2011 08:48:36 -0500 (CDT) From: Mukul Goyal To: Ulrich Herberg Message-ID: <309674622.21858.1301579316173.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.9_GA_2686 (ZimbraWebClient - IE8 (Win)/6.0.9_GA_2686) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG Subject: Re: [Roll] Still slides missing ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 13:46:58 -0000 The slides for draft-goyal-roll-p2p-measurement draft-goyal-roll-defunct-dags draft-goyal-roll-metrics-direction are available at http://www.ietf.org/proceedings/80/slides/roll-5.pdf Thanks Mukul ----- Original Message ----- From: "Ulrich Herberg" To: "JP Vasseur" Cc: "ROLL WG" Sent: Thursday, March 31, 2011 8:41:29 AM Subject: Re: [Roll] Still slides missing ... Unfortunately, several slide sets have not been uploaded. I would like to access them, since I participate remotely. Ulrich On Thu, Mar 31, 2011 at 11:05 AM, JP Vasseur < jpv@cisco.com > wrote: _______________________________________________ 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 ulrich@herberg.name Thu Mar 31 06:47:19 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710953A6AEA for ; Thu, 31 Mar 2011 06:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.562, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VaKSvImAZoUc for ; Thu, 31 Mar 2011 06:47:18 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 70EBF3A6B10 for ; Thu, 31 Mar 2011 06:47:18 -0700 (PDT) Received: by vws12 with SMTP id 12so2167524vws.31 for ; Thu, 31 Mar 2011 06:48:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tNMCJu4jNo4okh35vJCRTrN72xk1PvnVYCQ0JTwV8Rc=; b=RVm6D+gRFOGgBx2Hd7EPjMWeMZoMn+KKxM0P/FUpvrflDzRbS/PgKD/m8hYpqwaPYg q9G3iSxSwWcB95RE/FaFvtaMC2I5Z5Pq4ZpMwMGrXe2cKL1nHN9nyBh+sLSk0H2n0Fad 3BeqoZ9ny5c0eb5NQFSGuBDGarX+cRPPiFq2c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AY9ugCav90mikwuSvYwQ5HB3E8pgJhixf37kwwIq0+JYGYt+LjLF8f7PY+K5p7pLdA aNjaN9oMukZwZjWimbctCFDCgYXU9icv4qcUByXo74Shqonl0ghgmhRgJ0rXRefhkGXc cvj6fjFG440n1I9sH0S5uxb/sFdhtRxvU8G6o= MIME-Version: 1.0 Received: by 10.220.98.77 with SMTP id p13mr717745vcn.98.1301579337746; Thu, 31 Mar 2011 06:48:57 -0700 (PDT) Received: by 10.220.71.142 with HTTP; Thu, 31 Mar 2011 06:48:57 -0700 (PDT) In-Reply-To: References: <31C5813F-62CE-4510-B7B2-6FD720029A8C@cisco.com> Date: Thu, 31 Mar 2011 15:48:57 +0200 Message-ID: From: Ulrich Herberg To: JP Vasseur Content-Type: multipart/alternative; boundary=0016e645aab412cab9049fc78ebb Cc: ROLL WG Subject: Re: [Roll] Still slides missing ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 13:47:19 -0000 --0016e645aab412cab9049fc78ebb Content-Type: text/plain; charset=ISO-8859-1 Okay, they are just mixed up! :-) Got it Thanks! On Thu, Mar 31, 2011 at 3:41 PM, Ulrich Herberg wrote: > Unfortunately, several slide sets have not been uploaded. I would like to > access them, since I participate remotely. > > Ulrich > > > On Thu, Mar 31, 2011 at 11:05 AM, JP Vasseur wrote: > >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > > --0016e645aab412cab9049fc78ebb Content-Type: text/html; charset=ISO-8859-1 Okay, they are just mixed up! :-) Got it

Thanks!

On Thu, Mar 31, 2011 at 3:41 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
Unfortunately, several slide sets have not been uploaded. I would like to access them, since I participate remotely.

Ulrich


On Thu, Mar 31, 2011 at 11:05 AM, JP Vasseur <jpv@cisco.com> wrote:

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


--0016e645aab412cab9049fc78ebb-- From c.chauvenet@watteco.com Thu Mar 31 08:20:09 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C54BD3A6BBF for ; Thu, 31 Mar 2011 08:20:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.42 X-Spam-Level: X-Spam-Status: No, score=-5.42 tagged_above=-999 required=5 tests=[AWL=1.179, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uxVYY84rQiVi for ; Thu, 31 Mar 2011 08:20:08 -0700 (PDT) Received: from TX2EHSOBE002.bigfish.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by core3.amsl.com (Postfix) with ESMTP id EB8593A6B0E for ; Thu, 31 Mar 2011 08:20:07 -0700 (PDT) Received: from mail101-tx2-R.bigfish.com (10.9.14.254) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.8; Thu, 31 Mar 2011 15:21:47 +0000 Received: from mail101-tx2 (localhost.localdomain [127.0.0.1]) by mail101-tx2-R.bigfish.com (Postfix) with ESMTP id CECEA1650568; Thu, 31 Mar 2011 15:21:46 +0000 (UTC) X-SpamScore: -84 X-BigFish: VPS-84(zzbb2cK15caKJ14ffO4015Lzz1202hzz1033IL8275dhz2dh2a8h668h61h) X-Spam-TCS-SCL: 0:0 X-Forefront-Antispam-Report: KIP:(null); UIP:(null); IPVD:NLI; H:IE2RD2HUB010.red002.local; RD:none; EFVD:NLI Received: from mail101-tx2 (localhost.localdomain [127.0.0.1]) by mail101-tx2 (MessageSwitch) id 130158490693722_2812; Thu, 31 Mar 2011 15:21:46 +0000 (UTC) Received: from TX2EHSMHS031.bigfish.com (unknown [10.9.14.253]) by mail101-tx2.bigfish.com (Postfix) with ESMTP id 10EE215B005A; Thu, 31 Mar 2011 15:21:46 +0000 (UTC) Received: from IE2RD2HUB010.red002.local (213.199.187.153) by TX2EHSMHS031.bigfish.com (10.9.99.131) with Microsoft SMTP Server (TLS) id 14.1.225.8; Thu, 31 Mar 2011 15:21:40 +0000 Received: from IE2RD2XVS211.red002.local ([172.18.6.54]) by IE2RD2HUB010.red002.local ([10.33.16.249]) with mapi; Thu, 31 Mar 2011 08:21:36 -0700 From: C Chauvenet To: feng wang , "roll@ietf.org" Date: Thu, 31 Mar 2011 08:21:44 -0700 Thread-Topic: [Roll] Propose to modify LLN in draft-ietf-roll-terminology-05 Thread-Index: Acvvo7r/gBqHs0UdTDmtLKpTHLy0PwAEuU/g Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Subject: Re: [Roll] Propose to modify LLN in draft-ietf-roll-terminology-05 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 15:20:09 -0000 Hi,=20 The "such as" in the terminology draft let the door open to others like tho= se mentioned in the charter. I don't think we need to explicitly mention every applicable technology in = this doc or we will need to refresh it every time technology steps forward.= .. Best, C=E9dric. -----Message d'origine----- De=A0: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de f= eng wang Envoy=E9=A0: jeudi 31 mars 2011 15:01 =C0=A0: roll@ietf.org Objet=A0: [Roll] Propose to modify LLN in draft-ietf-roll-terminology-05 hi all, Here I have a suggestion to synchronize the terminology of LLN with ROLL Ch= arter. As what has been described in current ROLL WG Charter: "Low power and Lossy networks (LLNs) are made up of many embedded devices w= ith limited power, memory, and processing resources. They are interconnecte= d by a variety of links, such as IEEE 802.15.4, Bluetooth, Low Power WiFi, = wired or other low power PLC (Powerline Communication) links. " However, In the ongoing terminology draft, draft-ietf-roll-terminology-05, = it only says that: "Low power and Lossy networks (LLNs) are typically composed of many embedde= d devices with limited power, memory, and processing resources interconnect= ed by a variety of links, such as IEEE 802.15.4, Low Power WiFi." Bluetooth is missed here. As we know in new Bluetooth 4.0, which also includes of low energy use case= s as BTLE. And a new I-D draft about IPv6 over BTLE also starting in 6LoWPA= N WG. So here I propose to modify LLN terminology in the terminology-05 draft, to= add Bluetooth in. Thanks, -- Wang Feng. Shawn _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Thu Mar 31 08:43:47 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D32FF3A6B0E for ; Thu, 31 Mar 2011 08:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.285 X-Spam-Level: X-Spam-Status: No, score=-110.285 tagged_above=-999 required=5 tests=[AWL=0.313, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnWAtoG195Nj for ; Thu, 31 Mar 2011 08:43:46 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 734B73A690D for ; Thu, 31 Mar 2011 08:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=2755; q=dns/txt; s=iport; t=1301586326; x=1302795926; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=KzHeHtAwOSmc+GKRtj0nGTT0UtUetoLP0yTeGADhIV8=; b=CZXxSSuU94R2I0ey8HcLf4YoE5zwoLWXIe3JMe820KcjgMAMX/+yRWf1 ynrItWdQwVllAlAq7gxW+nNE4GCLCw+3WzhL+AUyOQNqBcJsCTuVmGm8I uJ+H3P4aEvUezb/Vk9y365XTDWop6C5lfL9ux0VAo9SksnurkciR3b/4e 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ai4EAP2flE2Q/khMgWdsb2JhbAClTRQBARYmJYh5mkGcH4VrBI0Rg1s X-IronPort-AV: E=Sophos;i="4.63,276,1299456000"; d="scan'208,217";a="23982322" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-2.cisco.com with ESMTP; 31 Mar 2011 15:45:25 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id p2VFjPOv028666; Thu, 31 Mar 2011 15:45:25 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 17:45:14 +0200 Received: from dhcp-4074.meeting.ietf.org ([10.61.86.169]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 31 Mar 2011 17:45:14 +0200 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: multipart/alternative; boundary=Apple-Mail-136--990917778 From: JP Vasseur In-Reply-To: Date: Thu, 31 Mar 2011 17:45:12 +0200 Message-Id: <5340275F-3E23-44EB-BC0C-BC978905CF39@cisco.com> References: <31C5813F-62CE-4510-B7B2-6FD720029A8C@cisco.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 31 Mar 2011 15:45:14.0053 (UTC) FILETIME=[A02E3750:01CBEFBA] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18046.000 X-TM-AS-Result: No--24.308100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] Still slides missing ... X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 15:43:48 -0000 --Apple-Mail-136--990917778 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii You're welcome Ulrich. Thanks. JP. On Mar 31, 2011, at 3:48 PM, Ulrich Herberg wrote: > Okay, they are just mixed up! :-) Got it=20 >=20 > Thanks! >=20 > On Thu, Mar 31, 2011 at 3:41 PM, Ulrich Herberg = wrote: > Unfortunately, several slide sets have not been uploaded. I would like = to access them, since I participate remotely. >=20 > Ulrich >=20 >=20 > On Thu, Mar 31, 2011 at 11:05 AM, JP Vasseur wrote: >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-136--990917778 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii You're welcome Ulrich.

Thanks.

JP.

On Mar 31, 2011, at 3:48 PM, Ulrich Herberg wrote:

Okay, they are just mixed up! :-) Got it

Thanks!

On Thu, Mar 31, 2011 at 3:41 PM, Ulrich Herberg <ulrich@herberg.name> wrote:
Unfortunately, several slide sets have not been uploaded. I would like to access them, since I participate remotely.

Ulrich


On Thu, Mar 31, 2011 at 11:05 AM, JP Vasseur <jpv@cisco.com> wrote:

_______________________________________________
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-136--990917778-- From jpv@cisco.com Thu Mar 31 21:12:07 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15F483A69D0 for ; Thu, 31 Mar 2011 21:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.305 X-Spam-Level: X-Spam-Status: No, score=-110.305 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oG1yOnsRWis1 for ; Thu, 31 Mar 2011 21:12:06 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by core3.amsl.com (Postfix) with ESMTP id 107103A6BD7 for ; Thu, 31 Mar 2011 21:12:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=560; q=dns/txt; s=iport; t=1301631226; x=1302840826; h=from:content-transfer-encoding:subject:date:message-id: cc:to:mime-version; bh=JJbwdMgwcDmS1tLrlT21X5ha1/1xyQvpEUQ5IWYLc2Y=; b=hkpCHn8kxwnLbk+GrWZkAQ2fbdfOPL37NLddSGqn+P8/77ljjtIzdohU h4Qr3aHRCc+TaT6kykxOShejOma2CTaQu+0sr/XR0kCfurvJB7TNVbn7k Q6qAnRfeTj8/MG22iS0XlwR85v4eLHXe+nzlQv52iMVVQQPrzCcCI33WL g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsDADJQlU2Q/khLgWdsb2JhbAClWhQBARYmJaN9nDeFawSNFoNe X-IronPort-AV: E=Sophos;i="4.63,280,1299456000"; d="scan'208";a="24040463" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 01 Apr 2011 04:13:45 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p314Djnt032154; Fri, 1 Apr 2011 04:13:45 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 06:13:45 +0200 Received: from dhcp-4074.meeting.ietf.org ([10.55.91.83]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 06:13:44 +0200 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2011 06:13:44 +0200 Message-Id: <8DA4DAEA-B896-44D8-946E-536D358495DE@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 01 Apr 2011 04:13:44.0689 (UTC) FILETIME=[31016E10:01CBF023] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-18046.004 X-TM-AS-Result: No--10.685400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: [Roll] WG Last Call draft-ietf-roll-minrank-hysteresis-of-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 04:12:07 -0000 Dear all, draft-ietf-roll-minrank-hysteresis-of has been discussed for quite some = time,=20 the document is stable and is now ready for Working Group Last Call. As = discussed during the WG meeting yesterday, there a very questions to address. This starts a 2-week WG Last call on = draft-ietf-roll-minrank-hysteresis-of-02=20 that will end on April 11 at noon ET (this is a bit more than 2 weeks, = considering most of us flying back end of this week). Please send your comments to the authors and copy the mailing list. Thanks. JP.= From jpv@cisco.com Thu Mar 31 21:55:08 2011 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BDE73A6BE9 for ; Thu, 31 Mar 2011 21:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.322 X-Spam-Level: X-Spam-Status: No, score=-110.322 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ls4oxVlZPCPL for ; Thu, 31 Mar 2011 21:55:06 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id CDEA73A6A28 for ; Thu, 31 Mar 2011 21:55:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=295; q=dns/txt; s=iport; t=1301633806; x=1302843406; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=ssH7BHTG4kqrRsQkY/0KQfe/6EXQbGcQ0nw7M3vIDXg=; b=gjn8/yOeA0E79I2XITkEN5NsvAB7BmPxgT+B7pdEUsJJBjFVVcMJl8XG x0ATwzjRsWZpR7Vb6DWnR80xO62j9uxyJz/5t3329uLhXJrhwi3Ew4+jX XFC54tzv5uTMSEGF3zISaUoCgVr+GKc5qdQ8mFUXEiqYIFdz1ptThUCyp Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsDAEBalU2Q/khNgWdsb2JhbAClWhQBARYmJaNenC2FawSNFoNe X-IronPort-AV: E=Sophos;i="4.63,280,1299456000"; d="scan'208";a="81750102" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2011 04:56:44 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id p314ujs4025884 for ; Fri, 1 Apr 2011 04:56:45 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 06:56:44 +0200 Received: from dhcp-4074.meeting.ietf.org ([10.55.91.83]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 1 Apr 2011 06:56:44 +0200 From: JP Vasseur Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 1 Apr 2011 06:56:43 +0200 Message-Id: <43AEA790-8199-4A86-A318-4963713CD991@cisco.com> To: ROLL WG Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) X-OriginalArrivalTime: 01 Apr 2011 04:56:44.0643 (UTC) FILETIME=[32C72B30:01CBF029] Subject: [Roll] Adoption draft-goyal-roll-p2p-measurement-01 as a ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Apr 2011 04:55:08 -0000 Dear all, draft-goyal-roll-p2p-measurement has been discussed on the mailing list = and is a normative reference of the P2P document. Could you tell us if you are in favor/opposed to adopt = draft-goyal-roll-p2p-measurement-01 as=20 a ROLL Working Group document ? Thanks. JP.=