From brian.e.carpenter@gmail.com Fri May 4 04:58:51 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AD3821F85C2 for ; Fri, 4 May 2012 04:58:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.554 X-Spam-Level: X-Spam-Status: No, score=-101.554 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_ILLEGAL_IP=1.908, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1FNIw6+87Ac for ; Fri, 4 May 2012 04:58:50 -0700 (PDT) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 9251021F858F for ; Fri, 4 May 2012 04:58:50 -0700 (PDT) Received: by eeke51 with SMTP id e51so886673eek.31 for ; Fri, 04 May 2012 04:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GRrY/vM7aOYFP4ae7iB0caIF2CZLAnX3rI5p76PgmDY=; b=ERBE6oJUj/FMGbi6lUletl/KOHv0m1/s8El9K6xlSBrn5VPZXkTrPBfF63RDuxCLPt 8N/KtQW2R9HQ+AcD5BaUB+nuL8+OdobXPMx2Hvr2tWpB51cnHiyHy6Tbwq8jVVlfLq1h DMt50nN00ENNSl04bNdvXam2zaH3jg+sVVabJoaySEXufR8wGD1DKM39acud07Z4fLG7 ViDoUBny0KBReJWlmfm9/xHOf+G52akNI5ofT1H8PAdc/CO61dP6A/fHFu7HctNNVhJL qe+Jh3VJhFoewHH+IASgJmpZxDY359g+tpmkDwxT1Im3bYJsplxDOs3Xe7fyloPO8h9w L0vw== Received: by 10.14.100.208 with SMTP id z56mr1106847eef.79.1336132729571; Fri, 04 May 2012 04:58:49 -0700 (PDT) Received: from [192.168.1.65] (host-2-102-217-144.as13285.net. [2.102.217.144]) by mx.google.com with ESMTPS id m42sm40556354eef.0.2012.05.04.04.58.47 (version=SSLv3 cipher=OTHER); Fri, 04 May 2012 04:58:48 -0700 (PDT) Message-ID: <4FA3C476.5000903@gmail.com> Date: Fri, 04 May 2012 12:58:46 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: roll@ietf.org, pthubert@cisco.com References: <20120504080338.24030.4170.idtracker@ietfa.amsl.com> In-Reply-To: <20120504080338.24030.4170.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 04 May 2012 07:29:31 -0700 Subject: Re: [Roll] I-D Action: draft-thubert-roll-flow-label-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 11:58:51 -0000 Hi, IMHO there are problems with this proposal. One is that it doesn't, as far as I can see, demonstrate that the overhead of rewriting the flow label on exit from an RPL domain is significantly less than the overhead of dealing with the RPL hop-by-hop option at the edge of the domain. Then, this phrase: > Sadly, the Option must be placed in > a Hop-by-Hop option that must be inserted or removed as the packet > crosses the border of the RPL domain. bothers me, because (and I have looked recently) there is nothing in the IPv6 specs that allows for an extension header being inserted (or removed) en route. The text continues > ...This operation may involve an > extra encapsulation that is detrimental to the network operation, in > particular with regards to bandwidth and battery constraints. Why "may"? If the packet is inbound to RPL, RFC 6553 makes it clear that it must be encapsulated; if the packet is outbound, why would it be encapsulated at all? This case is covered in the RFC too: > 3. Datagrams destined to nodes outside the RPL Instance are dropped > if the outermost IPv6 header contains a RPL Option not generated > by the RPL router forwarding the datagram. Then, the draft says: > This document specifies how the Flow Label can be reused within the > RPL domain as a replacement to the RPL option. The use of the Flow > Label within a RPL domain is an instance of the stateful scenarios > decribed in [RFC6437]... In fact RFC 6437 carefully says very little about stateful scenarios; it does not describe them, but it does constrain them. Here is the entire section on this topic: > 4. Flow State Establishment Requirements > > A node that sets the flow label MAY also take part in a flow state > establishment method that results in assigning specific treatments to > specific flows, possibly including signaling. Any such method MUST > NOT disturb nodes taking part in the stateless scenario just > described. Thus, any node that sets flow label values according to a > stateful scheme MUST choose labels that conform to Section 3 of this > specification. Further details are not discussed in this document. The problem is that section 3 intentionally does not consider flow label values in which any of the bits have semantic significance, and this was the consensus in the 6MAN WG after a great deal of discussion. However, the present proposal assigns semantics to various bits in the flow label, destroying its desired property of belonging to a statistically uniform distribution. The issue is clearly stated in RFC 6437: > Once set to a non-zero value, the Flow Label is expected to be > delivered unchanged to the destination node(s). A forwarding node > MUST either leave a non-zero flow label value unchanged or change it > only for compelling operational security reasons as described in > Section 6.1. Regards Brian Carpenter (please keep me on CC as I am not on the ROLL list) From internet-drafts@ietf.org Fri May 4 15:22:48 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4794121F84D9; Fri, 4 May 2012 15:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UYGVbbSTYL28; Fri, 4 May 2012 15:22:47 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA64F21F84D0; Fri, 4 May 2012 15:22:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120504222247.8137.19518.idtracker@ietfa.amsl.com> Date: Fri, 04 May 2012 15:22:47 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 22:22:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power= and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-10.txt Pages : 33 Date : 2012-05-04 This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl/ From prvs=464c508de=mukul@uwm.edu Fri May 4 15:26:10 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1FCB21F84D8 for ; Fri, 4 May 2012 15:26:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.516 X-Spam-Level: X-Spam-Status: No, score=-5.516 tagged_above=-999 required=5 tests=[AWL=1.083, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PAI3lRPnMRMP for ; Fri, 4 May 2012 15:26:10 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 143CD21F84D0 for ; Fri, 4 May 2012 15:26:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EABNXpE9/AAAB/2dsb2JhbABFhW6wDQEBAQQBAQEgSxcPEQQBAQMCDRkCKSgIGQmIBAuZcY4+iWqJCYEviVyCXYINgRgEiGSNGpBCgwY Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 6770312E3BD for ; Fri, 4 May 2012 17:26:09 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+HKUixf7w-O for ; Fri, 4 May 2012 17:26:09 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 161E412E3BA for ; Fri, 4 May 2012 17:26:09 -0500 (CDT) Date: Fri, 4 May 2012 17:26:09 -0500 (CDT) From: Mukul Goyal To: roll@ietf.org Message-ID: <394138592.277867.1336170368990.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20120504222247.8137.19518.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 May 2012 22:26:10 -0000 Hi all This version takes care of all the tickets created for last call comments. To see the text specific to a particular ticket "xx", search for "\begin issue_xx" in: https://pantherfile.uwm.edu/mukul/public/files/draft-ietf-roll-p2p-rpl-10.txt Thanks Mukul ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Friday, May 4, 2012 5:22:47 PM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-10.txt Pages : 33 Date : 2012-05-04 This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-10.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From admin@ipv6it.org Sat May 5 02:04:17 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7753821F8562 for ; Sat, 5 May 2012 02:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UCXURQlQFcsH for ; Sat, 5 May 2012 02:04:16 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id C3C7D21F855F for ; Sat, 5 May 2012 02:04:15 -0700 (PDT) Received: by wibhm4 with SMTP id hm4so1482313wib.1 for ; Sat, 05 May 2012 02:04:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=a7fVJ/UZoA7FtskpOaiaL1AbcpVO9u/nhUZMF6/q5TM=; b=OeBTwaBV9uWcaXTZNyw/Jy6hwbKgXVEut0JSJTH9OHudcewDIjbCi7GXKl2UDiFCWk X2iaohZM/gURge9i5Ueqvv9bLXpKEHEWY8yp0fkAo4q7a3VRTLDMQY7Btrlzy9n1+omX ObjTeqRLXio3BnVzbFe20GPaTei/0hQWDZqh3YpoQ2SFwWt22InFkLZ1AeSPJwO7aQFd EjKno1sxm8hcLonPVjp31vvYAzUPBUzQxGgaVFyZ+0c1pdRN0apECD31LgRE6S7CfCZn rD+ZRIxgIukjJnYvm2fBMw++MxgjQByQsgrk0rnVxEvOMRP335t4IiHsX8b9dk8i313G 6J2w== Received: by 10.216.141.31 with SMTP id f31mr3426914wej.53.1336208654893; Sat, 05 May 2012 02:04:14 -0700 (PDT) Received: from [127.0.0.1] (host77-121-dynamic.8-87-r.retail.telecomitalia.it. [87.8.121.77]) by mx.google.com with ESMTPS id f19sm6447247wiw.11.2012.05.05.02.04.13 (version=SSLv3 cipher=OTHER); Sat, 05 May 2012 02:04:14 -0700 (PDT) Message-ID: <4FA4ED09.2060209@ipv6it.org> Date: Sat, 05 May 2012 11:04:09 +0200 From: Federico Consoli User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQk5+2agP4HTVBGn8IdKv7m46R8Qsoyou5b3/MnMN+5rDjHQaIv5KQBpxwHyOvn/Acr+826V Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 09:04:17 -0000 Hi, I disagree with the default value of trickle timer, especially for Imin=6 and K=1. If you got a dense network it could lead to a very long time to build DAG. Eg. Suppose you got 2 node A, B. Node A got about 15-20 neighbor Node B got only A as a neighbor. When node A receive its first DIO it resets trickle to Imin and it starts trickle timer. Since A got a lot of neighbor its probably receive another consistent DIO so it will suppress the DIO message and it will increase its Imin to 7. So if node A suppress 6-8 times its DIO node B will receive it after a long time. Finally if the link A-B got an ETX of 2 or 3 (or more) this time doubles. These situations are not uncommon, especially in the routers at the edge of dense networks. -- Regards Consoli Federico From prvs=4655d8005=mukul@uwm.edu Sat May 5 07:34:17 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D572E21F8570 for ; Sat, 5 May 2012 07:34:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.058 X-Spam-Level: X-Spam-Status: No, score=-6.058 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJQQUlnbgqFn for ; Sat, 5 May 2012 07:34:17 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 343CB21F856F for ; Sat, 5 May 2012 07:34:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EALo5pU9/AAAB/2dsb2JhbABFhXKwFQEBAQQBAQEgSwsMDw4DBAEBAwINGQIpKAgGExuHcwunbIkkiQUEgS+JUIUIgRgEiGSNGpBCgwc Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 5205A12E3BC; Sat, 5 May 2012 09:34:16 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h76G26YdwfXH; Sat, 5 May 2012 09:34:15 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id D81AB12E3BF; Sat, 5 May 2012 09:34:15 -0500 (CDT) Date: Sat, 5 May 2012 09:34:15 -0500 (CDT) From: Mukul Goyal To: Federico Consoli Message-ID: <1214243683.280068.1336228455558.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <4FA4ED09.2060209@ipv6it.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 14:34:18 -0000 On the other hand, if Imin/K are set less conservatively, you might see too many DIOs generated. There is no silver bullet. No single setting would work well in all situations. We do provide some guidance on how to set trickle timer in Section 9.2 of the draft. The trickle parameter values in default configuration option are a conservative estimate based on the desire to avoid too many DIOs. If these settings are not OK for a particular deployment, well then the default configuration option should not be used. The connectivity variance you described is indeed a tricky situation and would require a tradeoff with the need to avoid generating too many DIOs. I imagine one possible solution could be to allow a node to set its k based on its position (rank) in the DAG (k increases as you move closer to the edge). But, again there might be cases where this (or any other fix) wont work. Thanks Mukul ----- Original Message ----- From: "Federico Consoli" To: roll@ietf.org Sent: Saturday, May 5, 2012 4:04:09 AM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments Hi, I disagree with the default value of trickle timer, especially for Imin=6 and K=1. If you got a dense network it could lead to a very long time to build DAG. Eg. Suppose you got 2 node A, B. Node A got about 15-20 neighbor Node B got only A as a neighbor. When node A receive its first DIO it resets trickle to Imin and it starts trickle timer. Since A got a lot of neighbor its probably receive another consistent DIO so it will suppress the DIO message and it will increase its Imin to 7. So if node A suppress 6-8 times its DIO node B will receive it after a long time. Finally if the link A-B got an ETX of 2 or 3 (or more) this time doubles. These situations are not uncommon, especially in the routers at the edge of dense networks. -- Regards Consoli Federico _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From admin@ipv6it.org Sat May 5 08:23:30 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 554A021F85AC for ; Sat, 5 May 2012 08:23:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9r3-Ac5EPDh for ; Sat, 5 May 2012 08:23:29 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 034E421F85AA for ; Sat, 5 May 2012 08:23:28 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2544601wgb.13 for ; Sat, 05 May 2012 08:23:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=W6UgaXz8v7fU64JoJ8NbGC+l+CTPdRq9UYfrzN7w+2g=; b=IWSeoIBxJs1tvoSKCoDCB5Lq7ODB98rjhGIJ+MyN+Y3oY1LxN62gNkQMIu9fCbKBnI MVc2LTHuDtpvuQJ5ShK7BCAOcQy525Wh/oe4wA3D9xrwnvhnKcmCF1cBOWKa/ZPzNLsj KEQ9tdVPiR8QivaYwZ3JtK9+jdiQ2BuTz0+/eu0FQZj5LNG6TNz/fANylyyFpiQk+vxf ++Nb5gTJvL4oZgXLwKQCWwEParJLbB7EJLBH0DOKBvAHxlFO9aIz5nGFodnqczPNQTeo iai8dfRbdQ0NCFu18UG8aFcm5JUpL8teDyyo5nfAzcRG3X/bdHdKvUB//QsYGbTpjxkp orZg== Received: by 10.180.104.230 with SMTP id gh6mr21560168wib.22.1336231408071; Sat, 05 May 2012 08:23:28 -0700 (PDT) Received: from [127.0.0.1] (host77-121-dynamic.8-87-r.retail.telecomitalia.it. [87.8.121.77]) by mx.google.com with ESMTPS id ca3sm6474118wib.6.2012.05.05.08.23.26 (version=SSLv3 cipher=OTHER); Sat, 05 May 2012 08:23:27 -0700 (PDT) Message-ID: <4FA545E9.4030002@ipv6it.org> Date: Sat, 05 May 2012 17:23:21 +0200 From: Federico Consoli User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Roll@ietf.org References: <1214243683.280068.1336228455558.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <1214243683.280068.1336228455558.JavaMail.root@mail17.pantherlink.uwm.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmDctsC8+Rg5wDD2VYDCWDFVuyakMqBAPKyHKMOXlMsy8XGG8KVX0O9PErssx5Moo8UFleZ Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 15:23:30 -0000 Yes but even if you got a small Imin value, network congestion may be only in a small initial period because Imin is incremented at each submission. IMHO I think that K=1 is too conservative. The situation that I describedcan be seen from another point of view. Suppose now that A and B got about 15-20 neighbor. A got a rank of 500 B got a rank of 3000 A suppresses DIOs for the reason described previously so node B will continue to use a bad path for a very long time because it does "not know" that node A "exists". I think that K should be at least =2 or more. > On the other hand, if Imin/K are set less conservatively, you might see too many DIOs generated. There is no silver bullet. No single setting would work well in all situations. We do provide some guidance on how to set trickle timer in Section 9.2 of the draft. The trickle parameter values in default configuration option are a conservative estimate based on the desire to avoid too many DIOs. If these settings are not OK for a particular deployment, well then the default configuration option should not be used. The connectivity variance you described is indeed a tricky situation and would require a tradeoff with the need to avoid generating too many DIOs. I imagine one possible solution could be to allow a node to set its k based on its position (rank) in the DAG (k increases as you move closer to the edge). But, again there might be cases where this (or any other fix) wont work. > > Thanks > Mukul > > ----- Original Message ----- > From: "Federico Consoli" > To: roll@ietf.org > Sent: Saturday, May 5, 2012 4:04:09 AM > Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments > > Hi, > I disagree with the default value of trickle timer, especially for > Imin=6 and K=1. > If you got a dense network it could lead to a very long time to build DAG. > > Eg. Suppose you got 2 node A, B. > Node A got about 15-20 neighbor > Node B got only A as a neighbor. > > When node A receive its first DIO it resets trickle to Imin and it > starts trickle timer. Since A got a lot of neighbor its probably receive > another consistent DIO so it will suppress the DIO message and it will > increase its Imin to 7. So if node A suppress 6-8 times its DIO node B > will receive it after a long time. Finally if the link A-B got an ETX of > 2 or 3 (or more) this time doubles. > > These situations are not uncommon, especially in the routers at the edge > of dense networks. > -- Regards Consoli Federico From prvs=4655d8005=mukul@uwm.edu Sat May 5 09:06:00 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9BD21F8495 for ; Sat, 5 May 2012 09:06:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.238 X-Spam-Level: X-Spam-Status: No, score=-6.238 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0P3T6Egc6zqz for ; Sat, 5 May 2012 09:06:00 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id DB6C121F85CC for ; Sat, 5 May 2012 09:05:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EABdPpU9/AAAB/2dsb2JhbABFhXKwFQEBAQMBAQEBIEsLBQcPDgMEAQEDAg0ZAikoCAYTGQKHbgULp1GJHIkFBIEviVAFhQOBGASIZI0akEKDBw Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 57823499101; Sat, 5 May 2012 11:05:59 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlIe3pbl2HHx; Sat, 5 May 2012 11:05:58 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id F0755499103; Sat, 5 May 2012 11:05:58 -0500 (CDT) Date: Sat, 5 May 2012 11:05:58 -0500 (CDT) From: Mukul Goyal To: Federico Consoli Message-ID: <384247923.280425.1336233958879.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <4FA545E9.4030002@ipv6it.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: Roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 16:06:00 -0000 [Federico] >Yes but even if you got a small Imin value, network congestion may be only in a small initial period because Imin is incremented at each submission. [Mukul] In smart home environment, you care a lot about extra DIO packets (to save on battery). So, even though network congestion might be for a small time duration during one particular route discovery, the overall life time of a device might take a big hit over the course of multiple discoveries over time. [Federico] >IMHO I think that K=1 is too conservative. [Mukul] It is indeed conservative and that is because smart home needs it to be conservative. And smart home is the application environment that cares most about using the default configuration option in order to save on bytes (and hence battery). [Federico] >The situation that I describedcan be seen from another point of view. Suppose now that A and B got about 15-20 neighbor. A got a rank of 500 B got a rank of 3000 A suppresses DIOs for the reason described previously so node B will continue to use a bad path for a very long time because it does "not know" that node A "exists". I think that K should be at least =2 or more. [Mukul] Continue using bad path? The route discovery is still going on! In the scenario you described, B probably will take a long time to be "discovered" or perhaps not be discovered at all within the specified DAG lifetime. Thanks Mukul > On the other hand, if Imin/K are set less conservatively, you might see too many DIOs generated. There is no silver bullet. No single setting would work well in all situations. We do provide some guidance on how to set trickle timer in Section 9.2 of the draft. The trickle parameter values in default configuration option are a conservative estimate based on the desire to avoid too many DIOs. If these settings are not OK for a particular deployment, well then the default configuration option should not be used. The connectivity variance you described is indeed a tricky situation and would require a tradeoff with the need to avoid generating too many DIOs. I imagine one possible solution could be to allow a node to set its k based on its position (rank) in the DAG (k increases as you move closer to the edge). But, again there might be cases where this (or any other fix) wont work. > > Thanks > Mukul > > ----- Original Message ----- > From: "Federico Consoli" > To: roll@ietf.org > Sent: Saturday, May 5, 2012 4:04:09 AM > Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments > > Hi, > I disagree with the default value of trickle timer, especially for > Imin=6 and K=1. > If you got a dense network it could lead to a very long time to build DAG. > > Eg. Suppose you got 2 node A, B. > Node A got about 15-20 neighbor > Node B got only A as a neighbor. > > When node A receive its first DIO it resets trickle to Imin and it > starts trickle timer. Since A got a lot of neighbor its probably receive > another consistent DIO so it will suppress the DIO message and it will > increase its Imin to 7. So if node A suppress 6-8 times its DIO node B > will receive it after a long time. Finally if the link A-B got an ETX of > 2 or 3 (or more) this time doubles. > > These situations are not uncommon, especially in the routers at the edge > of dense networks. > -- Regards Consoli Federico _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From admin@ipv6it.org Sat May 5 09:31:46 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4089D21F84DD for ; Sat, 5 May 2012 09:31:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kLkkdG50-moa for ; Sat, 5 May 2012 09:31:45 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 5D70D21F84DC for ; Sat, 5 May 2012 09:31:45 -0700 (PDT) Received: by wibhr7 with SMTP id hr7so1871118wib.13 for ; Sat, 05 May 2012 09:31:44 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=F7cal1qrjAmoVUB4dw9wGi/HO8CtqyQfJ0e+eAdS6iY=; b=Jt10WewZEl/KMc3xZ1K70TCiMW0TxyL3Wy2diOGwxWL/UOaAQ+3Dl9XmKtFs1hz+XP SGwGPQq1qvZRWXYBWuOStrif3WU0uLDP5ebvXC4zNkLQLnkoHYAulNEzKr74CszXrhnr ec+36yKpzzraiJOQE198KYFxA0fiODz0qFnowuuqJdETHZmaIxiJIBh4IWdvcEL+mUN9 WP/kHmcY6D9Nfy1uQpHCUrhBZK27MT4kYRJrF+8qbWR8TgmLks13KwKKJKJvI6+i3UB6 Zc6HOTg8XwEbzSrGdquTJRBQVJZdF1Bh5xNjT+5FcWZBCbUkQZHfwLuVXLp9r0GZp3Rb cHlQ== Received: by 10.180.105.198 with SMTP id go6mr22013871wib.19.1336235504432; Sat, 05 May 2012 09:31:44 -0700 (PDT) Received: from [127.0.0.1] (host77-121-dynamic.8-87-r.retail.telecomitalia.it. [87.8.121.77]) by mx.google.com with ESMTPS id fl2sm10796761wib.2.2012.05.05.09.31.42 (version=SSLv3 cipher=OTHER); Sat, 05 May 2012 09:31:43 -0700 (PDT) Message-ID: <4FA555EB.5060005@ipv6it.org> Date: Sat, 05 May 2012 18:31:39 +0200 From: Federico Consoli User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mukul Goyal References: <384247923.280425.1336233958879.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <384247923.280425.1336233958879.JavaMail.root@mail17.pantherlink.uwm.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmX2ou3YZktOxsKXuyhZYZL+mZ2Atx7+olc+yKGUfCUIl1D7zOxUFvNGMlHqJX5262Gxq6M Cc: Roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 16:31:46 -0000 Il 05/05/2012 18.05, Mukul Goyal ha scritto: > [Federico] >> Yes but even if you got a small Imin value, network congestion may be > only in a small initial period because Imin is incremented at each > submission. > > [Mukul] > In smart home environment, you care a lot about extra DIO packets (to save on battery). So, even though network congestion might be for a small time duration during one particular route discovery, the overall life time of a device might take a big hit over the course of multiple discoveries over time. > [Federico] >> IMHO I think that K=1 is too conservative. > [Mukul] > It is indeed conservative and that is because smart home needs it to be conservative. And smart home is the application environment that cares most about using the default configuration option in order to save on bytes (and hence battery). > > [Federico] >> The situation that I describedcan be seen from another point of view. > Suppose now that A and B got about 15-20 neighbor. > A got a rank of 500 > B got a rank of 3000 > > A suppresses DIOs for the reason described previously so node B will > continue to use a bad path for a very long time because it does "not > know" that node A "exists". I think that K should be at least =2 or more. > > [Mukul] > Continue using bad path? The route discovery is still going on! In the scenario you described, B probably will take a long time to be "discovered" or perhaps not be discovered at all within the specified DAG lifetime. [Federico] Exactly, do not you think that the fact that node B take a long time to discover node Ais a problem? Suppose that node B wants to communicate with a neighbor of node A, it could lead to sending many unnecessary DIOs. > > Thanks > Mukul > > > >> On the other hand, if Imin/K are set less conservatively, you might see too many DIOs generated. There is no silver bullet. No single setting would work well in all situations. We do provide some guidance on how to set trickle timer in Section 9.2 of the draft. The trickle parameter values in default configuration option are a conservative estimate based on the desire to avoid too many DIOs. If these settings are not OK for a particular deployment, well then the default configuration option should not be used. The connectivity variance you described is indeed a tricky situation and would require a tradeoff with the need to avoid generating too many DIOs. I imagine one possible solution could be to allow a node to set its k based on its position (rank) in the DAG (k increases as you move closer to the edge). But, again there might be cases where this (or any other fix) wont work. >> >> Thanks >> Mukul >> >> ----- Original Message ----- >> From: "Federico Consoli" >> To: roll@ietf.org >> Sent: Saturday, May 5, 2012 4:04:09 AM >> Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments >> >> Hi, >> I disagree with the default value of trickle timer, especially for >> Imin=6 and K=1. >> If you got a dense network it could lead to a very long time to build DAG. >> >> Eg. Suppose you got 2 node A, B. >> Node A got about 15-20 neighbor >> Node B got only A as a neighbor. >> >> When node A receive its first DIO it resets trickle to Imin and it >> starts trickle timer. Since A got a lot of neighbor its probably receive >> another consistent DIO so it will suppress the DIO message and it will >> increase its Imin to 7. So if node A suppress 6-8 times its DIO node B >> will receive it after a long time. Finally if the link A-B got an ETX of >> 2 or 3 (or more) this time doubles. >> >> These situations are not uncommon, especially in the routers at the edge >> of dense networks. >> > -- Regards Consoli Federico From prvs=4655d8005=mukul@uwm.edu Sat May 5 09:51:04 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D6821F847C for ; Sat, 5 May 2012 09:51:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhlPgm2evNUp for ; Sat, 5 May 2012 09:51:04 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id C209321F847B for ; Sat, 5 May 2012 09:51:01 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EABZZpU9/AAAB/2dsb2JhbABFhXKwFQEBBAEjVgwPDgMEAQEDAg0EFQJRCAYTG4duBadYiRuJCYEviVCCboIagRgEiGSNGpBCgwc Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 401071FD0C7; Sat, 5 May 2012 11:51:01 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ais1oJ-XzPAP; Sat, 5 May 2012 11:51:00 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id BFA4A1FD0A9; Sat, 5 May 2012 11:51:00 -0500 (CDT) Date: Sat, 5 May 2012 11:51:00 -0500 (CDT) From: Mukul Goyal To: Federico Consoli Message-ID: <387137981.280728.1336236660623.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <4FA555EB.5060005@ipv6it.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: Roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 16:51:04 -0000 > [Federico] >> The situation that I describedcan be seen from another point of view. > Suppose now that A and B got about 15-20 neighbor. > A got a rank of 500 > B got a rank of 3000 > > A suppresses DIOs for the reason described previously so node B will > continue to use a bad path for a very long time because it does "not > know" that node A "exists". I think that K should be at least =2 or more. > > [Mukul] > Continue using bad path? The route discovery is still going on! In the scenario you described, B probably will take a long time to be "discovered" or perhaps not be discovered at all within the specified DAG lifetime. [Federico2] Exactly, do not you think that the fact that node B take a long time to discover node Ais a problem? [Mukul2] No, it is not if B also has 15-20 neighbors like A. As long as the origin discovers a path to B that meets the specified constraints, there is no problem. It does not matter if the discovered path is through A or not. [Federico2] Suppose that node B wants to communicate with a neighbor of node A, it could lead to sending many unnecessary DIOs. [Mukul2] You described two separate scenarios: 1) A has 15 neighbors, B has just A as the neighbor. 2) Both A and B have 15 neighbors including each other. In the second scenario, K=1 definitely makes sense because there are many candidate paths and one such path to B would probably be discovered even though many of B's neighbors would end up suppressing their DIOs. It is possible that the discovered route wont pass through A. In the first scenario, discovery of a route to B depends on A making a DIO transmission and B receiving it. This would be delayed if A ends up suppressing its DIO again and again. The route discovery would fail if DAG lifetime is over before B could receive the A's DIO. If that is very likely to happen in a particular deployment, K should not be 1. No doubt about it. But, we cannot set the K value in default configuration option to account for this case, which is certainly not the common case. Thanks Mukul >> On the other hand, if Imin/K are set less conservatively, you might see too many DIOs generated. There is no silver bullet. No single setting would work well in all situations. We do provide some guidance on how to set trickle timer in Section 9.2 of the draft. The trickle parameter values in default configuration option are a conservative estimate based on the desire to avoid too many DIOs. If these settings are not OK for a particular deployment, well then the default configuration option should not be used. The connectivity variance you described is indeed a tricky situation and would require a tradeoff with the need to avoid generating too many DIOs. I imagine one possible solution could be to allow a node to set its k based on its position (rank) in the DAG (k increases as you move closer to the edge). But, again there might be cases where this (or any other fix) wont work. >> >> Thanks >> Mukul >> >> ----- Original Message ----- >> From: "Federico Consoli" >> To: roll@ietf.org >> Sent: Saturday, May 5, 2012 4:04:09 AM >> Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments >> >> Hi, >> I disagree with the default value of trickle timer, especially for >> Imin=6 and K=1. >> If you got a dense network it could lead to a very long time to build DAG. >> >> Eg. Suppose you got 2 node A, B. >> Node A got about 15-20 neighbor >> Node B got only A as a neighbor. >> >> When node A receive its first DIO it resets trickle to Imin and it >> starts trickle timer. Since A got a lot of neighbor its probably receive >> another consistent DIO so it will suppress the DIO message and it will >> increase its Imin to 7. So if node A suppress 6-8 times its DIO node B >> will receive it after a long time. Finally if the link A-B got an ETX of >> 2 or 3 (or more) this time doubles. >> >> These situations are not uncommon, especially in the routers at the edge >> of dense networks. >> > -- Regards Consoli Federico From admin@ipv6it.org Sat May 5 10:11:23 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD78321F84E7 for ; Sat, 5 May 2012 10:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5yGwrOcj2eN for ; Sat, 5 May 2012 10:11:23 -0700 (PDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id AA93321F84D9 for ; Sat, 5 May 2012 10:11:22 -0700 (PDT) Received: by wgbdr13 with SMTP id dr13so2581350wgb.13 for ; Sat, 05 May 2012 10:11:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=ep2H8tOdSjlnjXwktbbzLQKrZqALYRyktyfuyZauT4M=; b=VpOLY8eXstaQrn79nAMVOSL/9L5dr5bKG4kcPQIMVxjFCQcN4/vsw+6zpAJoqf/XAg 0g2P4fUCNMJ1jRLB6xdIbA3tf2mH7j5fCLgBXzy59dIrUcOf32MDqT2FduGUI4ueRfTy We2m/s4To3T6KW2j6kBfq2FDPsII5GMHv1W2+Ysf13C+IpuCevuL9rcSETPvXFvxbyjF LFMj13nZEO8QaHnkMrGkkxpEjy4LKgOUL97hzIevZxXHSa5UsYL0YJB8XgAmF2hf1nzH ht4UtxEDFNm8xs/t15TytoU/qd1JGPKxgN737j0K6QS8F0MOee8k55TbjYPIeMxUZu5+ 2tIw== Received: by 10.180.105.69 with SMTP id gk5mr25463408wib.3.1336237881816; Sat, 05 May 2012 10:11:21 -0700 (PDT) Received: from [127.0.0.1] (host77-121-dynamic.8-87-r.retail.telecomitalia.it. [87.8.121.77]) by mx.google.com with ESMTPS id fn2sm11194314wib.0.2012.05.05.10.11.20 (version=SSLv3 cipher=OTHER); Sat, 05 May 2012 10:11:21 -0700 (PDT) Message-ID: <4FA55F33.2030308@ipv6it.org> Date: Sat, 05 May 2012 19:11:15 +0200 From: Federico Consoli User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Roll@ietf.org References: <387137981.280728.1336236660623.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <387137981.280728.1336236660623.JavaMail.root@mail17.pantherlink.uwm.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQmlZSA8+oIDKQd9y2I42inaJ+14ukbgfZuwQmBNAewYVBz/iozQfV2XeFqa2IF8sxKUF0t4 Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 17:11:23 -0000 Il 05/05/2012 18.51, Mukul Goyal ha scritto: >> [Federico] >>> The situation that I describedcan be seen from another point of view. >> Suppose now that A and B got about 15-20 neighbor. >> A got a rank of 500 >> B got a rank of 3000 >> >> A suppresses DIOs for the reason described previously so node B will >> continue to use a bad path for a very long time because it does "not >> know" that node A "exists". I think that K should be at least =2 or more. >> >> [Mukul] >> Continue using bad path? The route discovery is still going on! In the scenario you described, B probably will take a long time to be "discovered" or perhaps not be discovered at all within the specified DAG lifetime. > [Federico2] > Exactly, do not you think that the fact that node B take a long time to > discover node Ais a problem? > > [Mukul2] > No, it is not if B also has 15-20 neighbors like A. As long as the origin discovers a path to B that meets the specified constraints, there is no problem. It does not matter if the discovered path is through A or not. > > [Federico2] > Suppose that node B wants to communicate > with a neighbor of node A, it could lead to sending many unnecessary DIOs. > > [Mukul2] > You described two separate scenarios: > 1) A has 15 neighbors, B has just A as the neighbor. > 2) Both A and B have 15 neighbors including each other. > > In the second scenario, K=1 definitely makes sense because there are many candidate paths and one such path to B would probably be discovered even though many of B's neighbors would end up suppressing their DIOs. It is possible that the discovered route wont pass through A. [Federico3] I think this is the problem, the fact that the node B does not have full information about the status of his neighborhood. In the second scenario node B will use a path almost certainly worse to reach a neighbor of the node A. > In the first scenario, discovery of a route to B depends on A making a DIO transmission and B receiving it. This would be delayed if A ends up suppressing its DIO again and again. The route discovery would fail if DAG lifetime is over before B could receive the A's DIO. If that is very likely to happen in a particular deployment, K should not be 1. No doubt about it. But, we cannot set the K value in default configuration option to account for this case, which is certainly not the common case. > > Thanks > Mukul > > >>> On the other hand, if Imin/K are set less conservatively, you might see too many DIOs generated. There is no silver bullet. No single setting would work well in all situations. We do provide some guidance on how to set trickle timer in Section 9.2 of the draft. The trickle parameter values in default configuration option are a conservative estimate based on the desire to avoid too many DIOs. If these settings are not OK for a particular deployment, well then the default configuration option should not be used. The connectivity variance you described is indeed a tricky situation and would require a tradeoff with the need to avoid generating too many DIOs. I imagine one possible solution could be to allow a node to set its k based on its position (rank) in the DAG (k increases as you move closer to the edge). But, again there might be cases where this (or any other fix) wont work. >>> >>> Thanks >>> Mukul >>> >>> ----- Original Message ----- >>> From: "Federico Consoli" >>> To: roll@ietf.org >>> Sent: Saturday, May 5, 2012 4:04:09 AM >>> Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments >>> >>> Hi, >>> I disagree with the default value of trickle timer, especially for >>> Imin=6 and K=1. >>> If you got a dense network it could lead to a very long time to build DAG. >>> >>> Eg. Suppose you got 2 node A, B. >>> Node A got about 15-20 neighbor >>> Node B got only A as a neighbor. >>> >>> When node A receive its first DIO it resets trickle to Imin and it >>> starts trickle timer. Since A got a lot of neighbor its probably receive >>> another consistent DIO so it will suppress the DIO message and it will >>> increase its Imin to 7. So if node A suppress 6-8 times its DIO node B >>> will receive it after a long time. Finally if the link A-B got an ETX of >>> 2 or 3 (or more) this time doubles. >>> >>> These situations are not uncommon, especially in the routers at the edge >>> of dense networks. >>> > -- Regards Consoli Federico From prvs=4655d8005=mukul@uwm.edu Sat May 5 10:18:05 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2054921F85A5 for ; Sat, 5 May 2012 10:18:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWAW+AxJ5LnQ for ; Sat, 5 May 2012 10:18:04 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 93A8021F859E for ; Sat, 5 May 2012 10:18:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEADlgpU9/AAAB/2dsb2JhbABFhXKwHCNxGgINGQJZBoghmRaOPokaiQmBL45YgRgEiGSNGpBCgwc Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 01FF0E6A8D for ; Sat, 5 May 2012 12:18:04 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujI+t85zur5D for ; Sat, 5 May 2012 12:18:03 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id C7762E6A8C for ; Sat, 5 May 2012 12:18:03 -0500 (CDT) Date: Sat, 5 May 2012 12:18:03 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1039288746.280931.1336238283627.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <1551139513.280929.1336238190771.JavaMail.root@mail17.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 17:18:05 -0000 > [Mukul2] > You described two separate scenarios: > 1) A has 15 neighbors, B has just A as the neighbor. > 2) Both A and B have 15 neighbors including each other. > > In the second scenario, K=1 definitely makes sense because there are many candidate paths and one such path to B would probably be discovered even though many of B's neighbors would end up suppressing their DIOs. It is possible that the discovered route wont pass through A. [Federico3] I think this is the problem, the fact that the node B does not have full information about the status of his neighborhood. In the second scenario node B will use a path almost certainly worse to reach a neighbor of the node A. [Mukul3] IMHO, there is no problem. There is no need for B to know the route through each neighbor. All it needs to know is one path that meets the constraints specified by the origin. The need to avoid too many DIO transmissions is critical and K in default configuration option is set to reflect this priority. Thanks Mukul From admin@ipv6it.org Sat May 5 10:27:36 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC36721F85D9 for ; Sat, 5 May 2012 10:27:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aISiXNI+EZHZ for ; Sat, 5 May 2012 10:27:36 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) by ietfa.amsl.com (Postfix) with ESMTP id 1F61F21F85C0 for ; Sat, 5 May 2012 10:27:35 -0700 (PDT) Received: by wibhr7 with SMTP id hr7so1892729wib.13 for ; Sat, 05 May 2012 10:27:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=jKY72TVOkWljQhc6dyncb7nbTwZBUQdsFyJFIzpb0gU=; b=e3C2izczQOYq7c0cNYsR1f4WVvZisTyDKbsksgo+ZuafaWWXagMYREFchwHeWv0Diq u634o+LKey9ltxPQIlOJYEougpF8Z+tl1GNOn9k3kHgqSwpbH9NlJQbu/B/z8tQUNH+6 RmpaL3AamA+D1/bZyY/BB9fHkDNpgdDTyDR6+OeJGBm4bAjnTSMj1amyQOWzyrq+i7iw Phky0uGpeHnQJzEaXvSK+CmFi7vkWe4lc6zubE/VCjM9bUYA3bicijVjhVtIxvyljc6V IfjDsxmSm1qNM7S+mH8mv2WFaDEDUUxqUEf0jtn+RU7A6eeHgVmX07aQ5+x6T7gvRQDs qkRA== Received: by 10.180.24.130 with SMTP id u2mr3858300wif.12.1336238854900; Sat, 05 May 2012 10:27:34 -0700 (PDT) Received: from [127.0.0.1] (host77-121-dynamic.8-87-r.retail.telecomitalia.it. [87.8.121.77]) by mx.google.com with ESMTPS id j3sm11344826wiw.1.2012.05.05.10.27.32 (version=SSLv3 cipher=OTHER); Sat, 05 May 2012 10:27:34 -0700 (PDT) Message-ID: <4FA562FF.5090909@ipv6it.org> Date: Sat, 05 May 2012 19:27:27 +0200 From: Federico Consoli User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Mukul Goyal References: <1039288746.280931.1336238283627.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <1039288746.280931.1336238283627.JavaMail.root@mail17.pantherlink.uwm.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQktlZpePuRyjMLF4rKd983tNn7jglDbx3HsbfbNa1U0e4zBkBxuFycGycmwaZFtGeOtCoCx Cc: Roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 17:27:37 -0000 Il 05/05/2012 19.18, Mukul Goyal ha scritto: >> [Mukul2] >> You described two separate scenarios: >> 1) A has 15 neighbors, B has just A as the neighbor. >> 2) Both A and B have 15 neighbors including each other. >> >> In the second scenario, K=1 definitely makes sense because there are many candidate paths and one such path to B would probably be discovered even though many of B's neighbors would end up suppressing their DIOs. It is possible that the discovered route wont pass through A. > [Federico3] > I think this is the problem, the fact that the node B does not have full > information about the status of his neighborhood. In the second scenario > node B will use a path almost certainly worse to reach a neighbor of the > node A. > > [Mukul3] > IMHO, there is no problem. There is no need for B to know the route through each neighbor. All it needs to know is one path that meets the constraints specified by the origin. The need to avoid too many DIO transmissions is critical and K in default configuration option is set to reflect this priority. [Federico4] Yes but the information about the route through each neighbor is very important for the objective function. > Thanks > Mukul > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- Regards Consoli Federico From prvs=4655d8005=mukul@uwm.edu Sat May 5 10:44:10 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB15D21F84D6 for ; Sat, 5 May 2012 10:44:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.418 X-Spam-Level: X-Spam-Status: No, score=-6.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16TFQSDTf1p8 for ; Sat, 5 May 2012 10:44:10 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 353F121F84AF for ; Sat, 5 May 2012 10:44:10 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAHxmpU9/AAAB/2dsb2JhbABFhXKwFQEBAQMBAQEBIEsLBQcPDgMEAQEDAg0ZAikoCAYTiAkFC6dDiRqJBQSBL4lQhQiBGASIZI0akEKDBw Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id AEBF81FD0C7; Sat, 5 May 2012 12:44:09 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSSin7ios1V0; Sat, 5 May 2012 12:44:09 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 34A9E1FD0A9; Sat, 5 May 2012 12:44:09 -0500 (CDT) Date: Sat, 5 May 2012 12:44:09 -0500 (CDT) From: Mukul Goyal To: Federico Consoli Message-ID: <643639228.281047.1336239849113.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <4FA562FF.5090909@ipv6it.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: Roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 May 2012 17:44:10 -0000 I have no further comment to make. I think we disgree on this point. Thanks Mukul ----- Original Message ----- From: "Federico Consoli" To: "Mukul Goyal" Cc: Roll@ietf.org Sent: Saturday, May 5, 2012 12:27:27 PM Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments Il 05/05/2012 19.18, Mukul Goyal ha scritto: >> [Mukul2] >> You described two separate scenarios: >> 1) A has 15 neighbors, B has just A as the neighbor. >> 2) Both A and B have 15 neighbors including each other. >> >> In the second scenario, K=1 definitely makes sense because there are many candidate paths and one such path to B would probably be discovered even though many of B's neighbors would end up suppressing their DIOs. It is possible that the discovered route wont pass through A. > [Federico3] > I think this is the problem, the fact that the node B does not have full > information about the status of his neighborhood. In the second scenario > node B will use a path almost certainly worse to reach a neighbor of the > node A. > > [Mukul3] > IMHO, there is no problem. There is no need for B to know the route through each neighbor. All it needs to know is one path that meets the constraints specified by the origin. The need to avoid too many DIO transmissions is critical and K in default configuration option is set to reflect this priority. [Federico4] Yes but the information about the route through each neighbor is very important for the objective function. > Thanks > Mukul > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- Regards Consoli Federico From adrian@olddog.co.uk Sat May 5 17:14:56 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45AD421F8573 for ; Sat, 5 May 2012 17:14:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bZOoTlfEZWk for ; Sat, 5 May 2012 17:14:44 -0700 (PDT) Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) by ietfa.amsl.com (Postfix) with ESMTP id AF8F321F854B for ; Sat, 5 May 2012 17:14:43 -0700 (PDT) Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q460EgI5032492; Sun, 6 May 2012 01:14:42 +0100 Received: from 950129200 ([63.68.157.174]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id q460Ecxm032454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sun, 6 May 2012 01:14:41 +0100 From: "Adrian Farrel" To: "'Mukul Goyal'" , "'Federico Consoli'" References: <4FA562FF.5090909@ipv6it.org> <643639228.281047.1336239849113.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <643639228.281047.1336239849113.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Sun, 6 May 2012 01:14:37 +0100 Message-ID: <048a01cd2b1d$3b5d7940$b2186bc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIASLz6x0OpoF/GnASAsFBQFAOwTJZVqCjQ Content-Language: en-gb Cc: Roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 00:14:56 -0000 Hi, Can I make a suggestion? draft-ietf-roll-p2p-rpl is targeted at publication as an Experimental. Could you enhance the text around the suggested defaults and the guidance to expand a little on what the problems might be, and encourage specific experimentation and reports back to the WG? Adrian > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul > Goyal > Sent: 05 May 2012 18:44 > To: Federico Consoli > Cc: Roll@ietf.org > Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments > > I have no further comment to make. I think we disgree on this point. > > Thanks > Mukul > ----- Original Message ----- > From: "Federico Consoli" > To: "Mukul Goyal" > Cc: Roll@ietf.org > Sent: Saturday, May 5, 2012 12:27:27 PM > Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments > > Il 05/05/2012 19.18, Mukul Goyal ha scritto: > >> [Mukul2] > >> You described two separate scenarios: > >> 1) A has 15 neighbors, B has just A as the neighbor. > >> 2) Both A and B have 15 neighbors including each other. > >> > >> In the second scenario, K=1 definitely makes sense because there are many > candidate paths and one such path to B would probably be discovered even > though many of B's neighbors would end up suppressing their DIOs. It is possible > that the discovered route wont pass through A. > > [Federico3] > > I think this is the problem, the fact that the node B does not have full > > information about the status of his neighborhood. In the second scenario > > node B will use a path almost certainly worse to reach a neighbor of the > > node A. > > > > [Mukul3] > > IMHO, there is no problem. There is no need for B to know the route through > each neighbor. All it needs to know is one path that meets the constraints > specified by the origin. The need to avoid too many DIO transmissions is critical > and K in default configuration option is set to reflect this priority. > [Federico4] > Yes but the information about the route through each neighbor is very > important for the objective function. > > > Thanks > > Mukul > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > -- > Regards > Consoli Federico > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=466168d84=mukul@uwm.edu Sat May 5 18:34:27 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DC1021F852C for ; Sat, 5 May 2012 18:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.155, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8mEcPGdYYvoP for ; Sat, 5 May 2012 18:34:26 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0F85421F84D6 for ; Sat, 5 May 2012 18:34:25 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAPLUpU9/AAAB/2dsb2JhbABDhXKwFAEBAQQBAQEgSwsMDxEEAQEDAg0WAwIpHwkIGYgOC6deiHKJBQSBL4lQhQiBGASIZI0akEKDBw Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id AB3BE499102; Sat, 5 May 2012 20:33:58 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhpHNFXOdZ9d; Sat, 5 May 2012 20:33:58 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 3794C1FD0C9; Sat, 5 May 2012 20:33:58 -0500 (CDT) Date: Sat, 5 May 2012 20:33:58 -0500 (CDT) From: Mukul Goyal To: adrian@olddog.co.uk Message-ID: <1354322643.282916.1336268038026.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <048a01cd2b1d$3b5d7940$b2186bc0$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: Roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 01:34:27 -0000 >Could you enhance the text around the suggested defaults and the guidance to expand a little on what the problems might be, and encourage specific experimentation and reports back to the WG? Sure I will do that. Thanks Mukul ----- Original Message ----- From: "Adrian Farrel" To: "Mukul Goyal" , "Federico Consoli" Cc: Roll@ietf.org Sent: Saturday, May 5, 2012 7:14:37 PM Subject: RE: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments Hi, Can I make a suggestion? draft-ietf-roll-p2p-rpl is targeted at publication as an Experimental. Could you enhance the text around the suggested defaults and the guidance to expand a little on what the problems might be, and encourage specific experimentation and reports back to the WG? Adrian > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mukul > Goyal > Sent: 05 May 2012 18:44 > To: Federico Consoli > Cc: Roll@ietf.org > Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments > > I have no further comment to make. I think we disgree on this point. > > Thanks > Mukul > ----- Original Message ----- > From: "Federico Consoli" > To: "Mukul Goyal" > Cc: Roll@ietf.org > Sent: Saturday, May 5, 2012 12:27:27 PM > Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments > > Il 05/05/2012 19.18, Mukul Goyal ha scritto: > >> [Mukul2] > >> You described two separate scenarios: > >> 1) A has 15 neighbors, B has just A as the neighbor. > >> 2) Both A and B have 15 neighbors including each other. > >> > >> In the second scenario, K=1 definitely makes sense because there are many > candidate paths and one such path to B would probably be discovered even > though many of B's neighbors would end up suppressing their DIOs. It is possible > that the discovered route wont pass through A. > > [Federico3] > > I think this is the problem, the fact that the node B does not have full > > information about the status of his neighborhood. In the second scenario > > node B will use a path almost certainly worse to reach a neighbor of the > > node A. > > > > [Mukul3] > > IMHO, there is no problem. There is no need for B to know the route through > each neighbor. All it needs to know is one path that meets the constraints > specified by the origin. The need to avoid too many DIO transmissions is critical > and K in default configuration option is set to reflect this priority. > [Federico4] > Yes but the information about the route through each neighbor is very > important for the objective function. > > > Thanks > > Mukul > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > -- > Regards > Consoli Federico > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From admin@ipv6it.org Sun May 6 02:14:22 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECD4421F84D0 for ; Sun, 6 May 2012 02:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KeZFMeSHY3g for ; Sun, 6 May 2012 02:14:22 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1937C21F84C9 for ; Sun, 6 May 2012 02:14:21 -0700 (PDT) Received: by bkty8 with SMTP id y8so3686978bkt.31 for ; Sun, 06 May 2012 02:14:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=Cr9VrRMLqCoNd/G7Q3NeRnw1a9U34DRgRFMJA3aQkxE=; b=HfzGQ9l9o0LWSVn+h/y4kJ+UhPCRMVswWjhvNymxi+8Rp27XEYi6rfd2rlut+IzGsP yyZP5OP/+y2J2YSVLN/XNjxHbjLvXAkAlcp+s3kYAOuyKOk6HCTHwommhdyvUbxireuz uypHjFRCuOzwnJH/iMMEMhMMHcI+VhI89nKyKKxJ+mYIsSIjJX1b6xI+O5Md2UyeM+n2 1V1JrVmGZuGIpqAeyeYUuZQH5J3HwC0b6xwsgoVOdn4+pEn5KShBEXW4B4SzyZeAVOF9 JYozk4p9qVxVMzSd5BOX3ygL+tS9SqLzaMPEKTwG8m82VGR2KlL6hB2nmtmoDA61wTSe vUsg== Received: by 10.205.121.130 with SMTP id gc2mr4116993bkc.10.1336295660880; Sun, 06 May 2012 02:14:20 -0700 (PDT) Received: from [127.0.0.1] (host77-121-dynamic.8-87-r.retail.telecomitalia.it. [87.8.121.77]) by mx.google.com with ESMTPS id v2sm25816740bkw.16.2012.05.06.02.14.19 (version=SSLv3 cipher=OTHER); Sun, 06 May 2012 02:14:20 -0700 (PDT) Message-ID: <4FA640E6.1050707@ipv6it.org> Date: Sun, 06 May 2012 11:14:14 +0200 From: Federico Consoli User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Roll@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnooF5XnPM+WZto0nRJ+M91NzhyMvT4WZb3qsLK+Ew8fgNm9jtMXUfH0DDq3panU/6eOxaf Subject: [Roll] I-D Action: draft-ietf-roll-minrank-hysteresis-of-10 Comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 09:14:23 -0000 Hi, In [RFC6550] section 11.2. Loop Avoidance and Detection "SenderRank: 16-bit field set to zero by the source and to DAGRank(rank) by a router that forwards inside the RPL network." In MRHOF Section 2: "The terminologies used in this document are also consistent with the terminologies described in [RFC6550], except the term Rank. In this document, Rank refers to the value of the Rank field, not DAGRank as in [RFC6550]." I believe that it is fairly intuitiveto use Rank in SenderRank but I can also think that I could use DAGRank in the data-flow header. I think that to be more compliant with [RFC6550] (and also with [RFC6553]) I think you should also introduce the term SenderRankin section 2. What do you think? -- Regards Consoli Federico From internet-drafts@ietf.org Sun May 6 10:07:59 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0022A21F852E; Sun, 6 May 2012 10:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.441 X-Spam-Level: X-Spam-Status: No, score=-102.441 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iIvbpgf8Iy5y; Sun, 6 May 2012 10:07:58 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6845321F844F; Sun, 6 May 2012 10:07:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120506170758.8793.61340.idtracker@ietfa.amsl.com> Date: Sun, 06 May 2012 10:07:58 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-11.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 17:07:59 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power= and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-11.txt Pages : 33 Date : 2012-05-06 This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl/ From prvs=466168d84=mukul@uwm.edu Sun May 6 10:27:37 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2772E21F8494 for ; Sun, 6 May 2012 10:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aHbybnu72TjF for ; Sun, 6 May 2012 10:27:36 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7176221F8476 for ; Sun, 6 May 2012 10:27:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAM2zpk9/AAAB/2dsb2JhbABEhXKwDAEBAQQBAQEgSxcPEQQBAQMCDRkCKSgIBhMJiAULmSmOPohoiQmBL4lQHIRsgRgEiGSNGpBCgweBOBk Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id CFF7E2B3F16 for ; Sun, 6 May 2012 12:27:35 -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 kb6MKU9WzmsD for ; Sun, 6 May 2012 12:27:35 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 7DA252B3F1B for ; Sun, 6 May 2012 12:27:35 -0500 (CDT) Date: Sun, 6 May 2012 12:27:35 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1621446290.284733.1336325255378.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20120506170758.8793.61340.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-11.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 17:27:37 -0000 Based on the discussion with Federico and suggestion by Adrian, this version has the following changes: 1) Section 9.2 (Trickle Operation For P2P Mode DIOs) has more text on how to set Imin and the redundancy constant. The text now points out that Imin setting has an impact on the lifetime of the temporary DAG and redundancy constant value 1 may not be suitable in deployments where specific destinations are reachable only through specific intermediate routers. 2) Section 6.1 (Setting a P2P Mode DIO) has little more text regarding the rationale behind settings in the default configuration option. I guess trickle parameter settings needed explanation and I just referred the reader to Section 9.2. But, I also added some text for other parameters (e.g. lifetime parameters) to make the intention clear. 3) There was already some discussion in Section 7.1 (P2P Route Discovery Option) regarding how to set the lifetime of the temporary DAG. I added one sentence that made it clear that the lifetime of the temporary DAG has a dependence on the Trickle parameters (Imin and redundancy constant). This sentence is actually a repetition of what is already mentioned in Section 9.2. Thanks Mukul ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Sunday, May 6, 2012 12:07:58 PM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-11.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-11.txt Pages : 33 Date : 2012-05-06 This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-11.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From trac+roll@trac.tools.ietf.org Sun May 6 12:15:12 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A43421F855A for ; Sun, 6 May 2012 12:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.496 X-Spam-Level: X-Spam-Status: No, score=-102.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HJJjRLybHqp2 for ; Sun, 6 May 2012 12:15:11 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 9469421F8550 for ; Sun, 6 May 2012 12:15:10 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SR6v5-0006G0-Ub; Sun, 06 May 2012 15:15:00 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Sun, 06 May 2012 19:14:59 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/88#comment:2 Message-ID: <070.a64a44b40e6b8c9748cd7b59e581cd55@trac.tools.ietf.org> References: <055.6ee5f9af0660881f34d198ae081e0ce4@trac.tools.ietf.org> X-Trac-Ticket-ID: 88 In-Reply-To: <055.6ee5f9af0660881f34d198ae081e0ce4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #88: Data option and ULP X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 19:15:12 -0000 #88: Data option and ULP Comment (by mcr@…): The resolution in -10 is acceptable, but is not complete. "The other values are reserved at present." is not enough. We need an amending formula as part of the IANA instructions. I suggest Standards Action. http://tools.ietf.org/html/rfc5226 section 4.2 gives details. IANA also asks that you refer to the registry by URL that you want to allocate. -- -----------------------------------+---------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: closed Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Sun May 6 12:15:24 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7302E21F8565 for ; Sun, 6 May 2012 12:15:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.499 X-Spam-Level: X-Spam-Status: No, score=-102.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdst99uhbLOl for ; Sun, 6 May 2012 12:15:23 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 72A3621F8566 for ; Sun, 6 May 2012 12:15:23 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SR6vM-0006VG-47; Sun, 06 May 2012 15:15:16 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: mukul@UWM.EDU, jpv@cisco.com, mcr@sandelman.ca X-Trac-Project: roll Date: Sun, 06 May 2012 19:15:16 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/88#comment:3 Message-ID: <070.76061ec04643eb0eb89f13fa28a6f8ba@trac.tools.ietf.org> References: <055.6ee5f9af0660881f34d198ae081e0ce4@trac.tools.ietf.org> X-Trac-Ticket-ID: 88 In-Reply-To: <055.6ee5f9af0660881f34d198ae081e0ce4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mukul@UWM.EDU, jpv@cisco.com, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #88: Data option and ULP X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 19:15:25 -0000 #88: Data option and ULP Changes (by mcr@…): * status: closed => reopened * resolution: fixed => -- -----------------------------------+----------------------- Reporter: jpv@… | Owner: mukul@… Type: defect | Status: reopened Priority: major | Milestone: Component: p2p-rpl | Version: Severity: Submitted WG Document | Resolution: Keywords: | -----------------------------------+----------------------- Ticket URL: roll From mcr@sandelman.ca Sun May 6 12:18:14 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9517321F8550 for ; Sun, 6 May 2012 12:18:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.582 X-Spam-Level: X-Spam-Status: No, score=-1.582 tagged_above=-999 required=5 tests=[AWL=0.372, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IWEAtx4Mo3W for ; Sun, 6 May 2012 12:18:13 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id C1EA321F8549 for ; Sun, 6 May 2012 12:18:13 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 238498CA7; Sun, 6 May 2012 15:17:15 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 9984A98B98; Sun, 6 May 2012 15:18:10 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8911E98470; Sun, 6 May 2012 15:18:10 -0400 (EDT) From: Michael Richardson To: Mukul Goyal In-Reply-To: <394138592.277867.1336170368990.JavaMail.root@mail17.pantherlink.uwm.edu> References: <394138592.277867.1336170368990.JavaMail.root@mail17.pantherlink.uwm.edu> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 06 May 2012 15:18:10 -0400 Message-ID: <7457.1336331890@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 19:18:14 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mukul" =3D=3D Mukul Goyal writes: Mukul> This version takes care of all the tickets created for last Mukul> call comments.=20=20 Mukul> To see the text specific to a particular ticket "xx", search Mukul> for "\begin issue_xx" in:=20 Mukul> https://pantherfile.uwm.edu/mukul/public/files/draft-ietf-roll-p= 2p-rpl-10.txt=20 Thank you that was helpful. I reopened ticket #88. http://trac.tools.ietf.org/wg/roll/trac/ticket/88 The resolution in -10 is acceptable, but is not complete. "The other values are reserved at present." is not enough. We need an amending formula as part of the IANA instructions. I suggest Standards Action. http://tools.ietf.org/html/rfc5226 section 4.2 gives details. IANA also asks that you refer to the registry by URL that you want to allocate=20 for the other three code point allocations you have made. You can suggest values as you have, but they are supposed to be suggestions.. Also, you might want reserve 0xf as Private Use. =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) iQCVAwUAT6bOcoqHRg3pndX9AQL+ewQAqBXv9tibbdk0w3+O8vrP+GjXLsbyEbCU Bm+tVG7WhqA7YfpuKVUCr+DgncIYGM27L0IwOcygngK/esDaQDyI/Ezh33XHZWog aIpPn2y/Q0oPzvyBljyIeratie5UpGEvI3LH7B/ZEQuQRA3X9Jr0HYDuxtq1lCyD mc12IegDQTI= =biiA -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Sun May 6 12:28:24 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20BAD21F84E2 for ; Sun, 6 May 2012 12:28:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.706 X-Spam-Level: X-Spam-Status: No, score=-1.706 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id diFARVJ2QnMY for ; Sun, 6 May 2012 12:28:23 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8933B21F84D1 for ; Sun, 6 May 2012 12:28:23 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 02CD18CA7; Sun, 6 May 2012 15:27:27 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 88B4498B98; Sun, 6 May 2012 15:28:22 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 82AD898470; Sun, 6 May 2012 15:28:22 -0400 (EDT) From: Michael Richardson To: Roll@ietf.org In-Reply-To: <1354322643.282916.1336268038026.JavaMail.root@mail17.pantherlink.uwm.edu> References: <1354322643.282916.1336268038026.JavaMail.root@mail17.pantherlink.uwm.edu> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Sun, 06 May 2012 15:28:22 -0400 Message-ID: <9348.1336332502@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 May 2012 19:28:24 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable adrian> Could you enhance the text around the suggested defaults and adrian> the guidance to expand a little on what the problems might adrian> be, and encourage specific experimentation and reports back adrian> to the WG?=20 >>>>> "Mukul" =3D=3D Mukul Goyal writes: Mukul> Sure I will do that. I believe we are talking about section 6.1 and 9.2, correct? My suggestion is that the "controversial" values like this SHOULD be identified more clearly with text akin to: Specific consideration of this value MUST be addressed in applicability statement(s). (I'd even like to put some kind of 2119-like word in about this) =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) iQCVAwUAT6bQ1oqHRg3pndX9AQJyXAP/d+KxhhxaEov3NwrKel5CkPJb1bk6DkF3 ha+IVt4U5BebFH1h1aPdh4g8sFIRO2/nS7wxWtpaEPMWxFApyrgAJLr23nMoDmfD JIb2qmeXsWAUKHDvBurRk+ODmxBELGVEIKuPS2UpbaDYWpx9wbjHsHctNBba3qPS Ex14tzLRCSg= =TskG -----END PGP SIGNATURE----- --=-=-=-- From prvs=467a60657=mukul@uwm.edu Mon May 7 02:36:01 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2058421F844C for ; Mon, 7 May 2012 02:36:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GakKRxWG3kRK for ; Mon, 7 May 2012 02:36:00 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id B140621F851B for ; Mon, 7 May 2012 02:35:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAGKWp09/AAAB/2dsb2JhbABEhXKwFAEBBSNWDA8RBAEBAwINGQIeMwgGEwkQh3ULp3eERYRFiQmBL4lQJYRjgRgEhxOBUY0agRGLGYQYgwc Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id ECA1B12E3BB; Mon, 7 May 2012 04:35:58 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sp6w-jz-KIBy; Mon, 7 May 2012 04:35:58 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 486B712E3AD; Mon, 7 May 2012 04:35:58 -0500 (CDT) Date: Mon, 7 May 2012 04:35:58 -0500 (CDT) From: Mukul Goyal To: Michael Richardson Message-ID: <1160202689.290337.1336383358180.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <7457.1336331890@marajade.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 09:36:01 -0000 Hi Michael Does the following text meets your concerns? Thanks Mukul Section 7.2 (Data Option) "o Upper: A 4-bit field that identifies the upper layer protocol header with which the information in the Data field starts. A value 0x0 in this field identifies UDP as the upper layer protocol while the value 0xF is reserved for Private Use as defined in [RFC5226]. The other values are Unassigned [RFC5226] at present. " Section 14. IANA Considerations 14.1. Additions to Mode of Operation This document defines a new Mode of Operation, entitled "P2P Route Discovery Mode" (see Section 6), assigned a value of 4 from the "Mode of Operation" space [to be removed upon publication: http://www.iana.org/assignments/rpl/rpl.xml#mop] [RFC6550]. +-------+---------------------------------------+---------------+ | Value | Description | Reference | +-------+---------------------------------------+---------------+ | 4 | P2P Route Discovery Mode of Operation | This document | +-------+---------------------------------------+---------------+ Mode of Operation 14.2. Additions to RPL Control Message Options This document defines two new RPL options: o "P2P Route Discovery Option" (see Section 7.1), assigned a value of 0x0A from the "RPL Control Message Options" space [to be removed upon publication: http://www.iana.org/assignments/rpl/ rpl.xml#control-message-options] [RFC6550]. o "Data Option" (see Section 7.2), assigned a value of 0x0B from the "RPL Control Message Options" space [to be removed upon publication: http://www.iana.org/assignments/rpl/ rpl.xml#control-message-options] [RFC6550]. +-------+---------------------+---------------+ | Value | Meaning | Reference | +-------+---------------------+---------------+ | 0x0A | P2P Route Discovery | This document | | 0x0B | Data | This document | +-------+---------------------+---------------+ RPL Control Message Options 14.3. Additions to RPL Control Codes This document defines the following new RPL messages: o "Discovery Reply Object" (see Section 8), assigned a value of 0x04 from the "RPL Control Codes" space [to be removed upon publication: http://www.iana.org/assignments/rpl/rpl.xml#control-codes] [RFC6550]. o "Discovery Reply Object Acknowledgement" (see Section 10), assigned a value of 0x05 from the "RPL Control Codes" space [to be removed upon publication: http://www.iana.org/assignments/rpl/rpl.xml#control-codes] [RFC6550]. o "Secure Discovery Reply Object" (see Section 8.1), assigned a value of 0x84 from the "RPL Control Codes" space [to be removed upon publication: http://www.iana.org/assignments/rpl/rpl.xml#control-codes] [RFC6550]. o "Secure Discovery Reply Object Acknowledgement" (see Section 10), assigned a value of 0x85 from the "RPL Control Codes" space [to be removed upon publication: http://www.iana.org/assignments/rpl/rpl.xml#control-codes] [RFC6550]. +------+--------------------------------------------+---------------+ | Code | Description | Reference | +------+--------------------------------------------+---------------+ | 0x04 | Discovery Reply Object | This document | | 0x05 | Discovery Reply Object Acknowledgement | This document | | 0x84 | Secure Discovery Reply Object | This document | | 0x85 | Secure Discovery Reply Object | This document | | | Acknowledgement | | +------+--------------------------------------------+---------------+ RPL Control Codes 14.4. New Registry for Upper Layer Headers inside Data Option The Data Option (see Section 7.2) defines a 4-bit "Upper" field, for which IANA is requested to create and maintain a new registry titled "Upper Layer Header Type Inside RPL Data Option". New codes may be allocated in this registry only by an IETF Review [RFC5226]. Each code is tracked with the following characteristics: o Value o Description o Reference The following codes are currently defined: +---------+-------------+---------------+ | Value | Description | Reference | +---------+-------------+---------------+ | 0x0 | UDP Header | This document | | 0x1-0xE | Unassigned | | | 0xF | Private Use | This document | +---------+-------------+---------------+ Upper Layer Header Types Inside RPL Data Option ----- Original Message ----- From: "Michael Richardson" To: "Mukul Goyal" Cc: roll@ietf.org Sent: Sunday, May 6, 2012 2:18:10 PM Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10.txt >>>>> "Mukul" == Mukul Goyal writes: Mukul> This version takes care of all the tickets created for last Mukul> call comments. Mukul> To see the text specific to a particular ticket "xx", search Mukul> for "\begin issue_xx" in: Mukul> https://pantherfile.uwm.edu/mukul/public/files/draft-ietf-roll-p2p-rpl-10.txt Thank you that was helpful. I reopened ticket #88. http://trac.tools.ietf.org/wg/roll/trac/ticket/88 The resolution in -10 is acceptable, but is not complete. "The other values are reserved at present." is not enough. We need an amending formula as part of the IANA instructions. I suggest Standards Action. http://tools.ietf.org/html/rfc5226 section 4.2 gives details. IANA also asks that you refer to the registry by URL that you want to allocate for the other three code point allocations you have made. You can suggest values as you have, but they are supposed to be suggestions.. Also, you might want reserve 0xf as Private Use. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From prvs=467a60657=mukul@uwm.edu Mon May 7 02:50:39 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B075E21F8568 for ; Mon, 7 May 2012 02:50:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.491 X-Spam-Level: X-Spam-Status: No, score=-6.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z6wEIEVanzaV for ; Mon, 7 May 2012 02:50:38 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id AA74821F8547 for ; Mon, 7 May 2012 02:50:38 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAHWap09/AAAB/2dsb2JhbABEhXKwFwEBBSNWDA8RBAEBAwINGQIeMwgGExmHdQunfoRFhEeJCYEviVCFCIEYBIcTgVGNGowqhBiDBw Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id E0DD72B3F0B; Mon, 7 May 2012 04:50:37 -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 7+E2npP8QoIZ; Mon, 7 May 2012 04:50:37 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 8C0962B3F05; Mon, 7 May 2012 04:50:37 -0500 (CDT) Date: Mon, 7 May 2012 04:50:37 -0500 (CDT) From: Mukul Goyal To: Michael Richardson Message-ID: <1870717185.290349.1336384237471.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <9348.1336332502@marajade.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: Roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 09:50:39 -0000 Hi Michael >My suggestion is that the "controversial" values like this SHOULD be identified more clearly with text akin to: >Specific consideration of this value MUST be addressed in applicability statement(s). >(I'd even like to put some kind of 2119-like word in about this) You mean to say that P2P-RPL draft should require the home/building/whomsoever_cares_to_use_p2p_rpl applicability statement to address how to set P2P-RPL trickle parameters? Thanks Mukul ----- Original Message ----- From: "Michael Richardson" To: Roll@ietf.org Cc: adrian@olddog.co.uk, "Mukul Goyal" Sent: Sunday, May 6, 2012 2:28:22 PM Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments adrian> Could you enhance the text around the suggested defaults and adrian> the guidance to expand a little on what the problems might adrian> be, and encourage specific experimentation and reports back adrian> to the WG? >>>>> "Mukul" == Mukul Goyal writes: Mukul> Sure I will do that. I believe we are talking about section 6.1 and 9.2, correct? My suggestion is that the "controversial" values like this SHOULD be identified more clearly with text akin to: Specific consideration of this value MUST be addressed in applicability statement(s). (I'd even like to put some kind of 2119-like word in about this) -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From pthubert@cisco.com Mon May 7 06:00:41 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3CEE21F85C5 for ; Mon, 7 May 2012 06:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.196 X-Spam-Level: X-Spam-Status: No, score=-10.196 tagged_above=-999 required=5 tests=[AWL=0.403, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AOY0KiOQe0KA for ; Mon, 7 May 2012 06:00:40 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 3F42821F85C4 for ; Mon, 7 May 2012 06:00:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=8100; q=dns/txt; s=iport; t=1336395640; x=1337605240; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to; bh=GLIk1WqRUNszXxXk0dNwAixNqzkJYyVI74uuFCmGOM0=; b=kFcWSIHL7EzRU4/WOQF91WJaVT2V5+gH5EQ1LwWc5EWQkTjU4gXp7/Vd hOPaZCQHSM+mVd1uaedfzsF99Efr1hU46OhAMzP2zpoHFGhEA5boo3aME mmTgzmqXAudiwk+85pq+1kuMucBm/N+EvcAygt5OVAlgWsvPowwhVYazR U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAK3Gp0+Q/khR/2dsb2JhbABEhXKsE4ETgQeCDAEBAQMBEgEQDQRKCwIBCBoCBgYYAgICAQFVAQEEARoRCYdnBZsYjRaSK4EviVUXhGw1YwSkV4Fpgms X-IronPort-AV: E=Sophos;i="4.75,543,1330905600"; d="scan'208";a="137223819" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-1.cisco.com with ESMTP; 07 May 2012 13:00:39 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q47D0dMV006660; Mon, 7 May 2012 13:00:39 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 7 May 2012 15:00:38 +0200 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, 7 May 2012 14:59:08 +0200 Message-ID: In-Reply-To: <4FA3C476.5000903@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-thubert-roll-flow-label-00.txt Thread-Index: Ac0p7UzGKVwBLef2ShmrzvRtHI8k9gCXt24w References: <20120504080338.24030.4170.idtracker@ietfa.amsl.com> <4FA3C476.5000903@gmail.com> From: "Pascal Thubert (pthubert)" To: "Brian E Carpenter" , X-OriginalArrivalTime: 07 May 2012 13:00:38.0868 (UTC) FILETIME=[6695D140:01CD2C51] Subject: Re: [Roll] I-D Action: draft-thubert-roll-flow-label-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 13:00:41 -0000 SGkgQnJpYW46DQoNCj4gSU1ITyB0aGVyZSBhcmUgcHJvYmxlbXMgd2l0aCB0aGlzIHByb3Bvc2Fs Lg0KID5PbmUgaXMgdGhhdCBpdCBkb2Vzbid0LCBhcyBmYXIgYXMgSSBjYW4gc2VlLCBkZW1vbnN0 cmF0ZSB0aGF0IHRoZSBvdmVyaGVhZCBvZiByZXdyaXRpbmcgdGhlIGZsb3cgbGFiZWwgb24gZXhp dCBmcm9tIGFuIFJQTCBkb21haW4gaXMgc2lnbmlmaWNhbnRseSBsZXNzIHRoYW4gdGhlIG92ZXJo ZWFkIG9mIGRlYWxpbmcgd2l0aCB0aGUgUlBMIGhvcC1ieS1ob3Agb3B0aW9uIGF0IHRoZSBlZGdl IG9mIHRoZSBkb21haW4uDQoNCltQYXNjYWxdIFRoZSBvdmVyaGVhZCBpcyBtYWlubHkgZm9yIHBh Y2tldHMgY29taW5nIGZyb20gdGhlIG91dHNpZGUgaW50byB0aGUgUlBMIGRvbWFpbi4gU3VjaCBw YWNrZXRzIG5lZWQgZXh0cmEgZW5jYXBzdWxhdGlvbiB0aGF0J3MgZGV0cmltZW50YWwgZm9yIGJh dHRlcmllcyBhbmQgbWF5IGNhdXNlIGEgc21hbGwgcGFja2V0IHRvIGdyb3cgYWJvdmUgdGhlIE1B QyBNYXggRnJhbWUsIGxlYWRpbmcgdG8gTDIgb3IgNkxvV1BBTiBmcmFnbWVudGF0aW9uLg0KDQpU aGVuLCB0aGlzIHBocmFzZToNCg0KPiAgICBTYWRseSwgdGhlIE9wdGlvbiBtdXN0IGJlIHBsYWNl ZCBpbg0KPiAgICBhIEhvcC1ieS1Ib3Agb3B0aW9uIHRoYXQgbXVzdCBiZSBpbnNlcnRlZCBvciBy ZW1vdmVkIGFzIHRoZSBwYWNrZXQNCj4gICAgY3Jvc3NlcyB0aGUgYm9yZGVyIG9mIHRoZSBSUEwg ZG9tYWluLiANCg0KYm90aGVycyBtZSwgYmVjYXVzZSAoYW5kIEkgaGF2ZSBsb29rZWQgcmVjZW50 bHkpIHRoZXJlIGlzIG5vdGhpbmcgaW4gdGhlIElQdjYgc3BlY3MgdGhhdCBhbGxvd3MgZm9yIGFu IGV4dGVuc2lvbiBoZWFkZXIgYmVpbmcgaW5zZXJ0ZWQgKG9yIHJlbW92ZWQpIGVuIHJvdXRlLiBU aGUgdGV4dCBjb250aW51ZXMNCg0KW1Bhc2NhbF0gSSdsbCByZXdvcmQgdG8gaW5kaWNhdGUgdGhh dCB0aGUgb3BlcmF0aW9uIG9mIGluc2VydGluZyAvIHJlbW92aW5nIHRoZSBIYkggaGVhZGVyIGNv bWVzIHdpdGggNmluNi4NCiBSRkMgNjU1MyBzYXlzOiANCiINCiAgIFdoZW4gdGhlIHJvdXRlciBp cyB0aGUgc291cmNlIG9mIHRoZSBvcmlnaW5hbCBwYWNrZXQgYW5kIHRoZQ0KICAgZGVzdGluYXRp b24gaXMga25vd24gdG8gYmUgd2l0aGluIHRoZSBzYW1lIFJQTCBJbnN0YW5jZSwgdGhlIHJvdXRl cg0KICAgU0hPVUxEIGluY2x1ZGUgdGhlIFJQTCBPcHRpb24gZGlyZWN0bHkgd2l0aGluIHRoZSBv cmlnaW5hbCBwYWNrZXQuDQogICBPdGhlcndpc2UsIHJvdXRlcnMgTVVTVCB1c2UgSVB2Ni1pbi1J UHY2IHR1bm5lbGluZyBbUkZDMjQ3M10gYW5kDQogICBwbGFjZSB0aGUgUlBMIE9wdGlvbiBpbiB0 aGUgdHVubmVsIGhlYWRlci4gIFVzaW5nIElQdjYtaW4tSVB2Ng0KICAgdHVubmVsaW5nIGVuc3Vy ZXMgdGhhdCB0aGUgZGVsaXZlcmVkIGRhdGFncmFtIHJlbWFpbnMgdW5tb2RpZmllZCBhbmQNCiAg IHRoYXQgSUNNUHY2IGVycm9ycyBnZW5lcmF0ZWQgYnkgYSBSUEwgT3B0aW9uIGFyZSBzZW50IGJh Y2sgdG8gdGhlDQogICByb3V0ZXIgdGhhdCBnZW5lcmF0ZWQgdGhlIFJQTCBPcHRpb24uIg0KDQo+ ICAgIC4uLlRoaXMgb3BlcmF0aW9uIG1heSBpbnZvbHZlIGFuDQo+ICAgIGV4dHJhIGVuY2Fwc3Vs YXRpb24gdGhhdCBpcyBkZXRyaW1lbnRhbCB0byB0aGUgbmV0d29yayBvcGVyYXRpb24sIGluDQo+ ICAgIHBhcnRpY3VsYXIgd2l0aCByZWdhcmRzIHRvIGJhbmR3aWR0aCBhbmQgYmF0dGVyeSBjb25z dHJhaW50cy4NCg0KV2h5ICJtYXkiPyBJZiB0aGUgcGFja2V0IGlzIGluYm91bmQgdG8gUlBMLCBS RkMgNjU1MyBtYWtlcyBpdCBjbGVhciB0aGF0IGl0IG11c3QgYmUgZW5jYXBzdWxhdGVkOyBpZiB0 aGUgcGFja2V0IGlzIG91dGJvdW5kLCB3aHkgd291bGQgaXQgYmUgZW5jYXBzdWxhdGVkIGF0IGFs bD8gVGhpcyBjYXNlIGlzIGNvdmVyZWQgaW4gdGhlIFJGQyB0b286DQoNCltQYXNjYWxdIEkgd3Jv dGUgIm1heSIgZnJvbSB0aGUgZmFjdCB0aGF0IHRoZSBwYWNrZXQgbWF5IGJlIGlzc3VlZCBhbmQg Y29uc3VtZWQgd2l0aGluIHRoZSBSUEwgZG9tYWluIGluIHdoaWNoIGNhc2UgdGhlIG9wdGlvbiBp cyBjb25zZXJ2ZWQgYWxsIHRoZSB3YXkgYW5kIHRoZXJlIGlzIG5vIDZpbjYgZW5jYXBzdWxhdGlv bi4NCkJ1dCBJIGFncmVlIHRoZSBvcGVyYXRpb24gYWJvdmUgZG9lcyBjb21lIHdpdGggNmluNi4N CiANCj4gICAgMy4gIERhdGFncmFtcyBkZXN0aW5lZCB0byBub2RlcyBvdXRzaWRlIHRoZSBSUEwg SW5zdGFuY2UgYXJlIGRyb3BwZWQNCj4gICAgICAgIGlmIHRoZSBvdXRlcm1vc3QgSVB2NiBoZWFk ZXIgY29udGFpbnMgYSBSUEwgT3B0aW9uIG5vdCBnZW5lcmF0ZWQNCj4gICAgICAgIGJ5IHRoZSBS UEwgcm91dGVyIGZvcndhcmRpbmcgdGhlIGRhdGFncmFtLg0KDQpUaGVuLCB0aGUgZHJhZnQgc2F5 czoNCg0KPiAgICBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBob3cgdGhlIEZsb3cgTGFiZWwgY2Fu IGJlIHJldXNlZCB3aXRoaW4gdGhlDQo+ICAgIFJQTCBkb21haW4gYXMgYSByZXBsYWNlbWVudCB0 byB0aGUgUlBMIG9wdGlvbi4gIFRoZSB1c2Ugb2YgdGhlIEZsb3cNCj4gICAgTGFiZWwgd2l0aGlu IGEgUlBMIGRvbWFpbiBpcyBhbiBpbnN0YW5jZSBvZiB0aGUgc3RhdGVmdWwgc2NlbmFyaW9zDQo+ ICAgIGRlY3JpYmVkIGluIFtSRkM2NDM3XS4uLg0KDQpJbiBmYWN0IFJGQyA2NDM3IGNhcmVmdWxs eSBzYXlzIHZlcnkgbGl0dGxlIGFib3V0IHN0YXRlZnVsIHNjZW5hcmlvczsgaXQgZG9lcyBub3Qg ZGVzY3JpYmUgdGhlbSwgYnV0IGl0IGRvZXMgY29uc3RyYWluIHRoZW0uIEhlcmUgaXMgdGhlIGVu dGlyZSBzZWN0aW9uIG9uIHRoaXMgdG9waWM6DQoNCltQYXNjYWxdIHdoYXQgYWJvdXQgdGhlIHdv cmQgImludHJvZHVjZWQiLCBvciAiZGlzY3Vzc2VkIj8NCg0KPiA0LiAgRmxvdyBTdGF0ZSBFc3Rh Ymxpc2htZW50IFJlcXVpcmVtZW50cw0KPiANCj4gICAgQSBub2RlIHRoYXQgc2V0cyB0aGUgZmxv dyBsYWJlbCBNQVkgYWxzbyB0YWtlIHBhcnQgaW4gYSBmbG93IHN0YXRlDQo+ICAgIGVzdGFibGlz aG1lbnQgbWV0aG9kIHRoYXQgcmVzdWx0cyBpbiBhc3NpZ25pbmcgc3BlY2lmaWMgdHJlYXRtZW50 cyB0bw0KPiAgICBzcGVjaWZpYyBmbG93cywgcG9zc2libHkgaW5jbHVkaW5nIHNpZ25hbGluZy4g IEFueSBzdWNoIG1ldGhvZCBNVVNUDQo+ICAgIE5PVCBkaXN0dXJiIG5vZGVzIHRha2luZyBwYXJ0 IGluIHRoZSBzdGF0ZWxlc3Mgc2NlbmFyaW8ganVzdA0KPiAgICBkZXNjcmliZWQuICBUaHVzLCBh bnkgbm9kZSB0aGF0IHNldHMgZmxvdyBsYWJlbCB2YWx1ZXMgYWNjb3JkaW5nIHRvIGENCj4gICAg c3RhdGVmdWwgc2NoZW1lIE1VU1QgY2hvb3NlIGxhYmVscyB0aGF0IGNvbmZvcm0gdG8gU2VjdGlv biAzIG9mIHRoaXMNCj4gICAgc3BlY2lmaWNhdGlvbi4gIEZ1cnRoZXIgZGV0YWlscyBhcmUgbm90 IGRpc2N1c3NlZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQo+VGhlIHByb2JsZW0gaXMgdGhhdCBzZWN0 aW9uIDMgaW50ZW50aW9uYWxseSBkb2VzIG5vdCBjb25zaWRlciBmbG93IGxhYmVsIHZhbHVlcyBp biB3aGljaCBhbnkgb2YgdGhlIGJpdHMgaGF2ZSBzZW1hbnRpYyBzaWduaWZpY2FuY2UsIGFuZCB0 aGlzIHdhcyB0aGUgY29uc2Vuc3VzIGluIHRoZSA2TUFOIFdHIGFmdGVyIGEgZ3JlYXQgZGVhbCBv ZiBkaXNjdXNzaW9uLiBIb3dldmVyLCB0aGUgIHByZXNlbnQgcHJvcG9zYWwgYXNzaWducyBzZW1h bnRpY3MgdG8gdmFyaW91cyBiaXRzIGluIHRoZSBmbG93IGxhYmVsLCBkZXN0cm95aW5nIGl0cyBk ZXNpcmVkIHByb3BlcnR5IG9mIGJlbG9uZ2luZyB0byBhIHN0YXRpc3RpY2FsbHkgdW5pZm9ybSBk aXN0cmlidXRpb24uDQoNCltQYXNjYWxdIFRoYXQgaXMgdHJ1ZSB3aXRoaW4gdGhlIGVkZ2UgbmV0 d29yayB0aGF0IGlzIHRoZSBSUEwgZG9tYWluLiBCdXQgb3V0c2lkZSB0aGUgUlBMIGRvbWFpbiB0 aGUgZGVzaXJlZCBwcm9wZXJ0aWVzIGFyZSBjb25zZXJ2ZWQuIFRoZSByYXRpb25hbGUgZm9yIHRo ZSBzdGF0aXN0aWNhbGx5IHVuaWZvcm0gZGlzdHJpYnV0aW9uIGRvZXMgbm90IG5lY2Vzc2FyaWx5 IGJyaW5nIGEgbG90IG9mIHZhbHVlIHdpdGhpbiB0aGUgTExOLiBPbiB0aGUgb3RoZXIgaGFuZCwg dGhlIDZpbjYgZW5jYXBzIGFuZCBIYkggaGVhZGVyIGFyZSBodWdlbHkgZGV0cmltZW50YWwgdG8g dGhlIG9wZXJhdGlvbnMgYW5kIHdpbGwgcmVzdWx0IGlzIHNob3J0ZXIgYmF0dGVyeSBsaWZlIGFu ZCByZWR1Y2VkIGFwcGxpY2FiaWxpdHkuIEkgcGFydGljaXBhdGVkIGFzIGEgY29lZGl0b3IgdG8g dGhlIElTQTEwMC4xMWEgc3RhbmRhcmQgdGhhdCBhY3R1YWxseSB1c2VzIElQdjYgaW4gdGhlIDZM b1dQQU4gSEMgZm9ybS4gSSd2ZSBzZWVuIGhvdyB0aGUgYWRvcHRpb24gb2YgSVB2NiB3YXMgYXQg c3Rha2UgZm9yIGEgc2luZ2xlIGFkZGl0aW9uYWwgb2N0ZXQgaW4gYSBoZWFkZXIsIGFuZCB0aGlz IGFjdHVhbGx5IGxlZCB0byBjaGFuZ2VzIGF0IHRoZSBJRVRGIGFuZCB0aGUgbmV3IDZMb1dQQU4g SEMuIEluZGVlZCwgdW5sZXNzIHlvdSBoYXZlIGEgcG93ZXIgc291cmNlLCBldmVyeSBvY3RldCB0 aGF0IHlvdSBoYXZlIHRvIHBsYWNlIGl0IGluIGV2ZXJ5IGZyYW1lIG9yIHBhY2tldCBpbiB0aGUg TExOIGNvdW50cyBkZWFybHkuDQoNCj5UaGUgaXNzdWUgaXMgY2xlYXJseSBzdGF0ZWQgaW4gUkZD IDY0Mzc6DQoNCj4gICAgT25jZSBzZXQgdG8gYSBub24temVybyB2YWx1ZSwgdGhlIEZsb3cgTGFi ZWwgaXMgZXhwZWN0ZWQgdG8gYmUNCj4gICAgZGVsaXZlcmVkIHVuY2hhbmdlZCB0byB0aGUgZGVz dGluYXRpb24gbm9kZShzKS4gIEEgZm9yd2FyZGluZyBub2RlDQo+ICAgIE1VU1QgZWl0aGVyIGxl YXZlIGEgbm9uLXplcm8gZmxvdyBsYWJlbCB2YWx1ZSB1bmNoYW5nZWQgb3IgY2hhbmdlIGl0DQo+ ICAgIG9ubHkgZm9yIGNvbXBlbGxpbmcgb3BlcmF0aW9uYWwgc2VjdXJpdHkgcmVhc29ucyBhcyBk ZXNjcmliZWQgaW4NCj4gICAgU2VjdGlvbiA2LjEuDQoNCltQYXNjYWxdICBXZSBoYXZlIGEgY29t cGVsbGluZyBvcGVyYXRpb25hbCByZWFzb24gZm9yIHN1cmUsIGJlY2F1c2UgdGhlIHBvd2VyIGNv bnN1bXB0aW9uIGlzIHRoZSBudW1iZXIgb25lIGNyaXRpY2FsIGNvbnN0cmFpbnQgdGhhdCBkcml2 ZXMgbW9zdCBvZiB0aGUgcGh5c2ljYWwgZGVzaWduIGNob2ljZXMgaW4gYSBMTE4gd2hlcmUgYSBi YXR0ZXJ5IGxpZmUgbXVzdCBvZnRlbiBleHByZXNzZWQgaW4geWVhcnMuICBJJ20gdW5jbGVhciwg dGhvdWdoLCB3aHkgUkZDIDY0Mzcgd2VudCBhcyBmYXIgYXMgaW5kaWNhdGluZyB0aGF0IHRoZSBj b21wZWxsaW5nIHJlYXNvbiBzaG91bGQgYmUgcXVhbGlmaWVkIGFzIHNlY3VyaXR5LiBJIHRha2Ug dGhhdCBhcyBhbiBpbmRpY2F0aW9uIG9mIGNyaXRpY2FsaXR5IGFzIG9wcG9zZWQgdG8gYSB0ZW50 YXRpdmUgdG8gcHJlZGljdCBmdXR1cmUgbmVlZHMuIEl0IG1ha2VzIHNlbnNlIHRvIG1lIHRvIGFk ZCBpbiB0aGUgZHJhZnQgdGhhdCAidGhlIHNvdXJjZSBpbiB0aGUgTExOIFNIT1VMRCBzZXQgdGhl IEZsb3cgbGFiZWwgdG8gemVybyBhbmQgTVVTVCBOT1QgZXhwZWN0IHRoYXQgdGhlIGZsb3cgbGFi ZWwgd2lsbCBiZSBjb25zZXJ2ZWQgZW5kIHRvIGVuZCBpZiBpdCBrbm93cyBieSBwb2xpY3kgdGhh dCB0aGUgTExOIHdpbGwgdXNlIHRoaXMgZHJhZnQiLiBXb3VsZCB0aGF0IGJlIHN1ZmZpY2llbnQg dG8gYWxsZXZpYXRlIHRoaXMgY29uY2Vybj8NCg0KQW5kIHllcywgSSB3aWxsIGNlcnRhaW5seSBr ZWVwIHlvdSBDQ2VkLCBhbmQgQ0MgeW91IGlmIG90aGVyIHRocmVhZHMgcG9wIHVwIG9uIHRoZSBz dWJqZWN0IGluIFJPTEwsIGlmIHlvdSBkbyBub3QgbWluZDsNCg0KUGFzY2FsDQo= From mcr@sandelman.ca Mon May 7 06:40:42 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C840721F864A for ; Mon, 7 May 2012 06:40:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.434 X-Spam-Level: X-Spam-Status: No, score=-1.434 tagged_above=-999 required=5 tests=[AWL=0.520, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zOppvMuQ0sK3 for ; Mon, 7 May 2012 06:40:39 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9EF21F8649 for ; Mon, 7 May 2012 06:40:37 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id A51DA82C7; Mon, 7 May 2012 09:39:38 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F169498B98; Mon, 7 May 2012 09:40:35 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id EDEC898141; Mon, 7 May 2012 09:40:35 -0400 (EDT) From: Michael Richardson To: Mukul Goyal In-Reply-To: <1160202689.290337.1336383358180.JavaMail.root@mail17.pantherlink.uwm.edu> References: <1160202689.290337.1336383358180.JavaMail.root@mail17.pantherlink.uwm.edu> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 07 May 2012 09:40:35 -0400 Message-ID: <16708.1336398035@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 13:40:42 -0000 <#part sign=pgpmime> >>>>> "Mukul" == Mukul Goyal writes: Mukul> Does the following text meets your concerns? Mukul> The Data Option (see Section 7.2) defines a 4-bit "Upper" field, for Mukul> which IANA is requested to create and maintain a new registry titled Mukul> "Upper Layer Header Type Inside RPL Data Option". New codes may be Mukul> allocated in this registry only by an IETF Review [RFC5226]. Each Mukul> code is tracked with the following characteristics: I had suggested "standards action", but IETF Review is as strong or stronger. So I'm happy. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From mcr@sandelman.ca Mon May 7 06:48:16 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9639921F863C for ; Mon, 7 May 2012 06:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.456 X-Spam-Level: X-Spam-Status: No, score=-1.456 tagged_above=-999 required=5 tests=[AWL=0.368, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qvZA5a7jKgE2 for ; Mon, 7 May 2012 06:48:16 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 2217D21F8637 for ; Mon, 7 May 2012 06:48:16 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id BCB4F82C7; Mon, 7 May 2012 09:47:17 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 0CB1E98B98; Mon, 7 May 2012 09:48:15 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0974C98141; Mon, 7 May 2012 09:48:15 -0400 (EDT) From: Michael Richardson To: Roll@ietf.org In-Reply-To: <1870717185.290349.1336384237471.JavaMail.root@mail17.pantherlink.uwm.edu> References: <1870717185.290349.1336384237471.JavaMail.root@mail17.pantherlink.uwm.edu> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 07 May 2012 09:48:14 -0400 Message-ID: <18140.1336398494@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 13:48:16 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Mukul" == Mukul Goyal writes: Mukul> Hi Michael >> My suggestion is that the "controversial" values like this SHOULD be Mukul> identified more clearly with text akin to: >> Specific consideration of this value MUST be addressed Mukul> in applicability statement(s). >> (I'd even like to put some kind of 2119-like word in about this) Mukul> You mean to say that P2P-RPL draft should require the Mukul> home/building/whomsoever_cares_to_use_p2p_rpl applicability Mukul> statement to address how to set P2P-RPL trickle parameters? Yes, exactly. There could be a template in the document which must be filled in. Text something like: Applicability Statements that specify P2P-RPL MUST provide values for the following parameters: X, Y, Z. Considerations for setting X. Considerations for setting Y. Considerations for setting Z. For example: The FOOBAR application scenario is a dense mesh needing fast repair times and having routing nodes without power limits. Therefore: 1) the X value SHOULD be set between a and b. 2) the Y value SHOULD be no greater than c. 3) the Z value setting is not critical. - -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Finger me for keys iQEVAwUBT6fSlICLcPvd0N1lAQIfpQgAwBVrjzOdOeVUOOzksTatl9aERaIkYpkj Dj0hEYoogjZE/jQIKG1GCJtoYLuYiQ1Lv4/dtwsnap3KUrymkDk1UdPjfbcKm8oc chHdf4Kg+MUYO7GYeOjlAOqJ/WID9mV/9cVVB71mr+33b2vmhMcnaS6Pv+spgtOS WTDusylkJC6nz2O+DAhjHFT9lzQGvJxfKDs/eXxU8RQK44XHymU7ZmlAV37AeZQB R3kZtFu3v9DC/0ILHz3P6go/iO/n5phd3GUeEMNJjFrrTnyqzIrU0wvwTQ4gaVnG L40iWlpTHxNoLwRMcvPopWVIVfzGbO7bXzcT8je/mccWaDyaPj5gLw== =mNPX -----END PGP SIGNATURE----- From prvs=467a60657=mukul@uwm.edu Mon May 7 07:13:53 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB63C21F85AD for ; Mon, 7 May 2012 07:13:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.501 X-Spam-Level: X-Spam-Status: No, score=-6.501 tagged_above=-999 required=5 tests=[AWL=0.098, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QncA-4ZE5J61 for ; Mon, 7 May 2012 07:13:52 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 2899921F85A3 for ; Mon, 7 May 2012 07:13:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAF7Xp09/AAAB/2dsb2JhbABEhXKwOQEBBSNWDA8RBAEBAwINGQJRCAYTiA4LqDWJLYkJgS+JUIUIgRgEiGSNGoERjzGDBw Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 804612B3F0D; Mon, 7 May 2012 09:13:48 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YRPtcaR7dSw; Mon, 7 May 2012 09:13:48 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 36ABA2B3F0C; Mon, 7 May 2012 09:13:48 -0500 (CDT) Date: Mon, 7 May 2012 09:13:48 -0500 (CDT) From: Mukul Goyal To: Michael Richardson Message-ID: <1881816876.292488.1336400028170.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <16708.1336398035@marajade.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 14:13:53 -0000 >I had suggested "standards action", but IETF Review is as strong or stronger. So I'm happy. I did not want to allow only standards track documents to allocate a code. Thanks Mukul ----- Original Message ----- From: "Michael Richardson" To: "Mukul Goyal" Cc: roll@ietf.org Sent: Monday, May 7, 2012 8:40:35 AM Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10.txt <#part sign=pgpmime> >>>>> "Mukul" == Mukul Goyal writes: Mukul> Does the following text meets your concerns? Mukul> The Data Option (see Section 7.2) defines a 4-bit "Upper" field, for Mukul> which IANA is requested to create and maintain a new registry titled Mukul> "Upper Layer Header Type Inside RPL Data Option". New codes may be Mukul> allocated in this registry only by an IETF Review [RFC5226]. Each Mukul> code is tracked with the following characteristics: I had suggested "standards action", but IETF Review is as strong or stronger. So I'm happy. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From mcr@sandelman.ca Mon May 7 07:30:33 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA15E21F85C4 for ; Mon, 7 May 2012 07:30:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.574 X-Spam-Level: X-Spam-Status: No, score=-1.574 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NjgyVFfUY8W1 for ; Mon, 7 May 2012 07:30:33 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 59A9F21F85BB for ; Mon, 7 May 2012 07:30:32 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 972A982C7; Mon, 7 May 2012 10:29:33 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id F05C298B98; Mon, 7 May 2012 10:30:30 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id E563F98141; Mon, 7 May 2012 10:30:30 -0400 (EDT) From: Michael Richardson To: Mukul Goyal In-Reply-To: <1881816876.292488.1336400028170.JavaMail.root@mail17.pantherlink.uwm.edu> References: <1881816876.292488.1336400028170.JavaMail.root@mail17.pantherlink.uwm.edu> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Mon, 07 May 2012 10:30:30 -0400 Message-ID: <26312.1336401030@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 May 2012 14:30:34 -0000 >>>>> "Mukul" == Mukul Goyal writes: >> I had suggested "standards action", but IETF Review is as strong >> or Mukul> stronger. So I'm happy. Mukul> I did not want to allow only standards track documents to Mukul> allocate a code. Standards Track documents could in theory be individual submissions, going straight to the RFC-EDITOR (IMAP was done this way), but in practice they wind up being reviewed by the IESG anyway. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From brian.e.carpenter@gmail.com Tue May 8 02:52:55 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC8E921F85AC for ; Tue, 8 May 2012 02:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RXxs5Jk0A8FO for ; Tue, 8 May 2012 02:52:55 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id AF92D21F858E for ; Tue, 8 May 2012 02:52:54 -0700 (PDT) Received: by eabd1 with SMTP id d1so1285018eab.31 for ; Tue, 08 May 2012 02:52:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=D3bi+yqp1x5zwx3aI+NEYaICGayjPWrmTe560THe2Gw=; b=ThzzaWARFEjMcI70yNiP+ZZDr8JMEadqOlM73XhZINBuSRHXdGu6Y3xzBNhisu+KjR Zh36Ye9H5W5jpBbQUuKA2z5hQecWBnkwob3DCCyLKdn81gnO4+RWHLCVFHs/agaPX0Bq w5rDp0fdBYONvDsA6ZaSV/qs3V7gINRKnI3cwuMxF9NZ8tbrtSRPOLvvmSIp7XPhICXj kDVFVZZlOuyyxPgqH8EYddTNG+GmEkT+juNx5PduuYXMdDjH2WcgJ0Be886GKyFlW02c Omg+3regmJ4qDV4RFPujMPCPW587JZyxwuAjqJL9MF4/Iibmr4Swf/tWvZzKtm/qjVtL 1idw== Received: by 10.213.3.215 with SMTP id 23mr3348493ebo.36.1336470773094; Tue, 08 May 2012 02:52:53 -0700 (PDT) Received: from [128.232.110.88] (c088.al.cl.cam.ac.uk. [128.232.110.88]) by mx.google.com with ESMTPS id n52sm92893154eef.6.2012.05.08.02.52.51 (version=SSLv3 cipher=OTHER); Tue, 08 May 2012 02:52:52 -0700 (PDT) Message-ID: <4FA8ECF0.7070200@gmail.com> Date: Tue, 08 May 2012 10:52:48 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <20120504080338.24030.4170.idtracker@ietfa.amsl.com> <4FA3C476.5000903@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-thubert-roll-flow-label-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 09:52:56 -0000 On 2012-05-07 13:59, Pascal Thubert (pthubert) wrote: > Hi Brian: > >> IMHO there are problems with this proposal. One is that it doesn't, >> as far as I can see, demonstrate that the overhead of rewriting the >> flow label on exit from an RPL domain is significantly less than >> the overhead of dealing with the RPL hop-by-hop option at the edge >> of the domain. > > [Pascal] The overhead is mainly for packets coming from the outside > into the RPL domain. Such packets need extra encapsulation that's > detrimental for batteries and may cause a small packet to grow above > the MAC Max Frame, leading to L2 or 6LoWPAN fragmentation. If you can explain this in a few words in the text, it will be fine. > > Then, this phrase: > >> Sadly, the Option must be placed in a Hop-by-Hop option that must >> be inserted or removed as the packet crosses the border of the RPL >> domain. > > bothers me, because (and I have looked recently) there is nothing in > the IPv6 specs that allows for an extension header being inserted (or > removed) en route. The text continues > > [Pascal] I'll reword to indicate that the operation of inserting / > removing the HbH header comes with 6in6. RFC 6553 says: " When the > router is the source of the original packet and the destination is > known to be within the same RPL Instance, the router SHOULD include > the RPL Option directly within the original packet. Otherwise, > routers MUST use IPv6-in-IPv6 tunneling [RFC2473] and place the RPL > Option in the tunnel header. Using IPv6-in-IPv6 tunneling ensures > that the delivered datagram remains unmodified and that ICMPv6 errors > generated by a RPL Option are sent back to the router that generated > the RPL Option." Yes, I had to read quite deeply into 6553 to understand this. I think your draft will be read by people without detailed knowledge of RPL so it needs to be explained. > >> ...This operation may involve an extra encapsulation that is >> detrimental to the network operation, in particular with regards to >> bandwidth and battery constraints. > > Why "may"? If the packet is inbound to RPL, RFC 6553 makes it clear > that it must be encapsulated; if the packet is outbound, why would it > be encapsulated at all? This case is covered in the RFC too: > > [Pascal] I wrote "may" from the fact that the packet may be issued > and consumed within the RPL domain in which case the option is > conserved all the way and there is no 6in6 encapsulation. But I agree > the operation above does come with 6in6. OK > >> 3. Datagrams destined to nodes outside the RPL Instance are >> dropped if the outermost IPv6 header contains a RPL Option not >> generated by the RPL router forwarding the datagram. > > Then, the draft says: > >> This document specifies how the Flow Label can be reused within the >> RPL domain as a replacement to the RPL option. The use of the >> Flow Label within a RPL domain is an instance of the stateful >> scenarios decribed in [RFC6437]... > > In fact RFC 6437 carefully says very little about stateful scenarios; > it does not describe them, but it does constrain them. Here is the > entire section on this topic: > > [Pascal] what about the word "introduced", or "discussed"? OK > >> 4. Flow State Establishment Requirements >> >> A node that sets the flow label MAY also take part in a flow state >> establishment method that results in assigning specific treatments >> to specific flows, possibly including signaling. Any such method >> MUST NOT disturb nodes taking part in the stateless scenario just >> described. Thus, any node that sets flow label values according to >> a stateful scheme MUST choose labels that conform to Section 3 of >> this specification. Further details are not discussed in this >> document. > >> The problem is that section 3 intentionally does not consider flow >> label values in which any of the bits have semantic significance, >> and this was the consensus in the 6MAN WG after a great deal of >> discussion. However, the present proposal assigns semantics to >> various bits in the flow label, destroying its desired property of >> belonging to a statistically uniform distribution. > > [Pascal] That is true within the edge network that is the RPL domain. > But outside the RPL domain the desired properties are conserved. The > rationale for the statistically uniform distribution does not > necessarily bring a lot of value within the LLN. On the other hand, > the 6in6 encaps and HbH header are hugely detrimental to the > operations and will result is shorter battery life and reduced > applicability. I participated as a coeditor to the ISA100.11a > standard that actually uses IPv6 in the 6LoWPAN HC form. I've seen > how the adoption of IPv6 was at stake for a single additional octet > in a header, and this actually led to changes at the IETF and the new > 6LoWPAN HC. Indeed, unless you have a power source, every octet that > you have to place it in every frame or packet in the LLN counts > dearly. I understand that, but there was a strong feeling in 6MAN that the flow label should be an end-to-end field (even though that is unenforceable). If you can make it clear that the flow label in your model refers only to the label of the encapsulating packet, and that any flow label set by the source host in the inner packet is not changed, it will be fine. That's the same model as RFC 6438 (flow labels for ECMP/LAG tunnels). > >> The issue is clearly stated in RFC 6437: > >> Once set to a non-zero value, the Flow Label is expected to be >> delivered unchanged to the destination node(s). A forwarding node >> MUST either leave a non-zero flow label value unchanged or change >> it only for compelling operational security reasons as described in >> Section 6.1. > > [Pascal] We have a compelling operational reason for sure, because > the power consumption is the number one critical constraint that > drives most of the physical design choices in a LLN where a battery > life must often expressed in years. I'm unclear, though, why RFC > 6437 went as far as indicating that the compelling reason should be > qualified as security. Because the firewall people had already made it very clear that whatever we wrote in an RFC, firewalls in sensitive applications would treat the flow label as a covert channel risk. Apart from that, as noted above, the WG wanted to insist on the end to end property of the label. > I take that as an indication of criticality as > opposed to a tentative to predict future needs. It makes sense to me > to add in the draft that "the source in the LLN SHOULD set the Flow > label to zero and MUST NOT expect that the flow label will be > conserved end to end if it knows by policy that the LLN will use this > draft". Would that be sufficient to alleviate this concern? If we are talking about the encapsulating packet, sure. Is there any reason that the label in the raw packet would be changed? Brian > > And yes, I will certainly keep you CCed, and CC you if other threads > pop up on the subject in ROLL, if you do not mind; > > Pascal From pthubert@cisco.com Tue May 8 05:52:09 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EDE21F8495 for ; Tue, 8 May 2012 05:52:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.207 X-Spam-Level: X-Spam-Status: No, score=-10.207 tagged_above=-999 required=5 tests=[AWL=0.392, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtzQcp11DxL0 for ; Tue, 8 May 2012 05:52:08 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 9843621F848B for ; Tue, 8 May 2012 05:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=12888; q=dns/txt; s=iport; t=1336481527; x=1337691127; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=6OlmpVjJCkmngid9bjWZQKdjKL+9rspYLEL1vyWgFF4=; b=KZPMy7o0z6jv1XXcQdrBrqHSE8+USPg02yuYca7AvZ1A2X323mFYo4O9 /r+0cC/QZoL/Zi8uwT/7/Ndp9UrDzQWcahEUblABUMXWaCqyxuDdZMjKp KyN8CV6pJGBoqdm72nb0OTHQXRxUWNZv4q1197MrWDMEhLpcHTi0OzeOt g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFALkWqU+Q/khN/2dsb2JhbABEhXKsI4EPgQeCDAEBAQMBEgEQDQRFBQcEAgEIEQQBAQECAgYGFwECAgIBAR8lCQgBAQQTCBEJh14DBgWaaY0WiTwNiVOBL4hraQUXhFU1YwShPYMagWmCaw X-IronPort-AV: E=Sophos;i="4.75,551,1330905600"; d="scan'208";a="72690151" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 08 May 2012 12:52:01 +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 q48Cq19W018224; Tue, 8 May 2012 12:52:01 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 May 2012 14:52:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 8 May 2012 14:50:09 +0200 Message-ID: In-Reply-To: <4FA8ECF0.7070200@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-thubert-roll-flow-label-00.txt Thread-Index: Ac0tAGHDI2REIvgLQSSa7Y5mnyD1IAAFVkSA References: <20120504080338.24030.4170.idtracker@ietfa.amsl.com> <4FA3C476.5000903@gmail.com> <4FA8ECF0.7070200@gmail.com> From: "Pascal Thubert (pthubert)" To: "Brian E Carpenter" X-OriginalArrivalTime: 08 May 2012 12:52:01.0157 (UTC) FILETIME=[5C6B2350:01CD2D19] Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-thubert-roll-flow-label-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 12:52:10 -0000 SGkgQnJpYW46DQoNCkknbGwgYmUgcHVibGlzaGluZyBhIGZpeCBzb29uLiBUaGF0IGEgYnVuY2gg Zm9yIHRob3NlIGNvbW1lbnRzLg0KDQo+IElmIHdlIGFyZSB0YWxraW5nIGFib3V0IHRoZSBlbmNh cHN1bGF0aW5nIHBhY2tldCwgc3VyZS4gSXMgdGhlcmUgYW55IHJlYXNvbiB0aGF0IHRoZSBsYWJl bCBpbiB0aGUgcmF3IHBhY2tldCB3b3VsZCBiZSBjaGFuZ2VkPw0KQnV0IHRoYXQncyB0aGUgY29y ZSBwcm9ibGVtIHdlJ2xsIGhhdmUgdG8gc29sdmUuIFRoaXMgZHJhZnQgYWltcyBzcGVjaWZpY2Fs bHkgYXQgcmVtb3ZpbmcgdGhlIGV4dHJhIGVuY2Fwc3VsYXRpb24gdGhhdCBjb25zdW1lcyBvY3Rl dHMgYW5kIHRoZXJlYnkgYmF0dGVyeS4NCg0KSWYgd2UgaGF2ZSBubyBleHRyYSBlbmNhcHMgdGhl biB0aGVyZSBpcyBubyBvdXRlciBmbG93IGxhYmVsIHRvIHBsYXkgd2l0aDsgd2UgaGF2ZSB0byB1 c2UgdGhlICdlbmQgdG8gZW5kJyBmbG93IGxhYmVsIHRoYXQgaXMgbm90ICdlbmQgdG8gZW5kICdh bnltb3JlIGJ1dCBoYXMgMiBzZXBhcmF0ZSBsaXZlcywgb25lIHdpdGhpbiB0aGUgTExOIGFuZCBv bmUgaW4gdGhlIEludGVybmV0IGFzIHdlIGtub3cgaXQuDQoNClJlbWFya3MgdGhlcmU6DQotIFJG QyA2NTUzIGlzIGEgZGVmaW5pdGUgbm8gZ28gaW4gdGhlIGZyaW5nZS4gV2hlbiB5b3UncmUgc3Bl bmRpbmcgY29uc2lkZXJhYmxlIGVmZm9ydHMgdG8gc2F2ZSBhIHNpbmdsZSBiaXQgaW4gYSBzdGFu ZGFyZCBsaWtlIElTQTEwMC4xMWEsIFdpSEFSVCBvciB0aGUgZXF1aXZhbGVudCBJRUMgdmVyc2lv bnMsIHlvdSBkbyBub3QgdGhpbmsgZm9yIGEgbWludXRlIG9mIGFkZGluZyAyMCBiaXRzIHRoYXQg aGF2ZSB0byBsb29rIGxpa2UgcmFuZG9tLiBSYXRoZXIsIHlvdSBhc2sgd2hldGhlciB5b3UgcmVh bGx5IHdhbnQgSVB2NiBpbiB0aGF0IHdvcmxkIGF0IGFsbC4gR3Vlc3Mgd2hhdCwgV2lIQVJUIHdl bnQgd2l0aG91dCBJUC4NCi0gVGhlIGV4dHJhIGVuY2FwcyBpcyBjZXJ0YWlubHkgYSBtYWpvciBj b25jZXJuIGZvciBaaWdiZWVJUCBwZW9wbGUgYXMgd2VsbCwgYW5kIHRoZSBtYWluIHJlYXNvbiB3 aHkgd2UgcHVibGlzaGVkIGRyYWZ0LWh1aS02bWFuLXJwbC1oZWFkZXJzIC4gDQotIFJGQyA2NTUz IHdhcyBkZXNpZ25lZCB3aXRoIGEgY2VydGFpbiBtaW5kIHNldCB0aGF0J3MgZm9jdXNlZCBvbiB0 aGUgYmVuZWZpdCBmb3IgdGhlIEludGVybmV0IGNvcmUgYnV0IGlnbm9yZXMgdGhlIGZyaW5nZSB0 aGF0J3MgYnVpbGRpbmcgYXQgdGhlIGVkZ2UuIE15IGNvbmNsdXNpb24gaXMgdGhhdCB3ZSBtdXN0 IGVuc3VyZSB0aGF0IGl0IGlzIHJlc3BlY3RlZCBpbiB0aGUgZG9tYWluIHdoZXJlIGl0IGlzIGRl c2lnbmVkIHRvIGFwcGx5LCBhbmQgdGhlIGRyYWZ0IHRyaWVzIHRvIHJlYWNoIHRoYXQgZ29hbC4g WW91J2xsIG5vdGUgdGhhdCB0aGUgZnJpbmdlIGhhcyBhIHBvdGVudGlhbCB0byByZXByZXNlbnQg b3JkZXJzIG9mIG1hZ25pdHVkZSBtb3JlIGRldmljZXMgKGRhcmUgSSBjYWxsIHRob3NlIGhvc3Rz IG9yIHJvdXRlcnM/KSB0aGFuIHRoZSBJbnRlcm5ldCBhcyB3ZSBrbm93IGl0Lg0KLSBFdm9sdXRp b24gaXMgdGhlIGtleSBmb3Igc3Vydml2YWwuIEkndmUgYmVlbiBhZHZvY2F0aW5nIGZvciAobW9y ZSB0aGFuIDUpIHllYXJzIHRoYXQgSVB2NiBjYW4gZXZvbHZlIGFuZCBiZSByZWxldmFudCBpbiB0 aGUgZnJpbmdlOyBkaWQgdGhhdCBhdCBDaXNjbyBOZXR3b3JrZXJzLCBFbWVyc29uIEV4Y2hhbmdl LCAgRVRTTyBNMk0sIGFuZCBJU0EvSUVDIFNETyBtZWV0aW5ncy4gUGxlYXNlIGRvIG5vdCBwcm92 ZSBtZSB3cm9uZy4NCg0KQ2hlZXJzLA0KDQpQYXNjYWwNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IEJyaWFuIEUgQ2FycGVudGVyIFttYWlsdG86YnJpYW4uZS5jYXJwZW50ZXJA Z21haWwuY29tXSANClNlbnQ6IG1hcmRpIDggbWFpIDIwMTIgMTE6NTMNClRvOiBQYXNjYWwgVGh1 YmVydCAocHRodWJlcnQpDQpDYzogcm9sbEBpZXRmLm9yZw0KU3ViamVjdDogUmU6IEktRCBBY3Rp b246IGRyYWZ0LXRodWJlcnQtcm9sbC1mbG93LWxhYmVsLTAwLnR4dA0KDQpPbiAyMDEyLTA1LTA3 IDEzOjU5LCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIHdyb3RlOg0KPiBIaSBCcmlhbjoNCj4g DQo+PiBJTUhPIHRoZXJlIGFyZSBwcm9ibGVtcyB3aXRoIHRoaXMgcHJvcG9zYWwuIE9uZSBpcyB0 aGF0IGl0IGRvZXNuJ3QsIA0KPj4gYXMgZmFyIGFzIEkgY2FuIHNlZSwgZGVtb25zdHJhdGUgdGhh dCB0aGUgb3ZlcmhlYWQgb2YgcmV3cml0aW5nIHRoZSANCj4+IGZsb3cgbGFiZWwgb24gZXhpdCBm cm9tIGFuIFJQTCBkb21haW4gaXMgc2lnbmlmaWNhbnRseSBsZXNzIHRoYW4gdGhlIA0KPj4gb3Zl cmhlYWQgb2YgZGVhbGluZyB3aXRoIHRoZSBSUEwgaG9wLWJ5LWhvcCBvcHRpb24gYXQgdGhlIGVk Z2Ugb2YgdGhlIA0KPj4gZG9tYWluLg0KPiANCj4gW1Bhc2NhbF0gVGhlIG92ZXJoZWFkIGlzIG1h aW5seSBmb3IgcGFja2V0cyBjb21pbmcgZnJvbSB0aGUgb3V0c2lkZSANCj4gaW50byB0aGUgUlBM IGRvbWFpbi4gU3VjaCBwYWNrZXRzIG5lZWQgZXh0cmEgZW5jYXBzdWxhdGlvbiB0aGF0J3MgDQo+ IGRldHJpbWVudGFsIGZvciBiYXR0ZXJpZXMgYW5kIG1heSBjYXVzZSBhIHNtYWxsIHBhY2tldCB0 byBncm93IGFib3ZlIA0KPiB0aGUgTUFDIE1heCBGcmFtZSwgbGVhZGluZyB0byBMMiBvciA2TG9X UEFOIGZyYWdtZW50YXRpb24uDQoNCklmIHlvdSBjYW4gZXhwbGFpbiB0aGlzIGluIGEgZmV3IHdv cmRzIGluIHRoZSB0ZXh0LCBpdCB3aWxsIGJlIGZpbmUuDQoNCj4gDQo+IFRoZW4sIHRoaXMgcGhy YXNlOg0KPiANCj4+IFNhZGx5LCB0aGUgT3B0aW9uIG11c3QgYmUgcGxhY2VkIGluIGEgSG9wLWJ5 LUhvcCBvcHRpb24gdGhhdCBtdXN0IGJlIA0KPj4gaW5zZXJ0ZWQgb3IgcmVtb3ZlZCBhcyB0aGUg cGFja2V0IGNyb3NzZXMgdGhlIGJvcmRlciBvZiB0aGUgUlBMIA0KPj4gZG9tYWluLg0KPiANCj4g Ym90aGVycyBtZSwgYmVjYXVzZSAoYW5kIEkgaGF2ZSBsb29rZWQgcmVjZW50bHkpIHRoZXJlIGlz IG5vdGhpbmcgaW4gDQo+IHRoZSBJUHY2IHNwZWNzIHRoYXQgYWxsb3dzIGZvciBhbiBleHRlbnNp b24gaGVhZGVyIGJlaW5nIGluc2VydGVkIChvcg0KPiByZW1vdmVkKSBlbiByb3V0ZS4gVGhlIHRl eHQgY29udGludWVzDQo+IA0KPiBbUGFzY2FsXSBJJ2xsIHJld29yZCB0byBpbmRpY2F0ZSB0aGF0 IHRoZSBvcGVyYXRpb24gb2YgaW5zZXJ0aW5nIC8gDQo+IHJlbW92aW5nIHRoZSBIYkggaGVhZGVy IGNvbWVzIHdpdGggNmluNi4gUkZDIDY1NTMgc2F5czogIiBXaGVuIHRoZSANCj4gcm91dGVyIGlz IHRoZSBzb3VyY2Ugb2YgdGhlIG9yaWdpbmFsIHBhY2tldCBhbmQgdGhlIGRlc3RpbmF0aW9uIGlz IA0KPiBrbm93biB0byBiZSB3aXRoaW4gdGhlIHNhbWUgUlBMIEluc3RhbmNlLCB0aGUgcm91dGVy IFNIT1VMRCBpbmNsdWRlIA0KPiB0aGUgUlBMIE9wdGlvbiBkaXJlY3RseSB3aXRoaW4gdGhlIG9y aWdpbmFsIHBhY2tldC4gT3RoZXJ3aXNlLCByb3V0ZXJzIA0KPiBNVVNUIHVzZSBJUHY2LWluLUlQ djYgdHVubmVsaW5nIFtSRkMyNDczXSBhbmQgcGxhY2UgdGhlIFJQTCBPcHRpb24gaW4gDQo+IHRo ZSB0dW5uZWwgaGVhZGVyLiAgVXNpbmcgSVB2Ni1pbi1JUHY2IHR1bm5lbGluZyBlbnN1cmVzIHRo YXQgdGhlIA0KPiBkZWxpdmVyZWQgZGF0YWdyYW0gcmVtYWlucyB1bm1vZGlmaWVkIGFuZCB0aGF0 IElDTVB2NiBlcnJvcnMgZ2VuZXJhdGVkIA0KPiBieSBhIFJQTCBPcHRpb24gYXJlIHNlbnQgYmFj ayB0byB0aGUgcm91dGVyIHRoYXQgZ2VuZXJhdGVkIHRoZSBSUEwgDQo+IE9wdGlvbi4iDQoNClll cywgSSBoYWQgdG8gcmVhZCBxdWl0ZSBkZWVwbHkgaW50byA2NTUzIHRvIHVuZGVyc3RhbmQgdGhp cy4gSSB0aGluayB5b3VyIGRyYWZ0IHdpbGwgYmUgcmVhZCBieSBwZW9wbGUgd2l0aG91dCBkZXRh aWxlZCBrbm93bGVkZ2Ugb2YgUlBMIHNvIGl0IG5lZWRzIHRvIGJlIGV4cGxhaW5lZC4NCg0KPiAN Cj4+IC4uLlRoaXMgb3BlcmF0aW9uIG1heSBpbnZvbHZlIGFuIGV4dHJhIGVuY2Fwc3VsYXRpb24g dGhhdCBpcyANCj4+IGRldHJpbWVudGFsIHRvIHRoZSBuZXR3b3JrIG9wZXJhdGlvbiwgaW4gcGFy dGljdWxhciB3aXRoIHJlZ2FyZHMgdG8gDQo+PiBiYW5kd2lkdGggYW5kIGJhdHRlcnkgY29uc3Ry YWludHMuDQo+IA0KPiBXaHkgIm1heSI/IElmIHRoZSBwYWNrZXQgaXMgaW5ib3VuZCB0byBSUEws IFJGQyA2NTUzIG1ha2VzIGl0IGNsZWFyIA0KPiB0aGF0IGl0IG11c3QgYmUgZW5jYXBzdWxhdGVk OyBpZiB0aGUgcGFja2V0IGlzIG91dGJvdW5kLCB3aHkgd291bGQgaXQgDQo+IGJlIGVuY2Fwc3Vs YXRlZCBhdCBhbGw/IFRoaXMgY2FzZSBpcyBjb3ZlcmVkIGluIHRoZSBSRkMgdG9vOg0KPiANCj4g W1Bhc2NhbF0gSSB3cm90ZSAibWF5IiBmcm9tIHRoZSBmYWN0IHRoYXQgdGhlIHBhY2tldCBtYXkg YmUgaXNzdWVkIGFuZCANCj4gY29uc3VtZWQgd2l0aGluIHRoZSBSUEwgZG9tYWluIGluIHdoaWNo IGNhc2UgdGhlIG9wdGlvbiBpcyBjb25zZXJ2ZWQgDQo+IGFsbCB0aGUgd2F5IGFuZCB0aGVyZSBp cyBubyA2aW42IGVuY2Fwc3VsYXRpb24uIEJ1dCBJIGFncmVlIHRoZSANCj4gb3BlcmF0aW9uIGFi b3ZlIGRvZXMgY29tZSB3aXRoIDZpbjYuDQoNCk9LDQoNCj4gDQo+PiAzLiAgRGF0YWdyYW1zIGRl c3RpbmVkIHRvIG5vZGVzIG91dHNpZGUgdGhlIFJQTCBJbnN0YW5jZSBhcmUgZHJvcHBlZCANCj4+ IGlmIHRoZSBvdXRlcm1vc3QgSVB2NiBoZWFkZXIgY29udGFpbnMgYSBSUEwgT3B0aW9uIG5vdCBn ZW5lcmF0ZWQgYnkgDQo+PiB0aGUgUlBMIHJvdXRlciBmb3J3YXJkaW5nIHRoZSBkYXRhZ3JhbS4N Cj4gDQo+IFRoZW4sIHRoZSBkcmFmdCBzYXlzOg0KPiANCj4+IFRoaXMgZG9jdW1lbnQgc3BlY2lm aWVzIGhvdyB0aGUgRmxvdyBMYWJlbCBjYW4gYmUgcmV1c2VkIHdpdGhpbiB0aGUgIA0KPj4gUlBM IGRvbWFpbiBhcyBhIHJlcGxhY2VtZW50IHRvIHRoZSBSUEwgb3B0aW9uLiAgVGhlIHVzZSBvZiB0 aGUgRmxvdyANCj4+IExhYmVsIHdpdGhpbiBhIFJQTCBkb21haW4gaXMgYW4gaW5zdGFuY2Ugb2Yg dGhlIHN0YXRlZnVsIHNjZW5hcmlvcyANCj4+IGRlY3JpYmVkIGluIFtSRkM2NDM3XS4uLg0KPiAN Cj4gSW4gZmFjdCBSRkMgNjQzNyBjYXJlZnVsbHkgc2F5cyB2ZXJ5IGxpdHRsZSBhYm91dCBzdGF0 ZWZ1bCBzY2VuYXJpb3M7IA0KPiBpdCBkb2VzIG5vdCBkZXNjcmliZSB0aGVtLCBidXQgaXQgZG9l cyBjb25zdHJhaW4gdGhlbS4gSGVyZSBpcyB0aGUgDQo+IGVudGlyZSBzZWN0aW9uIG9uIHRoaXMg dG9waWM6DQo+IA0KPiBbUGFzY2FsXSB3aGF0IGFib3V0IHRoZSB3b3JkICJpbnRyb2R1Y2VkIiwg b3IgImRpc2N1c3NlZCI/DQoNCk9LDQoNCj4gDQo+PiA0LiAgRmxvdyBTdGF0ZSBFc3RhYmxpc2ht ZW50IFJlcXVpcmVtZW50cw0KPj4gDQo+PiBBIG5vZGUgdGhhdCBzZXRzIHRoZSBmbG93IGxhYmVs IE1BWSBhbHNvIHRha2UgcGFydCBpbiBhIGZsb3cgc3RhdGUgDQo+PiBlc3RhYmxpc2htZW50IG1l dGhvZCB0aGF0IHJlc3VsdHMgaW4gYXNzaWduaW5nIHNwZWNpZmljIHRyZWF0bWVudHMgdG8gDQo+ PiBzcGVjaWZpYyBmbG93cywgcG9zc2libHkgaW5jbHVkaW5nIHNpZ25hbGluZy4gIEFueSBzdWNo IG1ldGhvZCBNVVNUIA0KPj4gTk9UIGRpc3R1cmIgbm9kZXMgdGFraW5nIHBhcnQgaW4gdGhlIHN0 YXRlbGVzcyBzY2VuYXJpbyBqdXN0IA0KPj4gZGVzY3JpYmVkLiAgVGh1cywgYW55IG5vZGUgdGhh dCBzZXRzIGZsb3cgbGFiZWwgdmFsdWVzIGFjY29yZGluZyB0byBhIA0KPj4gc3RhdGVmdWwgc2No ZW1lIE1VU1QgY2hvb3NlIGxhYmVscyB0aGF0IGNvbmZvcm0gdG8gU2VjdGlvbiAzIG9mIHRoaXMg DQo+PiBzcGVjaWZpY2F0aW9uLiAgRnVydGhlciBkZXRhaWxzIGFyZSBub3QgZGlzY3Vzc2VkIGlu IHRoaXMgZG9jdW1lbnQuDQo+IA0KPj4gVGhlIHByb2JsZW0gaXMgdGhhdCBzZWN0aW9uIDMgaW50 ZW50aW9uYWxseSBkb2VzIG5vdCBjb25zaWRlciBmbG93IA0KPj4gbGFiZWwgdmFsdWVzIGluIHdo aWNoIGFueSBvZiB0aGUgYml0cyBoYXZlIHNlbWFudGljIHNpZ25pZmljYW5jZSwgYW5kIA0KPj4g dGhpcyB3YXMgdGhlIGNvbnNlbnN1cyBpbiB0aGUgNk1BTiBXRyBhZnRlciBhIGdyZWF0IGRlYWwg b2YgDQo+PiBkaXNjdXNzaW9uLiBIb3dldmVyLCB0aGUgIHByZXNlbnQgcHJvcG9zYWwgYXNzaWdu cyBzZW1hbnRpY3MgdG8gDQo+PiB2YXJpb3VzIGJpdHMgaW4gdGhlIGZsb3cgbGFiZWwsIGRlc3Ry b3lpbmcgaXRzIGRlc2lyZWQgcHJvcGVydHkgb2YgDQo+PiBiZWxvbmdpbmcgdG8gYSBzdGF0aXN0 aWNhbGx5IHVuaWZvcm0gZGlzdHJpYnV0aW9uLg0KPiANCj4gW1Bhc2NhbF0gVGhhdCBpcyB0cnVl IHdpdGhpbiB0aGUgZWRnZSBuZXR3b3JrIHRoYXQgaXMgdGhlIFJQTCBkb21haW4uDQo+IEJ1dCBv dXRzaWRlIHRoZSBSUEwgZG9tYWluIHRoZSBkZXNpcmVkIHByb3BlcnRpZXMgYXJlIGNvbnNlcnZl ZC4gVGhlIA0KPiByYXRpb25hbGUgZm9yIHRoZSBzdGF0aXN0aWNhbGx5IHVuaWZvcm0gZGlzdHJp YnV0aW9uIGRvZXMgbm90IA0KPiBuZWNlc3NhcmlseSBicmluZyBhIGxvdCBvZiB2YWx1ZSB3aXRo aW4gdGhlIExMTi4gT24gdGhlIG90aGVyIGhhbmQsIA0KPiB0aGUgNmluNiBlbmNhcHMgYW5kIEhi SCBoZWFkZXIgYXJlIGh1Z2VseSBkZXRyaW1lbnRhbCB0byB0aGUgDQo+IG9wZXJhdGlvbnMgYW5k IHdpbGwgcmVzdWx0IGlzIHNob3J0ZXIgYmF0dGVyeSBsaWZlIGFuZCByZWR1Y2VkIA0KPiBhcHBs aWNhYmlsaXR5LiBJIHBhcnRpY2lwYXRlZCBhcyBhIGNvZWRpdG9yIHRvIHRoZSBJU0ExMDAuMTFh IHN0YW5kYXJkIA0KPiB0aGF0IGFjdHVhbGx5IHVzZXMgSVB2NiBpbiB0aGUgNkxvV1BBTiBIQyBm b3JtLiBJJ3ZlIHNlZW4gaG93IHRoZSANCj4gYWRvcHRpb24gb2YgSVB2NiB3YXMgYXQgc3Rha2Ug Zm9yIGEgc2luZ2xlIGFkZGl0aW9uYWwgb2N0ZXQgaW4gYSANCj4gaGVhZGVyLCBhbmQgdGhpcyBh Y3R1YWxseSBsZWQgdG8gY2hhbmdlcyBhdCB0aGUgSUVURiBhbmQgdGhlIG5ldyANCj4gNkxvV1BB TiBIQy4gSW5kZWVkLCB1bmxlc3MgeW91IGhhdmUgYSBwb3dlciBzb3VyY2UsIGV2ZXJ5IG9jdGV0 IHRoYXQgDQo+IHlvdSBoYXZlIHRvIHBsYWNlIGl0IGluIGV2ZXJ5IGZyYW1lIG9yIHBhY2tldCBp biB0aGUgTExOIGNvdW50cyANCj4gZGVhcmx5Lg0KDQpJIHVuZGVyc3RhbmQgdGhhdCwgYnV0IHRo ZXJlIHdhcyBhIHN0cm9uZyBmZWVsaW5nIGluIDZNQU4gdGhhdCB0aGUgZmxvdyBsYWJlbCBzaG91 bGQgYmUgYW4gZW5kLXRvLWVuZCBmaWVsZCAoZXZlbiB0aG91Z2ggdGhhdCBpcyB1bmVuZm9yY2Vh YmxlKS4NCklmIHlvdSBjYW4gbWFrZSBpdCBjbGVhciB0aGF0IHRoZSBmbG93IGxhYmVsIGluIHlv dXIgbW9kZWwgcmVmZXJzIG9ubHkgdG8gdGhlIGxhYmVsIG9mIHRoZSBlbmNhcHN1bGF0aW5nIHBh Y2tldCwgYW5kIHRoYXQgYW55IGZsb3cgbGFiZWwgc2V0IGJ5IHRoZSBzb3VyY2UgaG9zdCBpbiB0 aGUgaW5uZXIgcGFja2V0IGlzIG5vdCBjaGFuZ2VkLCBpdCB3aWxsIGJlIGZpbmUuDQpUaGF0J3Mg dGhlIHNhbWUgbW9kZWwgYXMgUkZDIDY0MzggKGZsb3cgbGFiZWxzIGZvciBFQ01QL0xBRyB0dW5u ZWxzKS4NCg0KPiANCj4+IFRoZSBpc3N1ZSBpcyBjbGVhcmx5IHN0YXRlZCBpbiBSRkMgNjQzNzoN Cj4gDQo+PiBPbmNlIHNldCB0byBhIG5vbi16ZXJvIHZhbHVlLCB0aGUgRmxvdyBMYWJlbCBpcyBl eHBlY3RlZCB0byBiZSANCj4+IGRlbGl2ZXJlZCB1bmNoYW5nZWQgdG8gdGhlIGRlc3RpbmF0aW9u IG5vZGUocykuICBBIGZvcndhcmRpbmcgbm9kZSANCj4+IE1VU1QgZWl0aGVyIGxlYXZlIGEgbm9u LXplcm8gZmxvdyBsYWJlbCB2YWx1ZSB1bmNoYW5nZWQgb3IgY2hhbmdlIGl0IA0KPj4gb25seSBm b3IgY29tcGVsbGluZyBvcGVyYXRpb25hbCBzZWN1cml0eSByZWFzb25zIGFzIGRlc2NyaWJlZCBp biAgDQo+PiBTZWN0aW9uIDYuMS4NCj4gDQo+IFtQYXNjYWxdICBXZSBoYXZlIGEgY29tcGVsbGlu ZyBvcGVyYXRpb25hbCByZWFzb24gZm9yIHN1cmUsIGJlY2F1c2UgDQo+IHRoZSBwb3dlciBjb25z dW1wdGlvbiBpcyB0aGUgbnVtYmVyIG9uZSBjcml0aWNhbCBjb25zdHJhaW50IHRoYXQgDQo+IGRy aXZlcyBtb3N0IG9mIHRoZSBwaHlzaWNhbCBkZXNpZ24gY2hvaWNlcyBpbiBhIExMTiB3aGVyZSBh IGJhdHRlcnkgDQo+IGxpZmUgbXVzdCBvZnRlbiBleHByZXNzZWQgaW4geWVhcnMuICBJJ20gdW5j bGVhciwgdGhvdWdoLCB3aHkgUkZDDQo+IDY0Mzcgd2VudCBhcyBmYXIgYXMgaW5kaWNhdGluZyB0 aGF0IHRoZSBjb21wZWxsaW5nIHJlYXNvbiBzaG91bGQgYmUgDQo+IHF1YWxpZmllZCBhcyBzZWN1 cml0eS4NCg0KQmVjYXVzZSB0aGUgZmlyZXdhbGwgcGVvcGxlIGhhZCBhbHJlYWR5IG1hZGUgaXQg dmVyeSBjbGVhciB0aGF0IHdoYXRldmVyIHdlIHdyb3RlIGluIGFuIFJGQywgZmlyZXdhbGxzIGlu IHNlbnNpdGl2ZSBhcHBsaWNhdGlvbnMgd291bGQgdHJlYXQgdGhlIGZsb3cgbGFiZWwgYXMgYSBj b3ZlcnQgY2hhbm5lbCByaXNrLiBBcGFydCBmcm9tIHRoYXQsIGFzIG5vdGVkIGFib3ZlLCB0aGUg V0cgd2FudGVkIHRvIGluc2lzdCBvbiB0aGUgZW5kIHRvIGVuZCBwcm9wZXJ0eSBvZiB0aGUgbGFi ZWwuDQoNCj4gSSB0YWtlIHRoYXQgYXMgYW4gaW5kaWNhdGlvbiBvZiBjcml0aWNhbGl0eSBhcyBv cHBvc2VkIHRvIGEgdGVudGF0aXZlIA0KPiB0byBwcmVkaWN0IGZ1dHVyZSBuZWVkcy4gSXQgbWFr ZXMgc2Vuc2UgdG8gbWUgdG8gYWRkIGluIHRoZSBkcmFmdCB0aGF0IA0KPiAidGhlIHNvdXJjZSBp biB0aGUgTExOIFNIT1VMRCBzZXQgdGhlIEZsb3cgbGFiZWwgdG8gemVybyBhbmQgTVVTVCBOT1Qg DQo+IGV4cGVjdCB0aGF0IHRoZSBmbG93IGxhYmVsIHdpbGwgYmUgY29uc2VydmVkIGVuZCB0byBl bmQgaWYgaXQga25vd3MgYnkgDQo+IHBvbGljeSB0aGF0IHRoZSBMTE4gd2lsbCB1c2UgdGhpcyBk cmFmdCIuIFdvdWxkIHRoYXQgYmUgc3VmZmljaWVudCB0byANCj4gYWxsZXZpYXRlIHRoaXMgY29u Y2Vybj8NCg0KSWYgd2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIGVuY2Fwc3VsYXRpbmcgcGFja2V0 LCBzdXJlLiBJcyB0aGVyZSBhbnkgcmVhc29uIHRoYXQgdGhlIGxhYmVsIGluIHRoZSByYXcgcGFj a2V0IHdvdWxkIGJlIGNoYW5nZWQ/DQoNCiAgIEJyaWFuDQoNCj4gDQo+IEFuZCB5ZXMsIEkgd2ls bCBjZXJ0YWlubHkga2VlcCB5b3UgQ0NlZCwgYW5kIENDIHlvdSBpZiBvdGhlciB0aHJlYWRzIA0K PiBwb3AgdXAgb24gdGhlIHN1YmplY3QgaW4gUk9MTCwgaWYgeW91IGRvIG5vdCBtaW5kOw0KPiAN Cj4gUGFzY2FsDQo= From brian.e.carpenter@gmail.com Tue May 8 06:43:50 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E45921F84DF for ; Tue, 8 May 2012 06:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.532 X-Spam-Level: X-Spam-Status: No, score=-103.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbPvywZzQU8H for ; Tue, 8 May 2012 06:43:49 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id AB1A221F84DD for ; Tue, 8 May 2012 06:43:48 -0700 (PDT) Received: by eabd1 with SMTP id d1so1373511eab.31 for ; Tue, 08 May 2012 06:43:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=e4dQIQqmuQSt9ivlzD8JzWHeca5hr+3wCE15tEpFW5E=; b=DargVQFNeLjidsckwNzcuEevvqDl+oAy3qbh5zwoTzCSigRX94/MWWjqTSfMMpoQXC bpGeIZQuJVIileno4pVVj90t80PdRxOnOoBYuVZ/Q+CDmx6IhV0MD8oZBOIrohbFGuz6 JvUglfkTeDHG8NWKsM0WjKLdxMH2CRfg0v/1gakDWGQXTbll64PyDMTjhUjUM+Y/NdJw +EkjSy/D/KQ+yWOyqhAjzyDTAqH7bMRy3I7oPBvA6QaLwctFx0FR9AeN10mU8zGLFHoh z6v9lAFjoUbIcKEi7/kW8lbEmuA9YCNTWL7idWMJIwg7uCPzV8w6dWmYToYrJRtTo7eY PgBA== Received: by 10.14.50.207 with SMTP id z55mr3361628eeb.45.1336484627778; Tue, 08 May 2012 06:43:47 -0700 (PDT) Received: from [128.232.110.88] (c088.al.cl.cam.ac.uk. [128.232.110.88]) by mx.google.com with ESMTPS id y54sm42924271eef.10.2012.05.08.06.43.45 (version=SSLv3 cipher=OTHER); Tue, 08 May 2012 06:43:45 -0700 (PDT) Message-ID: <4FA9230F.5090100@gmail.com> Date: Tue, 08 May 2012 14:43:43 +0100 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <20120504080338.24030.4170.idtracker@ietfa.amsl.com> <4FA3C476.5000903@gmail.com> <4FA8ECF0.7070200@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-thubert-roll-flow-label-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 13:43:50 -0000 On 2012-05-08 13:50, Pascal Thubert (pthubert) wrote: > Hi Brian: > > I'll be publishing a fix soon. That a bunch for those comments. > >> If we are talking about the encapsulating packet, sure. Is there any reason that the label in the raw packet would be changed? > But that's the core problem we'll have to solve. This draft aims specifically at removing the extra encapsulation that consumes octets and thereby battery. OK, somehow this was still not very clear to me. I think maybe some diagrams for the non-RPL-expert are needed. I try to avoid being doctrinaire; all I can tell you is the models we proposed in 6man which involved rewriting the flow label at domain boundaries were very unpopular. You should probably look at draft-carpenter-6man-flow-update-03 (and only the -03 version). I think that would have allowed what you want to do, but it was firmly rejected by 6man. Thus what I am about to say is heresy: as long as the flow labels emerging from the RPL domain *look* as if the source computer set a flow label per flow conformant with RFC 6437, it should be OK. Except for this complication: in the world of server load balancing, there is some interest in using the same flow label for multiple transport sessions from the same client, even if the client's IP address changes due to mobility. This is still pretty speculative, but it really does require the source node to have control over the final value of the flow label. Brian > If we have no extra encaps then there is no outer flow label to play with; we have to use the 'end to end' flow label that is not 'end to end 'anymore but has 2 separate lives, one within the LLN and one in the Internet as we know it. > > Remarks there: > - RFC 6553 is a definite no go in the fringe. When you're spending considerable efforts to save a single bit in a standard like ISA100.11a, WiHART or the equivalent IEC versions, you do not think for a minute of adding 20 bits that have to look like random. Rather, you ask whether you really want IPv6 in that world at all. Guess what, WiHART went without IP. > - The extra encaps is certainly a major concern for ZigbeeIP people as well, and the main reason why we published draft-hui-6man-rpl-headers . > - RFC 6553 was designed with a certain mind set that's focused on the benefit for the Internet core but ignores the fringe that's building at the edge. My conclusion is that we must ensure that it is respected in the domain where it is designed to apply, and the draft tries to reach that goal. You'll note that the fringe has a potential to represent orders of magnitude more devices (dare I call those hosts or routers?) than the Internet as we know it. > - Evolution is the key for survival. I've been advocating for (more than 5) years that IPv6 can evolve and be relevant in the fringe; did that at Cisco Networkers, Emerson Exchange, ETSO M2M, and ISA/IEC SDO meetings. Please do not prove me wrong. > > Cheers, > > Pascal > > -----Original Message----- > From: Brian E Carpenter [mailto:brian.e.carpenter@gmail.com] > Sent: mardi 8 mai 2012 11:53 > To: Pascal Thubert (pthubert) > Cc: roll@ietf.org > Subject: Re: I-D Action: draft-thubert-roll-flow-label-00.txt > > On 2012-05-07 13:59, Pascal Thubert (pthubert) wrote: >> Hi Brian: >> >>> IMHO there are problems with this proposal. One is that it doesn't, >>> as far as I can see, demonstrate that the overhead of rewriting the >>> flow label on exit from an RPL domain is significantly less than the >>> overhead of dealing with the RPL hop-by-hop option at the edge of the >>> domain. >> [Pascal] The overhead is mainly for packets coming from the outside >> into the RPL domain. Such packets need extra encapsulation that's >> detrimental for batteries and may cause a small packet to grow above >> the MAC Max Frame, leading to L2 or 6LoWPAN fragmentation. > > If you can explain this in a few words in the text, it will be fine. > >> Then, this phrase: >> >>> Sadly, the Option must be placed in a Hop-by-Hop option that must be >>> inserted or removed as the packet crosses the border of the RPL >>> domain. >> bothers me, because (and I have looked recently) there is nothing in >> the IPv6 specs that allows for an extension header being inserted (or >> removed) en route. The text continues >> >> [Pascal] I'll reword to indicate that the operation of inserting / >> removing the HbH header comes with 6in6. RFC 6553 says: " When the >> router is the source of the original packet and the destination is >> known to be within the same RPL Instance, the router SHOULD include >> the RPL Option directly within the original packet. Otherwise, routers >> MUST use IPv6-in-IPv6 tunneling [RFC2473] and place the RPL Option in >> the tunnel header. Using IPv6-in-IPv6 tunneling ensures that the >> delivered datagram remains unmodified and that ICMPv6 errors generated >> by a RPL Option are sent back to the router that generated the RPL >> Option." > > Yes, I had to read quite deeply into 6553 to understand this. I think your draft will be read by people without detailed knowledge of RPL so it needs to be explained. > >>> ...This operation may involve an extra encapsulation that is >>> detrimental to the network operation, in particular with regards to >>> bandwidth and battery constraints. >> Why "may"? If the packet is inbound to RPL, RFC 6553 makes it clear >> that it must be encapsulated; if the packet is outbound, why would it >> be encapsulated at all? This case is covered in the RFC too: >> >> [Pascal] I wrote "may" from the fact that the packet may be issued and >> consumed within the RPL domain in which case the option is conserved >> all the way and there is no 6in6 encapsulation. But I agree the >> operation above does come with 6in6. > > OK > >>> 3. Datagrams destined to nodes outside the RPL Instance are dropped >>> if the outermost IPv6 header contains a RPL Option not generated by >>> the RPL router forwarding the datagram. >> Then, the draft says: >> >>> This document specifies how the Flow Label can be reused within the >>> RPL domain as a replacement to the RPL option. The use of the Flow >>> Label within a RPL domain is an instance of the stateful scenarios >>> decribed in [RFC6437]... >> In fact RFC 6437 carefully says very little about stateful scenarios; >> it does not describe them, but it does constrain them. Here is the >> entire section on this topic: >> >> [Pascal] what about the word "introduced", or "discussed"? > > OK > >>> 4. Flow State Establishment Requirements >>> >>> A node that sets the flow label MAY also take part in a flow state >>> establishment method that results in assigning specific treatments to >>> specific flows, possibly including signaling. Any such method MUST >>> NOT disturb nodes taking part in the stateless scenario just >>> described. Thus, any node that sets flow label values according to a >>> stateful scheme MUST choose labels that conform to Section 3 of this >>> specification. Further details are not discussed in this document. >>> The problem is that section 3 intentionally does not consider flow >>> label values in which any of the bits have semantic significance, and >>> this was the consensus in the 6MAN WG after a great deal of >>> discussion. However, the present proposal assigns semantics to >>> various bits in the flow label, destroying its desired property of >>> belonging to a statistically uniform distribution. >> [Pascal] That is true within the edge network that is the RPL domain. >> But outside the RPL domain the desired properties are conserved. The >> rationale for the statistically uniform distribution does not >> necessarily bring a lot of value within the LLN. On the other hand, >> the 6in6 encaps and HbH header are hugely detrimental to the >> operations and will result is shorter battery life and reduced >> applicability. I participated as a coeditor to the ISA100.11a standard >> that actually uses IPv6 in the 6LoWPAN HC form. I've seen how the >> adoption of IPv6 was at stake for a single additional octet in a >> header, and this actually led to changes at the IETF and the new >> 6LoWPAN HC. Indeed, unless you have a power source, every octet that >> you have to place it in every frame or packet in the LLN counts >> dearly. > > I understand that, but there was a strong feeling in 6MAN that the flow label should be an end-to-end field (even though that is unenforceable). > If you can make it clear that the flow label in your model refers only to the label of the encapsulating packet, and that any flow label set by the source host in the inner packet is not changed, it will be fine. > That's the same model as RFC 6438 (flow labels for ECMP/LAG tunnels). > >>> The issue is clearly stated in RFC 6437: >>> Once set to a non-zero value, the Flow Label is expected to be >>> delivered unchanged to the destination node(s). A forwarding node >>> MUST either leave a non-zero flow label value unchanged or change it >>> only for compelling operational security reasons as described in >>> Section 6.1. >> [Pascal] We have a compelling operational reason for sure, because >> the power consumption is the number one critical constraint that >> drives most of the physical design choices in a LLN where a battery >> life must often expressed in years. I'm unclear, though, why RFC >> 6437 went as far as indicating that the compelling reason should be >> qualified as security. > > Because the firewall people had already made it very clear that whatever we wrote in an RFC, firewalls in sensitive applications would treat the flow label as a covert channel risk. Apart from that, as noted above, the WG wanted to insist on the end to end property of the label. > >> I take that as an indication of criticality as opposed to a tentative >> to predict future needs. It makes sense to me to add in the draft that >> "the source in the LLN SHOULD set the Flow label to zero and MUST NOT >> expect that the flow label will be conserved end to end if it knows by >> policy that the LLN will use this draft". Would that be sufficient to >> alleviate this concern? > > If we are talking about the encapsulating packet, sure. Is there any reason that the label in the raw packet would be changed? > > Brian > >> And yes, I will certainly keep you CCed, and CC you if other threads >> pop up on the subject in ROLL, if you do not mind; >> >> Pascal From prvs=468f8a16e=mukul@uwm.edu Tue May 8 09:22:43 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5825221F85AC for ; Tue, 8 May 2012 09:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.444 X-Spam-Level: X-Spam-Status: No, score=-6.444 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_RMML_Stock9=0.13] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wgEmzumdqYia for ; Tue, 8 May 2012 09:22:42 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7EB3C21F8592 for ; Tue, 8 May 2012 09:22:40 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap0EAOhHqU9/AAAB/2dsb2JhbABEhXKwSwEBBAEjVgUHDxEEAQEDAg0ZAlEIBhOICQULqDOKFYkJgS+JVByEXoEYBIhkjRqBEY8xgwc Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id A05C2E6A8F; Tue, 8 May 2012 11:21:58 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbxuiaLIxogX; Tue, 8 May 2012 11:21:58 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 23A19E6A92; Tue, 8 May 2012 11:21:58 -0500 (CDT) Date: Tue, 8 May 2012 11:21:58 -0500 (CDT) From: Mukul Goyal To: Michael Richardson Message-ID: <1741301535.314758.1336494118091.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <18140.1336398494@marajade.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: Roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 16:22:43 -0000 Hi Michael >Text something like: > Applicability Statements that specify P2P-RPL MUST provide values for > the following parameters: X, Y, Z. I will add the following sentence: Applicability Statements that specify the use of P2P-RPL MUST provide guidance for setting trickle parameters, particularly Imin and the Redundancy Constant. Thanks Mukul ----- Original Message ----- From: "Michael Richardson" To: Roll@ietf.org Cc: adrian@olddog.co.uk, "Mukul Goyal" Sent: Monday, May 7, 2012 8:48:14 AM Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-10 comments -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Mukul" == Mukul Goyal writes: Mukul> Hi Michael >> My suggestion is that the "controversial" values like this SHOULD be Mukul> identified more clearly with text akin to: >> Specific consideration of this value MUST be addressed Mukul> in applicability statement(s). >> (I'd even like to put some kind of 2119-like word in about this) Mukul> You mean to say that P2P-RPL draft should require the Mukul> home/building/whomsoever_cares_to_use_p2p_rpl applicability Mukul> statement to address how to set P2P-RPL trickle parameters? Yes, exactly. There could be a template in the document which must be filled in. Text something like: Applicability Statements that specify P2P-RPL MUST provide values for the following parameters: X, Y, Z. Considerations for setting X. Considerations for setting Y. Considerations for setting Z. For example: The FOOBAR application scenario is a dense mesh needing fast repair times and having routing nodes without power limits. Therefore: 1) the X value SHOULD be set between a and b. 2) the Y value SHOULD be no greater than c. 3) the Z value setting is not critical. - -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Finger me for keys iQEVAwUBT6fSlICLcPvd0N1lAQIfpQgAwBVrjzOdOeVUOOzksTatl9aERaIkYpkj Dj0hEYoogjZE/jQIKG1GCJtoYLuYiQ1Lv4/dtwsnap3KUrymkDk1UdPjfbcKm8oc chHdf4Kg+MUYO7GYeOjlAOqJ/WID9mV/9cVVB71mr+33b2vmhMcnaS6Pv+spgtOS WTDusylkJC6nz2O+DAhjHFT9lzQGvJxfKDs/eXxU8RQK44XHymU7ZmlAV37AeZQB R3kZtFu3v9DC/0ILHz3P6go/iO/n5phd3GUeEMNJjFrrTnyqzIrU0wvwTQ4gaVnG L40iWlpTHxNoLwRMcvPopWVIVfzGbO7bXzcT8je/mccWaDyaPj5gLw== =mNPX -----END PGP SIGNATURE----- From internet-drafts@ietf.org Tue May 8 09:35:24 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB5D21F84FF; Tue, 8 May 2012 09:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKVvV+0XjGSR; Tue, 8 May 2012 09:35:23 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B88BE21F84D3; Tue, 8 May 2012 09:35:23 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120508163523.28046.15740.idtracker@ietfa.amsl.com> Date: Tue, 08 May 2012 09:35:23 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-12.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 16:35:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power= and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-12.txt Pages : 34 Date : 2012-05-08 This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-12.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl/ From prvs=468f8a16e=mukul@uwm.edu Tue May 8 09:42:20 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4874A21F8593 for ; Tue, 8 May 2012 09:42:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.511 X-Spam-Level: X-Spam-Status: No, score=-6.511 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6z0MrLiajrC7 for ; Tue, 8 May 2012 09:42:19 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id A931A21F858F for ; Tue, 8 May 2012 09:42:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAP5LqU9/AAAB/2dsb2JhbABEhXKwTAEBAQQBAQEgSxcPEQQBAQMCDRkCKSgIBhMJiAULmgKOPooUiQmBL4lUHAmEVYEYBIhkjRqQQoMH Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 18AAC1FD0C7 for ; Tue, 8 May 2012 11:42:19 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXTY3QUNUFP3 for ; Tue, 8 May 2012 11:42:18 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id D69B71FD0C8 for ; Tue, 8 May 2012 11:42:18 -0500 (CDT) Date: Tue, 8 May 2012 11:42:18 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <326961085.315388.1336495338781.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20120508163523.28046.15740.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-12.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 May 2012 16:42:20 -0000 This version includes the correct IANA-related text that resolves ticket #88 recently reopened by Michael. Version 11 already included the text in response to discussion with Federico and suggestion by Adrian. This version includes one additional sentence (at the very end of Section 9.2) that applicability statements specifying the use of P2P-RPL MUST provide guidance for setting Trickle parameters, particularly Imin and the redundancy constant. I dont think there is a need for a more elaborate template for the applicability statements to follow. Thanks Mukul ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Tuesday, May 8, 2012 11:35:23 AM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-12.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-12.txt Pages : 34 Date : 2012-05-08 This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-12.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-12.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Wed May 9 01:32:06 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81A1521F85B4 for ; Wed, 9 May 2012 01:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.218 X-Spam-Level: X-Spam-Status: No, score=-10.218 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxxkMxotO32Z for ; Wed, 9 May 2012 01:32:05 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 131E221F846E for ; Wed, 9 May 2012 01:32:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=12858; q=dns/txt; s=iport; t=1336552324; x=1337761924; h=mime-version:content-transfer-encoding:subject:date: message-id:in-reply-to:references:from:to:cc; bh=7o9ig+YUP2MkRjfMRUROCJrG45fbNCOpcVHU0Rw8ms8=; b=G/m+HuiHARedVrbUDxyiRfreGUdUw5bk1opP/tc0e/q0fwgCHYTgXHcB BqjoTU7cruH4/ikF+AEj1AQvB5HLtFvGv4qytlM+c+JPDTpcY6EKcJ49l dB7RW7F+RE46skG0/HVYt2vEntS0Bz80in4V3Fp6j11UM4wT88MqVyAH/ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgIFAN8qqk+Q/khN/2dsb2JhbABEhXWsPoESgQeCDAEBAQMBEgEQDQQ3DgwEAgEIEQQBAQECAgYGFwECAgIBAR8lCQgBAQQTCBEJh14DBgWbDY0WiTQNiVOBL4hyawUXhF41YwShO4MagWmCaw X-IronPort-AV: E=Sophos;i="4.75,557,1330905600"; d="scan'208";a="72757501" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 09 May 2012 08:32:02 +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 q498W2uA027047; Wed, 9 May 2012 08:32:02 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 9 May 2012 10:32:02 +0200 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: Wed, 9 May 2012 10:31:35 +0200 Message-ID: In-Reply-To: <4FA9230F.5090100@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: I-D Action: draft-thubert-roll-flow-label-00.txt Thread-Index: Ac0tIJ/V+K5iLLSPQgecC3rzVf34+AAnNszg References: <20120504080338.24030.4170.idtracker@ietfa.amsl.com> <4FA3C476.5000903@gmail.com> <4FA8ECF0.7070200@gmail.com> <4FA9230F.5090100@gmail.com> From: "Pascal Thubert (pthubert)" To: "Brian E Carpenter" X-OriginalArrivalTime: 09 May 2012 08:32:02.0172 (UTC) FILETIME=[351CABC0:01CD2DBE] Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-thubert-roll-flow-label-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 08:32:06 -0000 SGkgQnJpYW46DQogDQo+Pj4gSWYgd2UgYXJlIHRhbGtpbmcgYWJvdXQgdGhlIGVuY2Fwc3VsYXRp bmcgcGFja2V0LCBzdXJlLiBJcyB0aGVyZSBhbnkgcmVhc29uIHRoYXQgdGhlIGxhYmVsIGluIHRo ZSByYXcgcGFja2V0IHdvdWxkIGJlIGNoYW5nZWQ/DQo+PiBCdXQgdGhhdCdzIHRoZSBjb3JlIHBy b2JsZW0gd2UnbGwgaGF2ZSB0byBzb2x2ZS4gVGhpcyBkcmFmdCBhaW1zIHNwZWNpZmljYWxseSBh dCByZW1vdmluZyB0aGUgZXh0cmEgZW5jYXBzdWxhdGlvbiB0aGF0IGNvbnN1bWVzIG9jdGV0cyBh bmQgdGhlcmVieSBiYXR0ZXJ5Lg0KPk9LLCBzb21laG93IHRoaXMgd2FzIHN0aWxsIG5vdCB2ZXJ5 IGNsZWFyIHRvIG1lLiBJIHRoaW5rIG1heWJlIHNvbWUgZGlhZ3JhbXMgZm9yIHRoZSBub24tUlBM LWV4cGVydCBhcmUgbmVlZGVkLg0KID5JIHRyeSB0byBhdm9pZCBiZWluZyBkb2N0cmluYWlyZTsg YWxsIEkgY2FuIHRlbGwgeW91IGlzIHRoZSBtb2RlbHMgd2UgcHJvcG9zZWQgaW4gNm1hbiB3aGlj aCBpbnZvbHZlZCByZXdyaXRpbmcgdGhlIGZsb3cgbGFiZWwgYXQgZG9tYWluIGJvdW5kYXJpZXMg d2VyZSB2ZXJ5IHVucG9wdWxhci4NCg0KW1Bhc2NhbF0gVGhpcyBpcyBNVUNIIGFwcHJlY2lhdGVk LCBCcmlhbi4gDQoNCj5Zb3Ugc2hvdWxkIHByb2JhYmx5IGxvb2sgYXQgZHJhZnQtY2FycGVudGVy LTZtYW4tZmxvdy11cGRhdGUtMDNbXSAgKGFuZCBvbmx5IHRoZSAtMDMgdmVyc2lvbikuIEkgdGhp bmsgdGhhdCB3b3VsZCBoYXZlIGFsbG93ZWQgd2hhdCB5b3Ugd2FudCB0byBkbywgYnV0IGl0IHdh cyBmaXJtbHkgcmVqZWN0ZWQgYnkgNm1hbi4NCg0KPlRodXMgd2hhdCBJIGFtIGFib3V0IHRvIHNh eSBpcyBoZXJlc3k6IGFzIGxvbmcgYXMgdGhlIGZsb3cgbGFiZWxzIGVtZXJnaW5nIGZyb20gdGhl IFJQTCBkb21haW4gKmxvb2sqIGFzIGlmIHRoZSBzb3VyY2UgY29tcHV0ZXIgc2V0IGEgZmxvdyBs YWJlbCBwZXIgZmxvdyBjb25mb3JtYW50IHdpdGggUkZDIDY0MzcsIGl0IHNob3VsZCBiZSBPSy4N Cg0KPkV4Y2VwdCBmb3IgdGhpcyBjb21wbGljYXRpb246IGluIHRoZSB3b3JsZCBvZiBzZXJ2ZXIg bG9hZCBiYWxhbmNpbmcsIHRoZXJlIGlzIHNvbWUgaW50ZXJlc3QgaW4gdXNpbmcgdGhlIHNhbWUg ZmxvdyBsYWJlbCBmb3IgbXVsdGlwbGUgdHJhbnNwb3J0IHNlc3Npb25zIGZyb20gdGhlIHNhbWUg Y2xpZW50LCBldmVuIGlmIHRoZSBjbGllbnQncyBJUCBhZGRyZXNzIGNoYW5nZXMgZHVlIHRvIG1v YmlsaXR5LiBUaGlzIGlzIHN0aWxsIHByZXR0eSBzcGVjdWxhdGl2ZSwgYnV0IGl0IHJlYWxseSBk b2VzIHJlcXVpcmUgdGhlIHNvdXJjZSBub2RlIHRvIGhhdmUgY29udHJvbCBvdmVyIHRoZSBmaW5h bCB2YWx1ZSBvZiB0aGUgZmxvdyBsYWJlbC4NCg0KW1Bhc2NhbF0gSSBhZGRlZCB0ZXh0IGFuZCBw dWJsaXNoZWQgMDEgcGVyIG91ciBkaXNjdXNzaW9ucy4gVGhlIHRleHQgaW5kaWNhdGVzIHRoYXQg dGhlIFJQTCBvcHRpb24gaXMgc3RpbGwgYW4gb3B0aW9uLiBUaGlzIGlzIHRydWUgaW4gcGFydGlj dWxhciB3aGVuIHRoZSBmbG93IGxhYmVsIGFzIGFub3RoZXIgdXNhZ2Ugb3IgaWYgdGhlIHBhcnQg b2YgdGhlIFJhbmsgdGhhdCBpcyBtZWFuaW5nZnVsIHRvIGVzdGFibGlzaCB0aGUgcGF0aCBjb25z aXN0ZW5jeSBjYW5ub3QgYmUgY29tcHJlc3NlZCBpbiBvbmUgb2N0ZXQuDQoNClRoYW5rcyBhIGJ1 bmNoIGZvciBhbGw7DQoNCg0KUGFzY2FsDQo+IA0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBCcmlhbiBFIENhcnBlbnRlciBbbWFpbHRvOmJyaWFuLmUuY2FycGVudGVyQGdt YWlsLmNvbV0NCj4gU2VudDogbWFyZGkgOCBtYWkgMjAxMiAxMTo1Mw0KPiBUbzogUGFzY2FsIFRo dWJlcnQgKHB0aHViZXJ0KQ0KPiBDYzogcm9sbEBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogSS1E IEFjdGlvbjogZHJhZnQtdGh1YmVydC1yb2xsLWZsb3ctbGFiZWwtMDAudHh0DQo+IA0KPiBPbiAy MDEyLTA1LTA3IDEzOjU5LCBQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIHdyb3RlOg0KPj4gSGkg QnJpYW46DQo+Pg0KPj4+IElNSE8gdGhlcmUgYXJlIHByb2JsZW1zIHdpdGggdGhpcyBwcm9wb3Nh bC4gT25lIGlzIHRoYXQgaXQgZG9lc24ndCwgDQo+Pj4gYXMgZmFyIGFzIEkgY2FuIHNlZSwgZGVt b25zdHJhdGUgdGhhdCB0aGUgb3ZlcmhlYWQgb2YgcmV3cml0aW5nIHRoZSANCj4+PiBmbG93IGxh YmVsIG9uIGV4aXQgZnJvbSBhbiBSUEwgZG9tYWluIGlzIHNpZ25pZmljYW50bHkgbGVzcyB0aGFu IHRoZSANCj4+PiBvdmVyaGVhZCBvZiBkZWFsaW5nIHdpdGggdGhlIFJQTCBob3AtYnktaG9wIG9w dGlvbiBhdCB0aGUgZWRnZSBvZiANCj4+PiB0aGUgZG9tYWluLg0KPj4gW1Bhc2NhbF0gVGhlIG92 ZXJoZWFkIGlzIG1haW5seSBmb3IgcGFja2V0cyBjb21pbmcgZnJvbSB0aGUgb3V0c2lkZSANCj4+ IGludG8gdGhlIFJQTCBkb21haW4uIFN1Y2ggcGFja2V0cyBuZWVkIGV4dHJhIGVuY2Fwc3VsYXRp b24gdGhhdCdzIA0KPj4gZGV0cmltZW50YWwgZm9yIGJhdHRlcmllcyBhbmQgbWF5IGNhdXNlIGEg c21hbGwgcGFja2V0IHRvIGdyb3cgYWJvdmUgDQo+PiB0aGUgTUFDIE1heCBGcmFtZSwgbGVhZGlu ZyB0byBMMiBvciA2TG9XUEFOIGZyYWdtZW50YXRpb24uDQo+IA0KPiBJZiB5b3UgY2FuIGV4cGxh aW4gdGhpcyBpbiBhIGZldyB3b3JkcyBpbiB0aGUgdGV4dCwgaXQgd2lsbCBiZSBmaW5lLg0KPiAN Cj4+IFRoZW4sIHRoaXMgcGhyYXNlOg0KPj4NCj4+PiBTYWRseSwgdGhlIE9wdGlvbiBtdXN0IGJl IHBsYWNlZCBpbiBhIEhvcC1ieS1Ib3Agb3B0aW9uIHRoYXQgbXVzdCBiZSANCj4+PiBpbnNlcnRl ZCBvciByZW1vdmVkIGFzIHRoZSBwYWNrZXQgY3Jvc3NlcyB0aGUgYm9yZGVyIG9mIHRoZSBSUEwg DQo+Pj4gZG9tYWluLg0KPj4gYm90aGVycyBtZSwgYmVjYXVzZSAoYW5kIEkgaGF2ZSBsb29rZWQg cmVjZW50bHkpIHRoZXJlIGlzIG5vdGhpbmcgaW4gDQo+PiB0aGUgSVB2NiBzcGVjcyB0aGF0IGFs bG93cyBmb3IgYW4gZXh0ZW5zaW9uIGhlYWRlciBiZWluZyBpbnNlcnRlZCAob3INCj4+IHJlbW92 ZWQpIGVuIHJvdXRlLiBUaGUgdGV4dCBjb250aW51ZXMNCj4+DQo+PiBbUGFzY2FsXSBJJ2xsIHJl d29yZCB0byBpbmRpY2F0ZSB0aGF0IHRoZSBvcGVyYXRpb24gb2YgaW5zZXJ0aW5nIC8gDQo+PiBy ZW1vdmluZyB0aGUgSGJIIGhlYWRlciBjb21lcyB3aXRoIDZpbjYuIFJGQyA2NTUzIHNheXM6ICIg V2hlbiB0aGUgDQo+PiByb3V0ZXIgaXMgdGhlIHNvdXJjZSBvZiB0aGUgb3JpZ2luYWwgcGFja2V0 IGFuZCB0aGUgZGVzdGluYXRpb24gaXMgDQo+PiBrbm93biB0byBiZSB3aXRoaW4gdGhlIHNhbWUg UlBMIEluc3RhbmNlLCB0aGUgcm91dGVyIFNIT1VMRCBpbmNsdWRlIA0KPj4gdGhlIFJQTCBPcHRp b24gZGlyZWN0bHkgd2l0aGluIHRoZSBvcmlnaW5hbCBwYWNrZXQuIE90aGVyd2lzZSwgDQo+PiBy b3V0ZXJzIE1VU1QgdXNlIElQdjYtaW4tSVB2NiB0dW5uZWxpbmcgW1JGQzI0NzNdIGFuZCBwbGFj ZSB0aGUgUlBMIA0KPj4gT3B0aW9uIGluIHRoZSB0dW5uZWwgaGVhZGVyLiAgVXNpbmcgSVB2Ni1p bi1JUHY2IHR1bm5lbGluZyBlbnN1cmVzIA0KPj4gdGhhdCB0aGUgZGVsaXZlcmVkIGRhdGFncmFt IHJlbWFpbnMgdW5tb2RpZmllZCBhbmQgdGhhdCBJQ01QdjYgZXJyb3JzIA0KPj4gZ2VuZXJhdGVk IGJ5IGEgUlBMIE9wdGlvbiBhcmUgc2VudCBiYWNrIHRvIHRoZSByb3V0ZXIgdGhhdCBnZW5lcmF0 ZWQgDQo+PiB0aGUgUlBMIE9wdGlvbi4iDQo+IA0KPiBZZXMsIEkgaGFkIHRvIHJlYWQgcXVpdGUg ZGVlcGx5IGludG8gNjU1MyB0byB1bmRlcnN0YW5kIHRoaXMuIEkgdGhpbmsgeW91ciBkcmFmdCB3 aWxsIGJlIHJlYWQgYnkgcGVvcGxlIHdpdGhvdXQgZGV0YWlsZWQga25vd2xlZGdlIG9mIFJQTCBz byBpdCBuZWVkcyB0byBiZSBleHBsYWluZWQuDQo+IA0KPj4+IC4uLlRoaXMgb3BlcmF0aW9uIG1h eSBpbnZvbHZlIGFuIGV4dHJhIGVuY2Fwc3VsYXRpb24gdGhhdCBpcyANCj4+PiBkZXRyaW1lbnRh bCB0byB0aGUgbmV0d29yayBvcGVyYXRpb24sIGluIHBhcnRpY3VsYXIgd2l0aCByZWdhcmRzIHRv IA0KPj4+IGJhbmR3aWR0aCBhbmQgYmF0dGVyeSBjb25zdHJhaW50cy4NCj4+IFdoeSAibWF5Ij8g SWYgdGhlIHBhY2tldCBpcyBpbmJvdW5kIHRvIFJQTCwgUkZDIDY1NTMgbWFrZXMgaXQgY2xlYXIg DQo+PiB0aGF0IGl0IG11c3QgYmUgZW5jYXBzdWxhdGVkOyBpZiB0aGUgcGFja2V0IGlzIG91dGJv dW5kLCB3aHkgd291bGQgaXQgDQo+PiBiZSBlbmNhcHN1bGF0ZWQgYXQgYWxsPyBUaGlzIGNhc2Ug aXMgY292ZXJlZCBpbiB0aGUgUkZDIHRvbzoNCj4+DQo+PiBbUGFzY2FsXSBJIHdyb3RlICJtYXki IGZyb20gdGhlIGZhY3QgdGhhdCB0aGUgcGFja2V0IG1heSBiZSBpc3N1ZWQgDQo+PiBhbmQgY29u c3VtZWQgd2l0aGluIHRoZSBSUEwgZG9tYWluIGluIHdoaWNoIGNhc2UgdGhlIG9wdGlvbiBpcyAN Cj4+IGNvbnNlcnZlZCBhbGwgdGhlIHdheSBhbmQgdGhlcmUgaXMgbm8gNmluNiBlbmNhcHN1bGF0 aW9uLiBCdXQgSSBhZ3JlZSANCj4+IHRoZSBvcGVyYXRpb24gYWJvdmUgZG9lcyBjb21lIHdpdGgg NmluNi4NCj4gDQo+IE9LDQo+IA0KPj4+IDMuICBEYXRhZ3JhbXMgZGVzdGluZWQgdG8gbm9kZXMg b3V0c2lkZSB0aGUgUlBMIEluc3RhbmNlIGFyZSBkcm9wcGVkIA0KPj4+IGlmIHRoZSBvdXRlcm1v c3QgSVB2NiBoZWFkZXIgY29udGFpbnMgYSBSUEwgT3B0aW9uIG5vdCBnZW5lcmF0ZWQgYnkgDQo+ Pj4gdGhlIFJQTCByb3V0ZXIgZm9yd2FyZGluZyB0aGUgZGF0YWdyYW0uDQo+PiBUaGVuLCB0aGUg ZHJhZnQgc2F5czoNCj4+DQo+Pj4gVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgaG93IHRoZSBGbG93 IExhYmVsIGNhbiBiZSByZXVzZWQgd2l0aGluIHRoZSANCj4+PiBSUEwgZG9tYWluIGFzIGEgcmVw bGFjZW1lbnQgdG8gdGhlIFJQTCBvcHRpb24uICBUaGUgdXNlIG9mIHRoZSBGbG93IA0KPj4+IExh YmVsIHdpdGhpbiBhIFJQTCBkb21haW4gaXMgYW4gaW5zdGFuY2Ugb2YgdGhlIHN0YXRlZnVsIHNj ZW5hcmlvcyANCj4+PiBkZWNyaWJlZCBpbiBbUkZDNjQzN10uLi4NCj4+IEluIGZhY3QgUkZDIDY0 MzcgY2FyZWZ1bGx5IHNheXMgdmVyeSBsaXR0bGUgYWJvdXQgc3RhdGVmdWwgc2NlbmFyaW9zOyAN Cj4+IGl0IGRvZXMgbm90IGRlc2NyaWJlIHRoZW0sIGJ1dCBpdCBkb2VzIGNvbnN0cmFpbiB0aGVt LiBIZXJlIGlzIHRoZSANCj4+IGVudGlyZSBzZWN0aW9uIG9uIHRoaXMgdG9waWM6DQo+Pg0KPj4g W1Bhc2NhbF0gd2hhdCBhYm91dCB0aGUgd29yZCAiaW50cm9kdWNlZCIsIG9yICJkaXNjdXNzZWQi Pw0KPiANCj4gT0sNCj4gDQo+Pj4gNC4gIEZsb3cgU3RhdGUgRXN0YWJsaXNobWVudCBSZXF1aXJl bWVudHMNCj4+Pg0KPj4+IEEgbm9kZSB0aGF0IHNldHMgdGhlIGZsb3cgbGFiZWwgTUFZIGFsc28g dGFrZSBwYXJ0IGluIGEgZmxvdyBzdGF0ZSANCj4+PiBlc3RhYmxpc2htZW50IG1ldGhvZCB0aGF0 IHJlc3VsdHMgaW4gYXNzaWduaW5nIHNwZWNpZmljIHRyZWF0bWVudHMgDQo+Pj4gdG8gc3BlY2lm aWMgZmxvd3MsIHBvc3NpYmx5IGluY2x1ZGluZyBzaWduYWxpbmcuICBBbnkgc3VjaCBtZXRob2Qg DQo+Pj4gTVVTVCBOT1QgZGlzdHVyYiBub2RlcyB0YWtpbmcgcGFydCBpbiB0aGUgc3RhdGVsZXNz IHNjZW5hcmlvIGp1c3QgDQo+Pj4gZGVzY3JpYmVkLiAgVGh1cywgYW55IG5vZGUgdGhhdCBzZXRz IGZsb3cgbGFiZWwgdmFsdWVzIGFjY29yZGluZyB0byANCj4+PiBhIHN0YXRlZnVsIHNjaGVtZSBN VVNUIGNob29zZSBsYWJlbHMgdGhhdCBjb25mb3JtIHRvIFNlY3Rpb24gMyBvZiANCj4+PiB0aGlz IHNwZWNpZmljYXRpb24uICBGdXJ0aGVyIGRldGFpbHMgYXJlIG5vdCBkaXNjdXNzZWQgaW4gdGhp cyBkb2N1bWVudC4NCj4+PiBUaGUgcHJvYmxlbSBpcyB0aGF0IHNlY3Rpb24gMyBpbnRlbnRpb25h bGx5IGRvZXMgbm90IGNvbnNpZGVyIGZsb3cgDQo+Pj4gbGFiZWwgdmFsdWVzIGluIHdoaWNoIGFu eSBvZiB0aGUgYml0cyBoYXZlIHNlbWFudGljIHNpZ25pZmljYW5jZSwgDQo+Pj4gYW5kIHRoaXMg d2FzIHRoZSBjb25zZW5zdXMgaW4gdGhlIDZNQU4gV0cgYWZ0ZXIgYSBncmVhdCBkZWFsIG9mIA0K Pj4+IGRpc2N1c3Npb24uIEhvd2V2ZXIsIHRoZSAgcHJlc2VudCBwcm9wb3NhbCBhc3NpZ25zIHNl bWFudGljcyB0byANCj4+PiB2YXJpb3VzIGJpdHMgaW4gdGhlIGZsb3cgbGFiZWwsIGRlc3Ryb3lp bmcgaXRzIGRlc2lyZWQgcHJvcGVydHkgb2YgDQo+Pj4gYmVsb25naW5nIHRvIGEgc3RhdGlzdGlj YWxseSB1bmlmb3JtIGRpc3RyaWJ1dGlvbi4NCj4+IFtQYXNjYWxdIFRoYXQgaXMgdHJ1ZSB3aXRo aW4gdGhlIGVkZ2UgbmV0d29yayB0aGF0IGlzIHRoZSBSUEwgZG9tYWluLg0KPj4gQnV0IG91dHNp ZGUgdGhlIFJQTCBkb21haW4gdGhlIGRlc2lyZWQgcHJvcGVydGllcyBhcmUgY29uc2VydmVkLiBU aGUgDQo+PiByYXRpb25hbGUgZm9yIHRoZSBzdGF0aXN0aWNhbGx5IHVuaWZvcm0gZGlzdHJpYnV0 aW9uIGRvZXMgbm90IA0KPj4gbmVjZXNzYXJpbHkgYnJpbmcgYSBsb3Qgb2YgdmFsdWUgd2l0aGlu IHRoZSBMTE4uIE9uIHRoZSBvdGhlciBoYW5kLCANCj4+IHRoZSA2aW42IGVuY2FwcyBhbmQgSGJI IGhlYWRlciBhcmUgaHVnZWx5IGRldHJpbWVudGFsIHRvIHRoZSANCj4+IG9wZXJhdGlvbnMgYW5k IHdpbGwgcmVzdWx0IGlzIHNob3J0ZXIgYmF0dGVyeSBsaWZlIGFuZCByZWR1Y2VkIA0KPj4gYXBw bGljYWJpbGl0eS4gSSBwYXJ0aWNpcGF0ZWQgYXMgYSBjb2VkaXRvciB0byB0aGUgSVNBMTAwLjEx YSANCj4+IHN0YW5kYXJkIHRoYXQgYWN0dWFsbHkgdXNlcyBJUHY2IGluIHRoZSA2TG9XUEFOIEhD IGZvcm0uIEkndmUgc2VlbiANCj4+IGhvdyB0aGUgYWRvcHRpb24gb2YgSVB2NiB3YXMgYXQgc3Rh a2UgZm9yIGEgc2luZ2xlIGFkZGl0aW9uYWwgb2N0ZXQgDQo+PiBpbiBhIGhlYWRlciwgYW5kIHRo aXMgYWN0dWFsbHkgbGVkIHRvIGNoYW5nZXMgYXQgdGhlIElFVEYgYW5kIHRoZSBuZXcgDQo+PiA2 TG9XUEFOIEhDLiBJbmRlZWQsIHVubGVzcyB5b3UgaGF2ZSBhIHBvd2VyIHNvdXJjZSwgZXZlcnkg b2N0ZXQgdGhhdCANCj4+IHlvdSBoYXZlIHRvIHBsYWNlIGl0IGluIGV2ZXJ5IGZyYW1lIG9yIHBh Y2tldCBpbiB0aGUgTExOIGNvdW50cyANCj4+IGRlYXJseS4NCj4gDQo+IEkgdW5kZXJzdGFuZCB0 aGF0LCBidXQgdGhlcmUgd2FzIGEgc3Ryb25nIGZlZWxpbmcgaW4gNk1BTiB0aGF0IHRoZSBmbG93 IGxhYmVsIHNob3VsZCBiZSBhbiBlbmQtdG8tZW5kIGZpZWxkIChldmVuIHRob3VnaCB0aGF0IGlz IHVuZW5mb3JjZWFibGUpLg0KPiBJZiB5b3UgY2FuIG1ha2UgaXQgY2xlYXIgdGhhdCB0aGUgZmxv dyBsYWJlbCBpbiB5b3VyIG1vZGVsIHJlZmVycyBvbmx5IHRvIHRoZSBsYWJlbCBvZiB0aGUgZW5j YXBzdWxhdGluZyBwYWNrZXQsIGFuZCB0aGF0IGFueSBmbG93IGxhYmVsIHNldCBieSB0aGUgc291 cmNlIGhvc3QgaW4gdGhlIGlubmVyIHBhY2tldCBpcyBub3QgY2hhbmdlZCwgaXQgd2lsbCBiZSBm aW5lLg0KPiBUaGF0J3MgdGhlIHNhbWUgbW9kZWwgYXMgUkZDIDY0MzggKGZsb3cgbGFiZWxzIGZv ciBFQ01QL0xBRyB0dW5uZWxzKS4NCj4gDQo+Pj4gVGhlIGlzc3VlIGlzIGNsZWFybHkgc3RhdGVk IGluIFJGQyA2NDM3Og0KPj4+IE9uY2Ugc2V0IHRvIGEgbm9uLXplcm8gdmFsdWUsIHRoZSBGbG93 IExhYmVsIGlzIGV4cGVjdGVkIHRvIGJlIA0KPj4+IGRlbGl2ZXJlZCB1bmNoYW5nZWQgdG8gdGhl IGRlc3RpbmF0aW9uIG5vZGUocykuICBBIGZvcndhcmRpbmcgbm9kZSANCj4+PiBNVVNUIGVpdGhl ciBsZWF2ZSBhIG5vbi16ZXJvIGZsb3cgbGFiZWwgdmFsdWUgdW5jaGFuZ2VkIG9yIGNoYW5nZSBp dCANCj4+PiBvbmx5IGZvciBjb21wZWxsaW5nIG9wZXJhdGlvbmFsIHNlY3VyaXR5IHJlYXNvbnMg YXMgZGVzY3JpYmVkIGluIA0KPj4+IFNlY3Rpb24gNi4xLg0KPj4gW1Bhc2NhbF0gIFdlIGhhdmUg YSBjb21wZWxsaW5nIG9wZXJhdGlvbmFsIHJlYXNvbiBmb3Igc3VyZSwgYmVjYXVzZSANCj4+IHRo ZSBwb3dlciBjb25zdW1wdGlvbiBpcyB0aGUgbnVtYmVyIG9uZSBjcml0aWNhbCBjb25zdHJhaW50 IHRoYXQgDQo+PiBkcml2ZXMgbW9zdCBvZiB0aGUgcGh5c2ljYWwgZGVzaWduIGNob2ljZXMgaW4g YSBMTE4gd2hlcmUgYSBiYXR0ZXJ5IA0KPj4gbGlmZSBtdXN0IG9mdGVuIGV4cHJlc3NlZCBpbiB5 ZWFycy4gIEknbSB1bmNsZWFyLCB0aG91Z2gsIHdoeSBSRkMNCj4+IDY0Mzcgd2VudCBhcyBmYXIg YXMgaW5kaWNhdGluZyB0aGF0IHRoZSBjb21wZWxsaW5nIHJlYXNvbiBzaG91bGQgYmUgDQo+PiBx dWFsaWZpZWQgYXMgc2VjdXJpdHkuDQo+IA0KPiBCZWNhdXNlIHRoZSBmaXJld2FsbCBwZW9wbGUg aGFkIGFscmVhZHkgbWFkZSBpdCB2ZXJ5IGNsZWFyIHRoYXQgd2hhdGV2ZXIgd2Ugd3JvdGUgaW4g YW4gUkZDLCBmaXJld2FsbHMgaW4gc2Vuc2l0aXZlIGFwcGxpY2F0aW9ucyB3b3VsZCB0cmVhdCB0 aGUgZmxvdyBsYWJlbCBhcyBhIGNvdmVydCBjaGFubmVsIHJpc2suIEFwYXJ0IGZyb20gdGhhdCwg YXMgbm90ZWQgYWJvdmUsIHRoZSBXRyB3YW50ZWQgdG8gaW5zaXN0IG9uIHRoZSBlbmQgdG8gZW5k IHByb3BlcnR5IG9mIHRoZSBsYWJlbC4NCj4gDQo+PiBJIHRha2UgdGhhdCBhcyBhbiBpbmRpY2F0 aW9uIG9mIGNyaXRpY2FsaXR5IGFzIG9wcG9zZWQgdG8gYSB0ZW50YXRpdmUgDQo+PiB0byBwcmVk aWN0IGZ1dHVyZSBuZWVkcy4gSXQgbWFrZXMgc2Vuc2UgdG8gbWUgdG8gYWRkIGluIHRoZSBkcmFm dCANCj4+IHRoYXQgInRoZSBzb3VyY2UgaW4gdGhlIExMTiBTSE9VTEQgc2V0IHRoZSBGbG93IGxh YmVsIHRvIHplcm8gYW5kIA0KPj4gTVVTVCBOT1QgZXhwZWN0IHRoYXQgdGhlIGZsb3cgbGFiZWwg d2lsbCBiZSBjb25zZXJ2ZWQgZW5kIHRvIGVuZCBpZiANCj4+IGl0IGtub3dzIGJ5IHBvbGljeSB0 aGF0IHRoZSBMTE4gd2lsbCB1c2UgdGhpcyBkcmFmdCIuIFdvdWxkIHRoYXQgYmUgDQo+PiBzdWZm aWNpZW50IHRvIGFsbGV2aWF0ZSB0aGlzIGNvbmNlcm4/DQo+IA0KPiBJZiB3ZSBhcmUgdGFsa2lu ZyBhYm91dCB0aGUgZW5jYXBzdWxhdGluZyBwYWNrZXQsIHN1cmUuIElzIHRoZXJlIGFueSByZWFz b24gdGhhdCB0aGUgbGFiZWwgaW4gdGhlIHJhdyBwYWNrZXQgd291bGQgYmUgY2hhbmdlZD8NCj4g DQo+ICAgIEJyaWFuDQo+IA0KPj4gQW5kIHllcywgSSB3aWxsIGNlcnRhaW5seSBrZWVwIHlvdSBD Q2VkLCBhbmQgQ0MgeW91IGlmIG90aGVyIHRocmVhZHMgDQo+PiBwb3AgdXAgb24gdGhlIHN1Ympl Y3QgaW4gUk9MTCwgaWYgeW91IGRvIG5vdCBtaW5kOw0KPj4NCj4+IFBhc2NhbA0K From mcr@sandelman.ca Wed May 9 12:53:14 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F326521F8552 for ; Wed, 9 May 2012 12:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.658 X-Spam-Level: X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[AWL=0.296, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rs9xrC32xd5e for ; Wed, 9 May 2012 12:53:13 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 207CD21F8549 for ; Wed, 9 May 2012 12:53:12 -0700 (PDT) Received: from sandelman.ca (wlan203.sandelman.ca [209.87.252.203]) by relay.sandelman.ca (Postfix) with ESMTPS id 2575F8B3D; Wed, 9 May 2012 15:52:08 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id A87BC98B98; Wed, 9 May 2012 15:53:10 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A22BB98470; Wed, 9 May 2012 15:53:10 -0400 (EDT) From: Michael Richardson To: Mukul Goyal In-Reply-To: <326961085.315388.1336495338781.JavaMail.root@mail17.pantherlink.uwm.edu> References: <326961085.315388.1336495338781.JavaMail.root@mail17.pantherlink.uwm.edu> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 09 May 2012 15:53:10 -0400 Message-ID: <20077.1336593190@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-12.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 19:53:14 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mukul" =3D=3D Mukul Goyal writes: Mukul> This version includes the correct IANA-related text that Mukul> resolves ticket #88 recently reopened by Michael. Thank you! =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT6rLJoqHRg3pndX9AQKyugP9FChEvgFNSaYlwOc4rWULLs2aC66sfogW 9lW93kgwonu/gJHR7/+Ji5UwlxC9kX4+BR5UPtAVvBebiqmNAbrk84iQ71OKCylu UkE09OsHoLLrFpO1d59lwmE2qq56JVsv3vD/hqMHgmI84ejNStO16MPeUPwUuSfU TGjQhOfPJCA= =47am -----END PGP SIGNATURE----- --=-=-=-- From internet-drafts@ietf.org Wed May 9 16:11:01 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7376D11E80F3; Wed, 9 May 2012 16:11:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.534 X-Spam-Level: X-Spam-Status: No, score=-102.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kJLxXXHK0bsZ; Wed, 9 May 2012 16:11:01 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055BB11E8086; Wed, 9 May 2012 16:11:01 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.02 Message-ID: <20120509231101.21771.66331.idtracker@ietfa.amsl.com> Date: Wed, 09 May 2012 16:11:01 -0700 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 23:11:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy netw= orks Working Group of the IETF. Title : A Mechanism to Measure the Quality of a Point-to-point R= oute in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-05.txt Pages : 20 Date : 2012-05-09 This document specifies a mechanism that enables an RPL router to measure the quality of an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement/ From prvs=469d6a882=mukul@uwm.edu Wed May 9 16:27:21 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE1811E80AA for ; Wed, 9 May 2012 16:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.517 X-Spam-Level: X-Spam-Status: No, score=-6.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8bzCTFgWKGZ for ; Wed, 9 May 2012 16:27:20 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 4CE1611E8086 for ; Wed, 9 May 2012 16:27:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAOn8qk9/AAAB/2dsb2JhbABEhXWrLAGFMAEBAQQBAQEgSwsMDxEEAQEDAg0ZAikoCAYTCYgFC6g/iW2JCYEviV0cCYRsgRgEiGSNGZBBgwc Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id F09D22B3EF9; Wed, 9 May 2012 18:27:17 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta04.pantherlink.uwm.edu Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38JU8oi0Ilxa; Wed, 9 May 2012 18:27:17 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 951BC2B3F01; Wed, 9 May 2012 18:27:17 -0500 (CDT) Date: Wed, 9 May 2012 18:27:18 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <383072227.341881.1336606038097.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20120509231101.21771.66331.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 May 2012 23:27:21 -0000 This version takes care of ticket #98 (created in response to LC comment by Phil Levis) and has the following changes: 1) Updated the overview section. This section now has better explanation of the mechanism and explicitly clarifies the following: 1.1) The route being measured is from the origin to the target. 1.2) The origin decides what metrics are measured. 2) Section 4 (Originating a Measurement Request) now clearly says: "The Origin MUST also include the routing metric objects of interest inside one or more Metric Container options inside the MO. " 3) Section 5 (Processing a Measurement Request at an Intermediate Router) now clearly says: "An Intermediate Router can only update the existing metric objects and MUST NOT add any new routing metric object to the Metric Container. An Intermediate Router MUST drop the MO if it cannot update a routing metric object specified inside the Metric Container." 4) Updated the IANA section to include the correct language as per RFC5226. These modifications should remove the perceived ambiguity (regarding who decides which metrics would be measured) reported in Ticket #98. Thanks Mukul ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Wednesday, May 9, 2012 6:11:01 PM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-05.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-05.txt Pages : 20 Date : 2012-05-09 This document specifies a mechanism that enables an RPL router to measure the quality of an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-05.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Wed May 9 17:31:42 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5520111E80AA for ; Wed, 9 May 2012 17:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.407 X-Spam-Level: X-Spam-Status: No, score=-6.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qu5t8p3ucM4S for ; Wed, 9 May 2012 17:31:41 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by ietfa.amsl.com (Postfix) with ESMTP id B37E721F844D for ; Wed, 9 May 2012 17:31:41 -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.76) (envelope-from ) id 1SSHIB-0004Ds-KO; Wed, 09 May 2012 17:31:40 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <383072227.341881.1336606038097.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Wed, 9 May 2012 17:31:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <383072227.341881.1336606038097.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 6c66c47a22907c63296a3ecdec1f9d62 Cc: roll Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-05.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 May 2012 00:31:42 -0000 The new draft addresses all of my comments. The overview section is much = clearer and unambiguous. Phil On May 9, 2012, at 4:27 PM, Mukul Goyal wrote: > This version takes care of ticket #98 (created in response to LC = comment by Phil Levis) and has the following changes: >=20 > 1) Updated the overview section. This section now has better = explanation of the mechanism and explicitly clarifies the following: > 1.1) The route being measured is from the origin to the target. > 1.2) The origin decides what metrics are measured. >=20 > 2) Section 4 (Originating a Measurement Request) now clearly says: >=20 > "The Origin MUST also include the routing metric objects of > interest inside one or more Metric Container options inside the MO. > " >=20 > 3) Section 5 (Processing a Measurement Request at an Intermediate = Router) now clearly says: >=20 > "An Intermediate Router can > only update the existing metric objects and MUST NOT add any new > routing metric object to the Metric Container. An Intermediate > Router MUST drop the MO if it cannot update a routing metric object > specified inside the Metric Container." >=20 > 4) Updated the IANA section to include the correct language as per = RFC5226. >=20 > These modifications should remove the perceived ambiguity (regarding = who decides which metrics would be measured) reported in Ticket #98.=20 >=20 > Thanks > Mukul=20 > ----- Original Message ----- > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Sent: Wednesday, May 9, 2012 6:11:01 PM > Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-05.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. This draft is a work item of the Routing Over Low power and = Lossy networks Working Group of the IETF. >=20 > Title : A Mechanism to Measure the Quality of a = Point-to-point Route in a Low Power and Lossy Network > Author(s) : Mukul Goyal > Emmanuel Baccelli > Anders Brandt > Jerald Martocci > Filename : draft-ietf-roll-p2p-measurement-05.txt > Pages : 20 > Date : 2012-05-09 >=20 > This document specifies a mechanism that enables an RPL router to > measure the quality of an existing route towards another RPL router > in a low power and lossy network, thereby allowing the router to > decide if it wants to initiate the discovery of a better route. >=20 >=20 > A URL for this Internet-Draft is: > = http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-05.txt= >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > This Internet-Draft can be retrieved at: > = ftp://ftp.ietf.org/internet-drafts/draft-ietf-roll-p2p-measurement-05.txt >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement/ >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 Phil From ietf@thomasclausen.org Thu May 10 23:25:23 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADE0021F861F for ; Thu, 10 May 2012 23:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uHWO9uAgLW5B for ; Thu, 10 May 2012 23:25:23 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 028F821F861D for ; Thu, 10 May 2012 23:25:16 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 61AAAA6848 for ; Thu, 10 May 2012 23:25:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id DC8221C0889; Thu, 10 May 2012 23:25:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 2B1691C088B; Thu, 10 May 2012 23:25:14 -0700 (PDT) From: Thomas Heide Clausen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 11 May 2012 08:25:11 +0200 Message-Id: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> To: Jean-Philippe Vasseur , Michael Richardson Mime-Version: 1.0 (Apple Message framework v1257) X-Mailer: Apple Mail (2.1257) Cc: roll WG Subject: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 06:25:23 -0000 Dear JP, Michael, all Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented and = discussed at the Paris meeting. The authors consider the document complete and "done", and are looking = to take it forward in the IETF=20 process for publication as "Informational RFC" in the very near future.=20= We would therefore like to ask the WG chairs, if the ROLL WG is willing = to accept and progress this=20 document towards publication? Best, Thomas, Ulrich, Yuichi, Jiazi and Axel= From jpv@cisco.com Fri May 11 05:20:14 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A504B21F85F7 for ; Fri, 11 May 2012 05:20:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.328 X-Spam-Level: X-Spam-Status: No, score=-110.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQIF-CtNd7wN for ; Fri, 11 May 2012 05:20:13 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 351ED21F84EA for ; Fri, 11 May 2012 05:20:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=9416; q=dns/txt; s=iport; t=1336738813; x=1337948413; h=from:mime-version:subject:date:references:cc:to: message-id; bh=abb4eVOS01OK1OMlMyieYqn1cHnrFtyQVR3mnzBIczs=; b=J6NzHd3Rl1NKr6EdPcHN2P5tNbtwN7v6dx1Cf6oCzcSZHpk+XWvT/Fla lGnbRBORv60ah5xihsOu6FeHSheGIH9Cc2MLtM0AWD0ohbZoOUKdO4lsr uMraqRhtRK/d/MUQ660dubIEvY4NmkzUVHmDoDO5XT2pQpBUFkM/KykSR o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFALECrU+Q/khL/2dsb2JhbABEgx6uaYIdgQeCFQEBAQMBAQEBDwFbCwULHAMBAgEuJyYCCAYTCRmHZwULmnugGIsXJYUVYwSVfYV1iGKBaYJr X-IronPort-AV: E=Sophos;i="4.75,571,1330905600"; d="scan'208,217";a="72982208" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-2.cisco.com with ESMTP; 11 May 2012 12:20:12 +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 q4BCKCL0007895; Fri, 11 May 2012 12:20:12 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 May 2012 14:20:12 +0200 Received: from [10.60.114.227] ([10.60.114.227]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 May 2012 14:20:11 +0200 From: JP Vasseur Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_B6F824CF-7289-466A-A209-C74379EBCBD4" Date: Fri, 11 May 2012 14:20:10 +0200 References: <9850315F-B3E6-4A29-AAD5-B53E6C978F69@thomasclausen.org> To: roll WG Message-Id: <66E2061B-4866-4276-B69A-6FD150D6EB93@cisco.com> X-Mailer: Apple Mail (2.1257) X-OriginalArrivalTime: 11 May 2012 12:20:11.0556 (UTC) FILETIME=[69726640:01CD2F70] Cc: Michael Richardson Subject: [Roll] Fwd: RPL-P2P - status & update X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 May 2012 12:20:14 -0000 --Apple-Mail=_B6F824CF-7289-466A-A209-C74379EBCBD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear all, A first WG Last Call took place on March 16th on: * draft-ietf-roll-p2p-measurement-04 and=20 * draft-ietf-roll-p2p-rpl-09 Thanks to all of you for the fruitful and constructive comments received = during WG Last call, that led=20 to several tickets that have been successfully closed, leading to new = revisions of these documents. This starts a new 2-week WG last call on: * draft-ietf-roll-p2p-measurement-05 and=20 * draft-ietf-roll-p2p-rpl-12 The WG Last call will end on May 25th at noon ET. Please send your = comments on the mailing list and copy the authors. Thanks. JP and Michael. =20 Begin forwarded message: > From: Thomas Heide Clausen > Subject: Re: [Roll] RPL-P2P - status & update > Date: April 13, 2012 11:21:00 PM GMT+02:00 > To: JP Vasseur > Cc: "roll@ietf.org WG" >=20 > Dear JP, >=20 > Sounds quite reasonable. >=20 > Have a pleasant weekend you too - I will be spending mine recovering = from week-long meetings in the bay area... >=20 > Best, >=20 > Thomas >=20 > On Apr 13, 2012, at 14:16 , JP Vasseur wrote: >=20 >> Hi Thomas, >>=20 >> Clarifying a bit more =85 what I meant =85 >>=20 >> Plan is: >> * Close on the last open ticket >> * Authors will post a new revision of the document, possibly = highlighting the changes >> * Issue another WG LC to make sure that the WG is comfortable with = the new revision >>=20 >> Thanks, have a good week-end. >>=20 >> JP. >>=20 >> On Apr 13, 2012, at 9:03 PM, JP Vasseur wrote: >>=20 >>> Hi Thomas, >>>=20 >>> Absolutely, the plan was to run another incremental Last Call, on = the new revision. >>>=20 >>> Cheers. >>>=20 >>> JP. >>>=20 >>> On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen wrote: >>>=20 >>>> Hello folks, >>>>=20 >>>> I've been trying to follow the many mails exchanged as a = consequence of the WGLC of RPL-P2P. >>>>=20 >>>> Given the volume of changes to the document, I would like to ask = that - once the authors estimate that a version of the I-D folding in = all proposed changes is ready - the WG be given another 1-2 weeks WGLC = before bouncing it off to the ADs? >>>>=20 >>>> This just to ensure that the WG gets to give the final version a = good review before seeing it off. >>>>=20 >>>> Thoughts? >>>>=20 >>>> Thomas >>>>=20 >>>> --=20 >>>> Thomas Heide Clausen >>>> http://www.thomasclausen.org/ >>>>=20 >>>> "Any simple problem can be made insoluble if enough meetings are = held to >>>> discuss it." >>>> -- Mitchell's Law of Committees >>>>=20 >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 --Apple-Mail=_B6F824CF-7289-466A-A209-C74379EBCBD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = all,

A first WG Last Call took place on March 16th = on:
* draft-ietf-roll-p2p-measurement-04 and 
* = draft-ietf-roll-p2p-rpl-09

Thanks to all of you = for the fruitful and constructive comments received during WG Last call, = that led 
to several tickets that have been successfully = closed, leading to new revisions of these = documents.

This starts a new 2-week WG last = call on:
* draft-ietf-roll-p2p-measurement-05 = and 
* = draft-ietf-roll-p2p-rpl-12

The WG Last = call will end on May 25th at noon ET. Please send your = comments on the mailing list and copy the = authors.

Thanks.

JP = and Michael. =  


Begin = forwarded message:

From: Thomas Heide = Clausen <ietf@thomasclausen.org>
<= /span>
Subject: Re: [Roll] RPL-P2P - status & = update
Date: April 13, 2012 11:21:00 PM = GMT+02:00
To: JP Vasseur <jpv@cisco.com>

Dear = JP,

Sounds quite = reasonable.

Have a pleasant weekend you too - I = will be spending mine recovering from week-long meetings in the bay = area...

Best,

Thomas

On Apr 13, 2012, at 14:16 , JP Vasseur = wrote:

Hi = Thomas,

Clarifying a bit more =85 what I meant = =85

Plan is:
* Close on the last open = ticket
* Authors will post a new revision of the document, = possibly highlighting the changes
* Issue another WG LC to = make sure that the WG is comfortable with the new = revision

Thanks, have a good = week-end.

JP.

On Apr = 13, 2012, at 9:03 PM, JP Vasseur wrote:

Hi = Thomas,

Absolutely, the plan was to run another = incremental Last Call, on the new = revision.

Cheers.

JP.

On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen = wrote:

Hello folks,

I've been trying to follow the = many mails exchanged as a consequence of the WGLC of = RPL-P2P.

Given the volume of changes to the document, I would = like to ask that - once the authors estimate that a version of the I-D = folding in all proposed changes is ready - the WG be given another 1-2 = weeks WGLC before bouncing it off to the ADs?

This just to ensure = that the WG gets to give the final version a good review before seeing = it off.

Thoughts?

Thomas

--
Thomas Heide = Clausen
http://www.thomasclausen.org/
"Any simple problem can be made insoluble if enough meetings are = held to
discuss it."
  -- Mitchell's Law of = Committees

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

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



= --Apple-Mail=_B6F824CF-7289-466A-A209-C74379EBCBD4-- From gnawali@cs.uh.edu Fri May 11 12:59:01 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10D3E21F86CB for ; Fri, 11 May 2012 12:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.977 X-Spam-Level: X-Spam-Status: No, score=-7.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jwVk0Exqqiye for ; Fri, 11 May 2012 12:59:00 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8ECFE21F867E for ; Fri, 11 May 2012 12:59:00 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 7A9FA23CADC for ; Fri, 11 May 2012 14:59:00 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gesIcuCwhhB7 for ; Fri, 11 May 2012 14:58:58 -0500 (CDT) Received: from it.cs.uh.edu (it.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 9060423CAD9 for ; Fri, 11 May 2012 14:58:58 -0500 (CDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by it.cs.uh.edu (Postfix) with ESMTP id 06BA22A280C4 for ; Fri, 11 May 2012 15:30:24 -0500 (CDT) Received: by yenq13 with SMTP id q13so3651457yen.31 for ; Fri, 11 May 2012 12:58:57 -0700 (PDT) Received: by 10.236.78.37 with SMTP id f25mr8180761yhe.114.1336766337583; Fri, 11 May 2012 12:58:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.116.9 with HTTP; Fri, 11 May 2012 12:58:37 -0700 (PDT) In-Reply-To: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> From: Omprakash Gnawali Date: Fri, 11 May 2012 14:58:37 -0500 Message-ID: To: Thomas Heide Clausen Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2012 19:59:01 -0000 Sorry I was not able to attend the IETF meeting. Were there substantial comments for this document during the meeting? I looked at the minutes and the discussion related to this draft seems rather brief. - om_p On Fri, May 11, 2012 at 1:25 AM, Thomas Heide Clausen wrote: > Dear JP, Michael, all > > Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented and discussed at the Paris meeting. > > The authors consider the document complete and "done", and are looking to take it forward in the IETF > process for publication as "Informational RFC" in the very near future. > > We would therefore like to ask the WG chairs, if the ROLL WG is willing to accept and progress this > document towards publication? > > Best, > > Thomas, Ulrich, Yuichi, Jiazi and Axel > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Fri May 11 21:48:56 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02DFF21F85D8 for ; Fri, 11 May 2012 21:48:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.435 X-Spam-Level: X-Spam-Status: No, score=-7.435 tagged_above=-999 required=5 tests=[AWL=1.164, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jGQN2ViRUZzc for ; Fri, 11 May 2012 21:48:55 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by ietfa.amsl.com (Postfix) with ESMTP id 0E1A721F8454 for ; Fri, 11 May 2012 21:48:54 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.103]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1ST4GC-0002y8-Sy; Fri, 11 May 2012 21:48:53 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> Date: Fri, 11 May 2012 21:10:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3CB5FAC8-4F2A-4B6B-9024-23D4CCFDD5D6@cs.stanford.edu> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 2d1a4fa5d0150c38835749a59b44c419 Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 04:48:56 -0000 On May 10, 2012, at 11:25 PM, Thomas Heide Clausen wrote: > Dear JP, Michael, all >=20 > Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented = and discussed at the Paris meeting. >=20 > The authors consider the document complete and "done", and are looking = to take it forward in the IETF=20 > process for publication as "Informational RFC" in the very near = future.=20 >=20 > We would therefore like to ask the WG chairs, if the ROLL WG is = willing to accept and progress this=20 > document towards publication? >=20 > Best, >=20 > Thomas, Ulrich, Yuichi, Jiazi and Axel > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 As I alluded to in Paris, I don't really think this is currently a valid = informational document; the document it *should* be is guidelines on how = to implement RPL, not a description of a series of basic and naive = mistakes. Unless we want a companion document, which for each of the = issues raised says how to solve it. We wouldn't write an RFC on = someone's experience with congestion collapse after implementing a = transport protocol without congestion control. Just my 2c. Phil From pthubert@cisco.com Sat May 12 01:55:57 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABE821F863D for ; Sat, 12 May 2012 01:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.228 X-Spam-Level: X-Spam-Status: No, score=-11.228 tagged_above=-999 required=5 tests=[AWL=1.371, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKRemHLCGo9N for ; Sat, 12 May 2012 01:55:56 -0700 (PDT) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 2503421F8650 for ; Sat, 12 May 2012 01:55:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1314; q=dns/txt; s=iport; t=1336812956; x=1338022556; h=mime-version:content-transfer-encoding:subject:date: message-id:from:to:cc; bh=aupv/ctlTNyx2x8eq4qHzkZ2u8MpzafGN37JEKfj3qI=; b=KR3syfrdAtWxgT6B+0Ai4SixYcMMFzzgiQzSQ2fmNAPLfZZnAUNzGfDO nGCb2csKMfwVXMuX2ufMy0r5jrOUdSRNTshu/wH21DkifXO10G3RHLLcQ brSdQnaxlE57Ql7NaCJtcS11VA2c9xESVRb9Kshi79f45NhKDUxB5wltQ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABwVrk+Q/khR/2dsb2JhbABEs2+BB4IVAQEBBAEBAQ8BHQo0CwwGAQgRBAEBCwYXAQcmHwkJAQQBEggah2wLmxafXwSLGYUlYwSkVIFpgms X-IronPort-AV: E=Sophos;i="4.75,575,1330905600"; d="scan'208";a="73042284" Received: from ams-core-1.cisco.com ([144.254.72.81]) by ams-iport-2.cisco.com with ESMTP; 12 May 2012 07:52:49 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4C7qnhu029289; Sat, 12 May 2012 07:52:49 GMT Received: from xmb-ams-108.cisco.com ([144.254.74.83]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 12 May 2012 09:52:49 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sat, 12 May 2012 09:51:50 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Way forward for draft-clausen-lln-rpl-experiences Thread-Index: Ac0wFBYokAJ5BA02QlybRM6KPsGprw== From: "Pascal Thubert (pthubert)" To: "Thomas Heide Clausen" , "JP Vasseur (jvasseur)" , "Michael Richardson" X-OriginalArrivalTime: 12 May 2012 07:52:49.0159 (UTC) FILETIME=[39D8A170:01CD3014] Cc: roll WG Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 08:55:57 -0000 Hello Thomas: IMHO a useful document would describe a potential pitfall for an inexperienced developer or deployer, and then provide guidance, procons, etc. I can figure how this document could become useful in that fashion but I do not see that it is there yet. =20 Are you willing to take it farther with the WG, IOW produce text that the WG roughly agrees upon? Cheers, Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Thomas Heide Clausen Sent: vendredi 11 mai 2012 08:25 To: JP Vasseur (jvasseur); Michael Richardson Cc: roll WG Subject: [Roll] Way forward for draft-clausen-lln-rpl-experiences Dear JP, Michael, all Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented and discussed at the Paris meeting. The authors consider the document complete and "done", and are looking to take it forward in the IETF process for publication as "Informational RFC" in the very near future.=20 We would therefore like to ask the WG chairs, if the ROLL WG is willing to accept and progress this document towards publication? Best, Thomas, Ulrich, Yuichi, Jiazi and Axel _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From ietf@thomasclausen.org Sat May 12 02:50:15 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD9E21F8525 for ; Sat, 12 May 2012 02:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=1.521, BAYES_00=-2.599, GB_I_INVITATION=-2, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Irs3dH9Mdcx7 for ; Sat, 12 May 2012 02:50:15 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6B3A321F851E for ; Sat, 12 May 2012 02:50:15 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 2CEE455803C for ; Sat, 12 May 2012 02:50:15 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4CE3C1C0891; Sat, 12 May 2012 02:50:14 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.147.249] (mtg91-1-82-227-24-173.fbx.proxad.net [82.227.24.173]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id EB1F61C080D; Sat, 12 May 2012 02:50:13 -0700 (PDT) References: In-Reply-To: Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <8B7C71B4-4BFD-41D0-9AB7-C445782A8317@thomasclausen.org> X-Mailer: iPad Mail (9B206) From: Thomas Heide Clausen Date: Sat, 12 May 2012 11:50:40 +0200 To: "Pascal Thubert (pthubert)" Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 09:50:16 -0000 Hello Pascal, Thank you for your email, appreciate the time. On 12 May 2012, at 09:51, "Pascal Thubert (pthubert)" w= rote: > Hello Thomas: >=20 > IMHO a useful document would describe a potential pitfall for an > inexperienced developer or deployer, and then provide guidance, procons, > etc. > I can figure how this document could become useful in that fashion but I > do not see that it is there yet. =20 > Are you willing to take it farther with the WG, IOW produce text that > the WG roughly agrees upon? Feedback is - always - very welcomed enthusiastically, of course. I am not q= uite sure what you ask/suggest, but do let me know any and all suggestions. More generally, I am not sure that the direction you propose ("guidance to a= n inexperienced developer or deployer") is the right direction for the docum= ent. I actually believe that many of the issues, which draft-clausen-lln-rpl= -experiences describes, are well beyond what can be classified as "potential= pitfalls for an inexperienced developer or deployer", but rather are artifa= cts and consequences of the RPL protocol design choices, documented. And I t= hink that these need to be documented. Best, Thomas > Cheers, >=20 > Pascal >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Thomas Heide Clausen > Sent: vendredi 11 mai 2012 08:25 > To: JP Vasseur (jvasseur); Michael Richardson > Cc: roll WG > Subject: [Roll] Way forward for draft-clausen-lln-rpl-experiences >=20 > Dear JP, Michael, all >=20 > Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented and > discussed at the Paris meeting. >=20 > The authors consider the document complete and "done", and are looking > to take it forward in the IETF process for publication as "Informational > RFC" in the very near future.=20 >=20 > We would therefore like to ask the WG chairs, if the ROLL WG is willing > to accept and progress this document towards publication? >=20 > Best, >=20 > Thomas, Ulrich, Yuichi, Jiazi and Axel > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From ietf@jiaziyi.com Sat May 12 04:26:56 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C21A121F8634 for ; Sat, 12 May 2012 04:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oozxnyl2AGDW for ; Sat, 12 May 2012 04:26:55 -0700 (PDT) Received: from mx1000.mochahost.com (unknown [50.31.147.194]) by ietfa.amsl.com (Postfix) with ESMTP id F245221F862B for ; Sat, 12 May 2012 04:26:54 -0700 (PDT) Received: from mocha3004.mochahost.com ([50.31.147.60]:55734) by mx1000.mochahost.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1STAcB-003Vuw-De for roll@ietf.org; Sat, 12 May 2012 07:35:59 -0400 Received: from vbo91-1-89-87-201-6.dsl.sta.abo.bbox.fr ([89.87.201.6]:50124 helo=jy-mac-pro.home) by mocha3004.mochahost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1STATO-002nmj-6A for roll@ietf.org; Sat, 12 May 2012 07:26:54 -0400 From: Jiazi Yi Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_B4A791C2-06D5-4D23-9E14-CC56E23355B0" Date: Sat, 12 May 2012 13:26:51 +0200 In-Reply-To: <3CB5FAC8-4F2A-4B6B-9024-23D4CCFDD5D6@cs.stanford.edu> To: roll WG References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <3CB5FAC8-4F2A-4B6B-9024-23D4CCFDD5D6@cs.stanford.edu> Message-Id: <598F4696-2A7B-4619-A5F5-0FC6CDD17409@jiaziyi.com> X-Mailer: Apple Mail (2.1257) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mx1000.mochahost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jiaziyi.com Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 May 2012 11:26:56 -0000 --Apple-Mail=_B4A791C2-06D5-4D23-9E14-CC56E23355B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi,=20 As Thomas presented in Paris, this document is based on our experiences = of RPL based on testbeds, simulations, etc. Of course, we are aware of = the fact that we are far from smart, so we just followed the = specification of RPL. I'm sorry for making those mistakes that are = "basic and naive" for you, but we had tried our best.=20 For the authors, we think this document is relatively complete on the = aspect of "experience", rather than guidance -- of course, feedback and = more experience are always welcome. We would appreciate if there are = smart ones who can make companion document educating us how to avoid = those kind of "inexperienced" mistakes. best Jiazi Yi http://www.jiaziyi.com Hipercom@LIX, Ecole Polytechnique Route de Saclay 91128 Palaiseau Cedex France On May 12, 2012, at 6:10 AM, Philip Levis wrote: >=20 > On May 10, 2012, at 11:25 PM, Thomas Heide Clausen wrote: >=20 >> Dear JP, Michael, all >>=20 >> Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented = and discussed at the Paris meeting. >>=20 >> The authors consider the document complete and "done", and are = looking to take it forward in the IETF=20 >> process for publication as "Informational RFC" in the very near = future.=20 >>=20 >> We would therefore like to ask the WG chairs, if the ROLL WG is = willing to accept and progress this=20 >> document towards publication? >>=20 >> Best, >>=20 >> Thomas, Ulrich, Yuichi, Jiazi and Axel >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 >=20 > As I alluded to in Paris, I don't really think this is currently a = valid informational document; the document it *should* be is guidelines = on how to implement RPL, not a description of a series of basic and = naive mistakes. Unless we want a companion document, which for each of = the issues raised says how to solve it. We wouldn't write an RFC on = someone's experience with congestion collapse after implementing a = transport protocol without congestion control. Just my 2c. >=20 > Phil >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_B4A791C2-06D5-4D23-9E14-CC56E23355B0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

For the authors, = we think this document is relatively complete on the aspect of = "experience", rather than guidance -- of course, feedback and more = experience are always welcome.  We would appreciate if there are = smart ones who can make companion document educating us how to avoid = those kind of "inexperienced" = mistakes.

best

Jiazi = Yi

Hipe= rcom@LIX, Ecole Polytechnique
Route de Saclay 91128 = Palaiseau Cedex France

On = May 12, 2012, at 6:10 AM, Philip Levis wrote:


On = May 10, 2012, at 11:25 PM, Thomas Heide Clausen = wrote:

Dear JP, Michael, = all

Upon JPs invitation, draft-clausen-lln-rpl-experiences = was presented and discussed at the Paris = meeting.

The authors = consider the document complete and "done", and are looking to take it = forward in the IETF
process = for publication as "Informational RFC" in the very near future. =

We would therefore like to ask the WG chairs, if the ROLL = WG is willing to accept and progress this
document towards publication?

Best,

Thomas, Ulrich, = Yuichi, Jiazi and Axel
_______________________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/m= ailman/listinfo/roll



As I alluded to in Paris, I don't = really think this is currently a valid informational document; the = document it *should* be is guidelines on how to implement RPL, not a = description of a series of basic and naive mistakes. Unless we want a = companion document, which for each of the issues raised says how to = solve it.  We wouldn't write an RFC on someone's experience with = congestion collapse after implementing a transport protocol without = congestion control. Just my = 2c.

Phil

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

= --Apple-Mail=_B4A791C2-06D5-4D23-9E14-CC56E23355B0-- From admin@ipv6it.org Sun May 13 07:02:07 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD7B21F858E for ; Sun, 13 May 2012 07:02:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.185 X-Spam-Level: X-Spam-Status: No, score=-1.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dncctnRMzoIB for ; Sun, 13 May 2012 07:02:06 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 13B1521F8499 for ; Sun, 13 May 2012 07:02:05 -0700 (PDT) Received: by bkty8 with SMTP id y8so3720416bkt.31 for ; Sun, 13 May 2012 07:02:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding:x-gm-message-state; bh=DFhRvjqCOtqKaBc/xFgucCn5jufKH+rzabNFmmhBdE4=; b=SX48JiFJ1kMuc64h+hcGvj0qHBDxHfNTpJsrG8NHLHExOmtgDWt0JyFYhVig3s8O88 0F8OXa+jrdnE69Jm078mF0BAyKDr837AKlWWzDW2z4uo5traBSDbQjobQKJhryMuMbsI lHaq02Yo3ZnnoNQ4DSll+jLAzljVd/h6kkFs0q6jDMCt8dEEa/1wmRdxzzSqmRcDsS2z IqEWFmOO4+phjYNeNU3XnEjpRwDbJqANt/R1DSphGTBcFtCo2iMvRiCkKxg1FMcWUZuw RB5zWsKyr4mO3LId8H5uZXPD3vvUlWjfUc9jhGeRYzsp1lBOtpYie8mTclXRn/PxJKq4 QNcw== Received: by 10.205.118.9 with SMTP id fo9mr1791359bkc.58.1336917724984; Sun, 13 May 2012 07:02:04 -0700 (PDT) Received: from [127.0.0.1] ([87.18.133.188]) by mx.google.com with ESMTPS id fw10sm28624363bkc.11.2012.05.13.07.02.02 (version=SSLv3 cipher=OTHER); Sun, 13 May 2012 07:02:04 -0700 (PDT) Message-ID: <4FAFBED7.4060207@ipv6it.org> Date: Sun, 13 May 2012 16:01:59 +0200 From: Federico Consoli User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Roll@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlu3mDAIxzTPSYzLKAx60FhwXkzlrJurwYaXj+C3t5ZKo1M3vIcwKC93tCJuFLGUCbynogS Subject: [Roll] I-D Action: draft-ietf-roll-minrank-hysteresis-of-10 Comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 14:02:07 -0000 Hi, I have a doubt concerning the selection of parent set. Draft Section 3.3 says: "The exact selection of a parent set is an implementation decision." The document does not specify what to do in a situation like this: Example: ------ The node A has 1 parent with rank 700 and path cost 300 => A has a rank = 1000. B has A as Preferred parent and the path cost A-B is 300, soB has rank 1300. Later A receives from node C a DIO. Node C has rank 900 andpath cost A-C is 500 => A puts C in its parent set and announce a rank 1400. But, A receives a DIO from node B before to send a DIO =>A puts B in its parent set. When B receives the DD it will increase its rank. When Node A receives the DIO from the node B, it has 2 options: 1) Increase its rank 2) Delete the node from the parent set If A chooses option 1 there will be an infinite loop. ------ In general, a node does not know the reason why a parent increase its rank. In fact, a node can also increase his rank because its link is got worse. IMHO I think that if a parent announces a rank higher than the rank of the the nodethen the node MUST remove the parent from its Parent set. -- Regards Consoli Federico From pal@cs.stanford.edu Sun May 13 09:28:14 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E04A621F8498 for ; Sun, 13 May 2012 09:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.58 X-Spam-Level: X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pmYqiQkIN6tU for ; Sun, 13 May 2012 09:28:14 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1FD6321F8456 for ; Sun, 13 May 2012 09:28:14 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.103]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1STbeV-0002i2-Pu; Sun, 13 May 2012 09:28:11 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4FAFBED7.4060207@ipv6it.org> Date: Sun, 13 May 2012 09:28:18 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4FAFBED7.4060207@ipv6it.org> To: Federico Consoli X-Mailer: Apple Mail (2.1257) X-Scan-Signature: f52b81a2b0b1468c47a83f31a7d93b0f Cc: Roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-minrank-hysteresis-of-10 Comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 16:28:15 -0000 On May 13, 2012, at 7:01 AM, Federico Consoli wrote: > Hi, > I have a doubt concerning the selection of parent set. > Draft Section 3.3 says: > "The exact selection of a parent set is an implementation decision." >=20 > The document does not specify what to do in a situation like this: >=20 > Example: > ------ > The node A has 1 parent with rank 700 and path cost 300 =3D> A has a = rank =3D 1000. > B has A as Preferred parent and the path cost A-B is 300, soB has rank = 1300. >=20 > Later A receives from node C a DIO. Node C has rank 900 andpath cost = A-C is 500 =3D> A puts C in its parent set and announce a rank 1400. > But, A receives a DIO from node B before to send a DIO =3D>A puts B in = its parent set. >=20 > When B receives the DD it will increase its rank. When Node A receives = the DIO from the node B, it has 2 options: > 1) Increase its rank > 2) Delete the node from the parent set >=20 > If A chooses option 1 there will be an infinite loop. > ------ >=20 > In general, a node does not know the reason why a parent increase its = rank. In fact, a node can also increase his rank because its link is got = worse. >=20 > IMHO I think that if a parent announces a rank higher than the rank of = the the nodethen the node MUST remove the parent from its Parent set. >=20 > --=20 > Regards > Consoli Federico >=20 >=20 The RPL specification goes into this. Loops can temporarily form in the = network, but RPL will detect them and repair them. MaxRankIncrease = controls how far the nodes can count forward. RPL will detect the loop = (11.2 of RFC6550) and reset its Trickle timer to advertise the newer, = higher Rank. At some point, for example, if B's Rank goes high enough, A = will remove it from its parent set due to the Rank spread between B and = its other parent (the one with 700). Phil From admin@ipv6it.org Sun May 13 09:45:10 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524F621F852A for ; Sun, 13 May 2012 09:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9M+RYdOkGGm for ; Sun, 13 May 2012 09:45:09 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 24F5521F8526 for ; Sun, 13 May 2012 09:45:08 -0700 (PDT) Received: by bkty8 with SMTP id y8so3777212bkt.31 for ; Sun, 13 May 2012 09:45:08 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=mnJ0TFD4P8GlaomOGZCitq31HH1qjXPZW1zQ7JI4Gd8=; b=GyOBIoOeRFLdenPPbKkzrKyw4gDP6QhO0RqemZxwH45TxlBx88tJnE3R6zFzgM0y6N gFjr0KooVByvyyEeGZQVkMFLWwx8OnyyNpfoYUT1WsDlwevMLGOGXFCQaiafU2r/9+mv HtDtIDqdNSBa3OyGCeJEe71IQhMebvz5Ad/txT62j2NXZUhqBMJnpfRPvVltSqSfRu4Q Ii/z+RSNNsBNS+0oirMw6lzvi6MUtFaU/9j3lixErIVq3lMtWg3NDVJOBDp9jTgQvmWl Rlc6ZV0Q3JDoEcIkAQn+FJ4uxYTrkiBTq7VabD3r6A6/tPS5EFcPG9IdiB1SddSx0kIh nLvA== Received: by 10.204.150.72 with SMTP id x8mr2022655bkv.33.1336927507953; Sun, 13 May 2012 09:45:07 -0700 (PDT) Received: from [127.0.0.1] ([87.18.133.188]) by mx.google.com with ESMTPS id s20sm29232431bks.2.2012.05.13.09.45.05 (version=SSLv3 cipher=OTHER); Sun, 13 May 2012 09:45:07 -0700 (PDT) Message-ID: <4FAFE50E.6030003@ipv6it.org> Date: Sun, 13 May 2012 18:45:02 +0200 From: Federico Consoli User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Philip Levis References: <4FAFBED7.4060207@ipv6it.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQm+L7eNPfF+EBexQlUFQfGp0um0LgVLNuDzmd8Y0nMIEXR9RbU41xJXNcyFJ6yo9uX4rLoY Cc: Roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-minrank-hysteresis-of-10 Comments X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 13 May 2012 16:45:10 -0000 Il 13/05/2012 18.28, Philip Levis ha scritto: > On May 13, 2012, at 7:01 AM, Federico Consoli wrote: > >> Hi, >> I have a doubt concerning the selection of parent set. >> Draft Section 3.3 says: >> "The exact selection of a parent set is an implementation decision." >> >> The document does not specify what to do in a situation like this: >> >> Example: >> ------ >> The node A has 1 parent with rank 700 and path cost 300 => A has a rank = 1000. >> B has A as Preferred parent and the path cost A-B is 300, soB has rank 1300. >> >> Later A receives from node C a DIO. Node C has rank 900 andpath cost A-C is 500 => A puts C in its parent set and announce a rank 1400. >> But, A receives a DIO from node B before to send a DIO =>A puts B in its parent set. >> >> When B receives the DD it will increase its rank. When Node A receives the DIO from the node B, it has 2 options: >> 1) Increase its rank >> 2) Delete the node from the parent set >> >> If A chooses option 1 there will be an infinite loop. >> ------ >> >> In general, a node does not know the reason why a parent increase its rank. In fact, a node can also increase his rank because its link is got worse. >> >> IMHO I think that if a parent announces a rank higher than the rank of the the nodethen the node MUST remove the parent from its Parent set. >> >> -- >> Regards >> Consoli Federico >> >> > > The RPL specification goes into this. Loops can temporarily form in the network, but RPL will detect them and repair them. MaxRankIncrease controls how far the nodes can count forward. RPL will detect the loop (11.2 of RFC6550) and reset its Trickle timer to advertise the newer, higher Rank. At some point, for example, if B's Rank goes high enough, A will remove it from its parent set due to the Rank spread between B and its other parent (the one with 700). > > Phil > Ok, I agree with you. So I think that the use of MaxRankIncrease is mandatory with mrhof, you can't disable it (set to 0). -- Regards Consoli Federico From mcr@sandelman.ca Tue May 15 10:44:40 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A65F521F86CA for ; Tue, 15 May 2012 10:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.688 X-Spam-Level: X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[AWL=0.266, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gU1y-I6f2pdc for ; Tue, 15 May 2012 10:44:39 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id B291A21F86BA for ; Tue, 15 May 2012 10:44:39 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 4BA868398 for ; Tue, 15 May 2012 13:43:21 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 27AEF98B98; Tue, 15 May 2012 13:44:37 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 247CF98281 for ; Tue, 15 May 2012 13:44:37 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: References: <20120430114209.21250.82110.idtracker@ietfa.amsl.com> <18151.1335822136@marajade.sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 15 May 2012 13:44:37 -0400 Message-ID: <10134.1337103877@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] proposal for common table of contents for applicability statements X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 15 May 2012 17:44:40 -0000 =2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is the table of contents from each of the applicability statements.=20=20 I thought we had a third applicability statement as an independant draft, but I couldn't find one. We should have a building/home applicability statement. I feel that these two applicability statements are over broad, and that each should be split into two or three statements. In particular, I think that Energy-Constrained and Energy-Rich networks should be split into different documents as they have vastly different requirements. It may be that there is a further split for networks that are dense (urban) vs those that are less dense (suburban or rural). A major purpose of these documents is to permit a utility (etc.) to be able to write an RFP to procure equipment from multiple vendors that can interoperate. (there are NAFTA, GATT, etc. that governments needs to comply to, which an RFC easily satisfies) As such, there needs to be enough information as to the profile of RPL to be deployed (to each area), such that a vendor can actually implement something definite. I also feel that these document spend too much time on explaining what RPL is (and frankly they they do a really good, succint job at it, so I hate to lose that text, but I don't think it needs to be repeated) What I'd like to do (and I invite you to reply inline, keeping just this text, and +1 each part seperately) 1) is to synchronize these two documents' table of contents.=20=20=20 2) discuss adopting draft-phinney as a WG document! 3) make sure that we are also detailing security and routing issues properly, and yes, we need to have statments like: "Metering networks using ZigBee FOOBAR MUST in layer-2 have security BAZ enabled in order that RPL messages will be secured." or: "This statement applies to using RPL as the MESH over network on 802.15.4 technology with the 6LowPAN defined nd-18 including RFC6282 HC" The applicability statement is not the place to be general. Let's be specific, and in doing so, let's be succinct. draft-ietf-roll-applicability-ami-05.txt: 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Electric Metering . . . . . . . . . . . . . . . . . . . . 3 1.2. Gas and Water Metering . . . . . . . . . . . . . . . . . . 3 1.3. Routing Protocol for LLNs (RPL) . . . . . . . . . . . . . 4 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5 2.1. Network Topology . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Electric Meter Network . . . . . . . . . . . . . . . . 5 2.1.2. Energy-Constrained Network Infrastructure . . . . . . 6 2.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 6 2.2.1. Smart Metering Data . . . . . . . . . . . . . . . . . 7 2.2.2. Distribution Automation Communication . . . . . . . . 8 2.2.3. Emerging Applications . . . . . . . . . . . . . . . . 8 3. Using RPL to Meet Functional Requirements . . . . . . . . . . 8 4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 9 4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 9 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 10 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 10 4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 10 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 11 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 11 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 12 4.2. Recommended Configuration Defaults and Ranges . . . . . . 12 4.2.1. Trickle Parameters . . . . . . . . . . . . . . . . . . 12 4.2.2. Other Parameters . . . . . . . . . . . . . . . . . . . 13 5. Manageability Considerations . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Other Related Protocols . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Informative References . . . . . . . . . . . . . . . . . . 15 10.2. Normative References . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 draft-phinney-rpl-industrial-applicability-00: 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Deployment scenarii . . . . . . . . . . . . . . . . . . . 7 3.2. Applications and Traffic classes . . . . . . . . . . . . . 9 3.3. RPL applicability matrix . . . . . . . . . . . . . . . . . 10 4. Characterization of communication flows in IACS wireless networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Source-sink (SS) communication paradigm . . . . . . . . . 13 4.3. Publish-subscribe (PS, or pub/sub) communication paradigm . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Peer-to-peer (P2P) communication paradigm . . . . . . . . 15 4.5. Peer-to-multipeer (P2MP) communication paradigm . . . . . 16 4.6. Additional considerations: Duocast and N-cast . . . . . . 17 4.7. RPL applicability per communication paradigm . . . . . . . 18 5. RPL profile . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Use for process control . . . . . . . . . . . . . . . . . 21 5.2. RPL features . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.1. Storing vs. non-storing mode . . . . . . . . . . . . . 21 5.2.2. DAO policy . . . . . . . . . . . . . . . . . . . . . . 21 5.2.3. Path metrics . . . . . . . . . . . . . . . . . . . . . 22 5.2.4. Objective functions . . . . . . . . . . . . . . . . . 22 5.2.5. DODAG repair . . . . . . . . . . . . . . . . . . . . . 22 5.2.6. Security . . . . . . . . . . . . . . . . . . . . . . . 22 5.3. RPL options . . . . . . . . . . . . . . . . . . . . . . . 22 5.4. Recommended configuration defaults and ranges . . . . . . 22 5.4.1. Trickle parameters . . . . . . . . . . . . . . . . . . 22 5.4.2. Other parameters . . . . . . . . . . . . . . . . . . . 23 5.4.3. Additional configuration recommendations . . . . . . . 23 6. Other related protocols . . . . . . . . . . . . . . . . . . . 24 7. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 25 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26 9. Security considerations . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . . 29 11.3. External Informative References . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 =2D --=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUBT7KWBIqHRg3pndX9AQKEDgP/ddKMasN7jRNVl6ZGAtCchSYeV/0oUSQ0 Gn8FSRCbacZosnchjVDuDz5MMV4MToC8BPgBh2n0qW4jTpYK8KTPiwhGcJUgkwtv n1xmEJj6d9kftudUCFfmh2WlrXaPWlYdndM/avulkGK8mOVYphHYrtxf4nbyj1HV Y3ChARZ5nUM=3D =3D8qRA =2D----END PGP SIGNATURE----- From jpv@cisco.com Wed May 16 00:18:12 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A59021F8652 for ; Wed, 16 May 2012 00:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.382 X-Spam-Level: X-Spam-Status: No, score=-111.382 tagged_above=-999 required=5 tests=[AWL=1.217, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgCjVNBT3l9f for ; Wed, 16 May 2012 00:18:11 -0700 (PDT) Received: from ams-iport-4.cisco.com (ams-iport-4.cisco.com [144.254.224.147]) by ietfa.amsl.com (Postfix) with ESMTP id 8DA6721F864F for ; Wed, 16 May 2012 00:18:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=1103; q=dns/txt; s=iport; t=1337152691; x=1338362291; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=N9TpMNg9eMHXk6qu9x6VawxtIM6QKNxEfQAZQtJ7nmk=; b=Wisx4hPSIzmYM7AWUMJ8vJ9ox2Qq8iT9fX2rP3G4wcNfZ0lpZ1jBoe7q 4g7svBsG3NhxaymKk2cMEVq8NwoCwiF4c5KtCFSR074OZ/zhu95AypseB cDRT/3zuc/1FZ6FVh9Hfj6NOIHRCMWcEDYIothpDaqancGe5yhlaCqtI7 Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFABZUs0+Q/khL/2dsb2JhbABEgx2wY4EHghUBAQEDARIBJz8FCwtGVwY1h2cFmxmgHosdhHVjBJV9hXWIYoFpgms X-IronPort-AV: E=Sophos;i="4.75,601,1330905600"; d="scan'208";a="4567696" Received: from ams-core-2.cisco.com ([144.254.72.75]) by ams-iport-4.cisco.com with ESMTP; 16 May 2012 07:18:10 +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 q4G7IAS9028591; Wed, 16 May 2012 07:18:10 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 09:18:10 +0200 Received: from [10.60.114.227] ([10.60.114.227]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 09:18:09 +0200 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> Date: Wed, 16 May 2012 09:18:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 16 May 2012 07:18:09.0378 (UTC) FILETIME=[0BDA3C20:01CD3334] Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 07:18:12 -0000 Dear Thomas, On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: > Dear JP, Michael, all >=20 > Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented = and discussed at the Paris meeting. >=20 > The authors consider the document complete and "done", and are looking = to take it forward in the IETF=20 > process for publication as "Informational RFC" in the very near = future.=20 >=20 > We would therefore like to ask the WG chairs, if the ROLL WG is = willing to accept and progress this=20 > document towards publication? Thanks for your suggestion. So far we haven't see a lot of = discussion/interest from the WG but your request is perfectly fair. So far there are no details on the scenarios and testing = environments that led to the issues that=20 you reported, thus I would suggest you to first include them so that = people interested could be able to reproduce it. Once the drat is updated, we'll be happy to pool the WG. Does that make sense ? Thanks. JP and Michael. >=20 > Best, >=20 > Thomas, Ulrich, Yuichi, Jiazi and Axel From ietf@thomasclausen.org Wed May 16 05:08:48 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08A821F869A for ; Wed, 16 May 2012 05:08:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.465 X-Spam-Level: X-Spam-Status: No, score=-3.465 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, GB_I_INVITATION=-2, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21GdCe5pH+ez for ; Wed, 16 May 2012 05:08:48 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD6521F8663 for ; Wed, 16 May 2012 05:08:48 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id E7DB7558182 for ; Wed, 16 May 2012 05:08:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 71BFA1BD9978; Wed, 16 May 2012 05:08:46 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 616CD1BD9976; Wed, 16 May 2012 05:08:45 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Thomas Heide Clausen In-Reply-To: <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> Date: Wed, 16 May 2012 14:08:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1257) Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 12:08:48 -0000 Dear JP and Michael, Thank you for your mail. On May 16, 2012, at 09:18 , JP Vasseur wrote: > Dear Thomas, >=20 > On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >=20 >> Dear JP, Michael, all >>=20 >> Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented = and discussed at the Paris meeting. >>=20 >> The authors consider the document complete and "done", and are = looking to take it forward in the IETF=20 >> process for publication as "Informational RFC" in the very near = future.=20 >>=20 >> We would therefore like to ask the WG chairs, if the ROLL WG is = willing to accept and progress this=20 >> document towards publication? >=20 > Thanks for your suggestion. So far we haven't see a lot of = discussion/interest from the WG but your request is > perfectly fair. Thank you - I aim to be fair. > So far there are no details on the scenarios and testing environments = that led to the issues that=20 > you reported, thus I would suggest you to first include them so that = people interested could be able to reproduce > it. Once the drat is updated, we'll be happy to pool the WG. >=20 > Does that make sense ? Not really. Let me explain my disagreement. We tried RPL (and, I note, several different independent implementations = of RPL) in a number of different scenarios and deployments, and observed = the behaviors exhibited - noting that what we observed across the = different implementations, scenarios and deployments was fairly = universal. We then went back to the specification, to understand these behaviors in = detail, and understand their universality as independent from a specific = scenario or deployment or implementation - but rather, as artifacts of = the RPL protocol design. We therefore believe that _any_ deployment, scenario or testing = environment of RPL needs to pay attention to the issues presented, and = find a way of addressing them. The way of addressing these issues in a = given deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario. (For example, a deployment using only L2s which provides guaranteed = bi-directional links for L3 would address this by in the applicability = statement stating "As all L2-links are guaranteed bi-directional, this = addresses the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".) Thus, we believe that it would actually be misleading (not to mention, = unnecessarily verbose) to put the "details on the scenarios and testing = environments" into this I-D. Doing so would mislead the reader to believe that the issues presented = only manifest themselves in those precise scenarios - which definitely = isn't the case. Best, Thomas > Thanks. >=20 > JP and Michael. >=20 >>=20 >> Best, >>=20 >> Thomas, Ulrich, Yuichi, Jiazi and Axel >=20 From jpv@cisco.com Wed May 16 06:04:18 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C36321F865D for ; Wed, 16 May 2012 06:04:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.585 X-Spam-Level: X-Spam-Status: No, score=-111.585 tagged_above=-999 required=5 tests=[AWL=1.014, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohXi-JeOYmQR for ; Wed, 16 May 2012 06:04:17 -0700 (PDT) Received: from ams-iport-3.cisco.com (ams-iport-3.cisco.com [144.254.224.146]) by ietfa.amsl.com (Postfix) with ESMTP id 6A72721F865B for ; Wed, 16 May 2012 06:04:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=3811; q=dns/txt; s=iport; t=1337173457; x=1338383057; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=Q/MUexIRkI79TAk96949uRb/VndUMsodb5DtLKzTztQ=; b=PjeM2o7HcfV43dQFJgODUQ94vy/4EnqlnJVeDZTvYRNmzluhuH6LOp3Y 2sv5DABEXxtgHOTJw+RGuyPNQGBdEO6F26uHDq5f5xKq9wrZ1hX0kXmHM m3BwtI9ecJiuHiMNKychRXV+6aASgiiNYx6BdX1v/zporwc5pddfGWSVL c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkYFACals0+Q/khM/2dsb2JhbABEgx2wZIEHghUBAQEDARIBZgULCxguVwYuB4dnBZsXoB2LHRmEXGMElX2FdYhigWmCa4Fd X-IronPort-AV: E=Sophos;i="4.75,603,1330905600"; d="scan'208";a="4582950" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-3.cisco.com with ESMTP; 16 May 2012 13:04:16 +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 q4GD4GoL013243; Wed, 16 May 2012 13:04:16 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 15:04:16 +0200 Received: from [10.60.114.227] ([10.60.114.227]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 15:04:15 +0200 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: JP Vasseur In-Reply-To: <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> Date: Wed, 16 May 2012 15:04:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 16 May 2012 13:04:15.0936 (UTC) FILETIME=[65AF8400:01CD3364] Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 13:04:18 -0000 Dear Thomas, On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: > Dear JP and Michael, >=20 > Thank you for your mail. >=20 > On May 16, 2012, at 09:18 , JP Vasseur wrote: >=20 >> Dear Thomas, >>=20 >> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>=20 >>> Dear JP, Michael, all >>>=20 >>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented = and discussed at the Paris meeting. >>>=20 >>> The authors consider the document complete and "done", and are = looking to take it forward in the IETF=20 >>> process for publication as "Informational RFC" in the very near = future.=20 >>>=20 >>> We would therefore like to ask the WG chairs, if the ROLL WG is = willing to accept and progress this=20 >>> document towards publication? >>=20 >> Thanks for your suggestion. So far we haven't see a lot of = discussion/interest from the WG but your request is >> perfectly fair. >=20 > Thank you - I aim to be fair. >=20 >> So far there are no details on the scenarios and testing environments = that led to the issues that=20 >> you reported, thus I would suggest you to first include them so that = people interested could be able to reproduce >> it. Once the drat is updated, we'll be happy to pool the WG. >>=20 >> Does that make sense ? >=20 > Not really. Let me explain my disagreement. >=20 > We tried RPL (and, I note, several different independent = implementations of RPL) in a number of different scenarios and = deployments, and observed the behaviors exhibited - noting that what we = observed across the different implementations, scenarios and deployments = was fairly universal. >=20 > We then went back to the specification, to understand these behaviors = in detail, and understand their universality as independent from a = specific scenario or deployment or implementation - but rather, as = artifacts of the RPL protocol design. >=20 > We therefore believe that _any_ deployment, scenario or testing = environment of RPL needs to pay attention to the issues presented, and = find a way of addressing them. The way of addressing these issues in a = given deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario. JP> Thanks for the clarification; that being said, for the WG to make = sure that nothing is "scenario" dependent and the outcome could indeed = apply to all scenarios, it might be worth being more explicit. For example, you pointed out to = the MTU issue, to which I mentioned that 15.4g would bring a solution, = so you may want to=20 explain that you did not use 15.4g and there are a number of such = examples =85. >=20 > (For example, a deployment using only L2s which provides guaranteed = bi-directional links for L3 would address this by in the applicability = statement stating "As all L2-links are guaranteed bi-directional, this = addresses the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".) >=20 > Thus, we believe that it would actually be misleading (not to mention, = unnecessarily verbose) to put the "details on the scenarios and testing = environments" into this I-D. >=20 > Doing so would mislead the reader to believe that the issues presented = only manifest themselves in those precise scenarios - which definitely = isn't the case. JP> see the previous comment and tell us what you think; we could = provide other examples. Note that we do not oppose to asking to the WG; we just request you = first to add additional information to proceed forward. thanks. JP and Michael. JP. >=20 > Best, >=20 > Thomas >=20 >> Thanks. >>=20 >> JP and Michael. >>=20 >>>=20 >>> Best, >>>=20 >>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>=20 >=20 From ietf@thomasclausen.org Wed May 16 06:17:51 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F35A021F84D5 for ; Wed, 16 May 2012 06:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.55 X-Spam-Level: X-Spam-Status: No, score=-3.55 tagged_above=-999 required=5 tests=[AWL=0.714, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cas4jhDVUEDk for ; Wed, 16 May 2012 06:17:50 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0B54021F8622 for ; Wed, 16 May 2012 06:17:50 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id D52E7558024 for ; Wed, 16 May 2012 06:17:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 8EA121BDA0BC; Wed, 16 May 2012 06:17:49 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 35B1A1BDA0B7; Wed, 16 May 2012 06:17:48 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_5C80BAAC-4D16-48CC-8E89-62CBFDE33B9F" From: Thomas Heide Clausen In-Reply-To: Date: Wed, 16 May 2012 15:17:45 +0200 Message-Id: <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> To: JP Vasseur X-Mailer: Apple Mail (2.1257) Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 13:17:51 -0000 --Apple-Mail=_5C80BAAC-4D16-48CC-8E89-62CBFDE33B9F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 16, 2012, at 15:04 , JP Vasseur wrote: > Dear Thomas, >=20 > On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: >=20 >> Dear JP and Michael, >>=20 >> Thank you for your mail. >>=20 >> On May 16, 2012, at 09:18 , JP Vasseur wrote: >>=20 >>> Dear Thomas, >>>=20 >>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>>=20 >>>> Dear JP, Michael, all >>>>=20 >>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was = presented and discussed at the Paris meeting. >>>>=20 >>>> The authors consider the document complete and "done", and are = looking to take it forward in the IETF=20 >>>> process for publication as "Informational RFC" in the very near = future.=20 >>>>=20 >>>> We would therefore like to ask the WG chairs, if the ROLL WG is = willing to accept and progress this=20 >>>> document towards publication? >>>=20 >>> Thanks for your suggestion. So far we haven't see a lot of = discussion/interest from the WG but your request is >>> perfectly fair. >>=20 >> Thank you - I aim to be fair. >>=20 >>> So far there are no details on the scenarios and testing = environments that led to the issues that=20 >>> you reported, thus I would suggest you to first include them so that = people interested could be able to reproduce >>> it. Once the drat is updated, we'll be happy to pool the WG. >>>=20 >>> Does that make sense ? >>=20 >> Not really. Let me explain my disagreement. >>=20 >> We tried RPL (and, I note, several different independent = implementations of RPL) in a number of different scenarios and = deployments, and observed the behaviors exhibited - noting that what we = observed across the different implementations, scenarios and deployments = was fairly universal. >>=20 >> We then went back to the specification, to understand these behaviors = in detail, and understand their universality as independent from a = specific scenario or deployment or implementation - but rather, as = artifacts of the RPL protocol design. >>=20 >> We therefore believe that _any_ deployment, scenario or testing = environment of RPL needs to pay attention to the issues presented, and = find a way of addressing them. The way of addressing these issues in a = given deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario. >=20 > JP> Thanks for the clarification; that being said, for the WG to make = sure that nothing is "scenario" dependent and the outcome could indeed = apply to all scenarios, > it might be worth being more explicit. For example, you pointed out to = the MTU issue, to which I mentioned that 15.4g would bring a solution, = so you may want to=20 > explain that you did not use 15.4g=20 This particular issue is fairly well pointed out in section 6, which = references RFC4919 (cf section 2 hereof) - the particular "small MTU" is = not dependent on the specific 127 octets of a specific L2, but a set of = observations that RPL - when faced with a small MTU - may often not be = able to carry a complete control message in a single fragment. Section = 6, 3rd paragraph is fairly explicit as to this. More globally, the draft cites = http://datatracker.ietf.org/wg/roll/charter/ - which (other than making = specific reference to 802.15.4 (and not 15.4g) states that: "In most cases, LLNs will be employed over link layers with=20 restricted frame-sizes, thus a routing protocol for LLNs should = be specifically adapted for such link layers We observe some limits on RPL within the framework that the ROLL charter = has set forth. I'm not sure I see what more can be done to address this point. > and there are a number of such examples =85. Personally, I do not believe that there are, but we (I think I can = speak for all the authors here) would very much appreciate your being = explicit on these examples - least it's hard to discuss them.=20 Thomas >>=20 >> (For example, a deployment using only L2s which provides guaranteed = bi-directional links for L3 would address this by in the applicability = statement stating "As all L2-links are guaranteed bi-directional, this = addresses the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".) >>=20 >> Thus, we believe that it would actually be misleading (not to = mention, unnecessarily verbose) to put the "details on the scenarios and = testing environments" into this I-D. >>=20 >> Doing so would mislead the reader to believe that the issues = presented only manifest themselves in those precise scenarios - which = definitely isn't the case. >=20 > JP> see the previous comment and tell us what you think; we could = provide other examples. >=20 > Note that we do not oppose to asking to the WG; we just request you = first to add additional information to proceed forward. >=20 > thanks. >=20 > JP and Michael. >=20 > JP. >=20 >>=20 >> Best, >>=20 >> Thomas >>=20 >>> Thanks. >>>=20 >>> JP and Michael. >>>=20 >>>>=20 >>>> Best, >>>>=20 >>>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>>=20 >>=20 >=20 --Apple-Mail=_5C80BAAC-4D16-48CC-8E89-62CBFDE33B9F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Dear = Thomas,

On May 16, 2012, at 2:08 PM, Thomas Heide Clausen = wrote:

Dear JP and = Michael,

Thank you for = your mail.

On May 16, = 2012, at 09:18 , JP Vasseur wrote:

Dear Thomas,

On May 11, 2012, at 8:25 AM, = Thomas Heide Clausen wrote:

Dear = JP, Michael, all

Upon = JPs invitation, draft-clausen-lln-rpl-experiences was presented and = discussed at the Paris = meeting.

The = authors consider the document complete and "done", and are looking to = take it forward in the IETF =
process = for publication as "Informational RFC" in the very near future. =

We = would therefore like to ask the WG chairs, if the ROLL WG is willing to = accept and progress this =
document= towards = publication?

Thanks for your suggestion. So = far we haven't see a lot of discussion/interest from the WG but your = request is
perfectly = fair.

Thank you - I = aim to be fair.

So far there are no details on the scenarios and testing = environments that led to the issues that =
you reported, thus I would suggest you to first include = them so that people interested could be able to = reproduce
it. Once the drat is updated, = we'll be happy to pool the WG.

Does that make sense = ?

Not really. Let = me explain my disagreement.

We tried RPL = (and, I note, several different independent implementations of RPL) in a = number of different scenarios and deployments, and observed the = behaviors exhibited - noting that what we observed across the different = implementations, scenarios and deployments was fairly = universal.

We then went = back to the specification, to understand these behaviors in detail, and = understand their universality as independent from a specific scenario or = deployment or implementation - but rather, as artifacts of the RPL = protocol design.

We therefore = believe that _any_ deployment, scenario or testing environment of RPL = needs to pay attention to the issues presented, and find a way of = addressing them. The way of addressing these issues in a given = deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario.

JP> = Thanks for the clarification; that being said, for the WG to make sure = that nothing is "scenario" dependent and the outcome could indeed apply = to all scenarios,
it might be worth being more explicit. For example, = you pointed out to the MTU issue, to which I mentioned that 15.4g would = bring a solution, so you may want to
explain that you did not use = 15.4g 

This particular = issue is fairly well pointed out in section 6, which references RFC4919 = (cf section 2 hereof) - the particular "small MTU" is not dependent on = the specific 127 octets of a specific L2, but a set of observations that = RPL - when faced with a small MTU - may often not be able to carry a = complete control message in a single fragment. Section 6, 3rd = paragraph is fairly explicit as to this.

More = globally, the draft cites http://datatracker.i= etf.org/wg/roll/charter/ - which (other than making specific = reference to 802.15.4 (and not 15.4g) states that:

"In most cases, LLNs will be = employed over link layers with 
=  restricted frame-sizes, thus a routing protocol for LLNs = should be
=  specifically adapted for such link = layers

We observe some limits on RPL within the framework that the ROLL = charter has set forth.

I'm not sure I see what more can be done to address this = point.

and = there are a number of such examples = =85.

Personally, I do not = believe that there are, but  we (I think I can speak for all = the authors here) would very much appreciate your being explicit on = these examples - least it's hard to discuss = them. 

Thomas


(For example, a deployment using only L2s which provides = guaranteed bi-directional links  for L3 would address this by in = the applicability statement stating "As all L2-links are guaranteed = bi-directional, this addresses the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".)

Thus, we = believe that it would actually be misleading (not to mention, = unnecessarily verbose) to put the "details on the scenarios and testing = environments" into this I-D.

Doing so would = mislead the reader to believe that the issues presented only manifest = themselves in those precise scenarios - which definitely isn't the = case.

JP> see the previous comment and tell us = what you think; we could provide other = examples.

Note = that we do not oppose to asking to the WG; we just request you first to = add additional information to proceed forward.

thanks.

JP = and Michael.

JP.


Best,

Thomas

Thanks.

JP and = Michael.


Best,

Thomas, = Ulrich, Yuichi, Jiazi and = Axel




= --Apple-Mail=_5C80BAAC-4D16-48CC-8E89-62CBFDE33B9F-- From ietf@jiaziyi.com Wed May 16 06:36:42 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDFF421F8653 for ; Wed, 16 May 2012 06:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, GB_I_INVITATION=-2, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q5vgW+B6-wFU for ; Wed, 16 May 2012 06:36:41 -0700 (PDT) Received: from mx1000.mochahost.com (unknown [50.31.147.194]) by ietfa.amsl.com (Postfix) with ESMTP id 2733D21F864B for ; Wed, 16 May 2012 06:36:40 -0700 (PDT) Received: from mocha3004.mochahost.com ([50.31.147.60]:35631) by mx1000.mochahost.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77) (envelope-from ) id 1SUeZ3-002awl-Ox; Wed, 16 May 2012 09:46:53 -0400 Received: from sphinx.lix.polytechnique.fr ([129.104.11.1]:62417 helo=[192.168.112.174]) by mocha3004.mochahost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.77) (envelope-from ) id 1SUeP7-003n0g-SA; Wed, 16 May 2012 09:36:38 -0400 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_153F70E8-14EE-40AF-949B-200BC3E77848" From: Jiazi Yi In-Reply-To: Date: Wed, 16 May 2012 15:36:33 +0200 Message-Id: <262E058F-3B45-4700-81CC-22AF92EC0C5A@jiaziyi.com> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> To: JP Vasseur X-Mailer: Apple Mail (2.1278) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - mx1000.mochahost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - jiaziyi.com Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 13:36:42 -0000 --Apple-Mail=_153F70E8-14EE-40AF-949B-200BC3E77848 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi dear JP, On May 16, 2012, at 3:04 PM, JP Vasseur wrote: > Dear Thomas, >=20 > On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: >=20 >> Dear JP and Michael, >>=20 >> Thank you for your mail. >>=20 >> On May 16, 2012, at 09:18 , JP Vasseur wrote: >>=20 >>> Dear Thomas, >>>=20 >>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>>=20 >>>> Dear JP, Michael, all >>>>=20 >>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was = presented and discussed at the Paris meeting. >>>>=20 >>>> The authors consider the document complete and "done", and are = looking to take it forward in the IETF=20 >>>> process for publication as "Informational RFC" in the very near = future.=20 >>>>=20 >>>> We would therefore like to ask the WG chairs, if the ROLL WG is = willing to accept and progress this=20 >>>> document towards publication? >>>=20 >>> Thanks for your suggestion. So far we haven't see a lot of = discussion/interest from the WG but your request is >>> perfectly fair. >>=20 >> Thank you - I aim to be fair. >>=20 >>> So far there are no details on the scenarios and testing = environments that led to the issues that=20 >>> you reported, thus I would suggest you to first include them so that = people interested could be able to reproduce >>> it. Once the drat is updated, we'll be happy to pool the WG. >>>=20 >>> Does that make sense ? >>=20 >> Not really. Let me explain my disagreement. >>=20 >> We tried RPL (and, I note, several different independent = implementations of RPL) in a number of different scenarios and = deployments, and observed the behaviors exhibited - noting that what we = observed across the different implementations, scenarios and deployments = was fairly universal. >>=20 >> We then went back to the specification, to understand these behaviors = in detail, and understand their universality as independent from a = specific scenario or deployment or implementation - but rather, as = artifacts of the RPL protocol design. >>=20 >> We therefore believe that _any_ deployment, scenario or testing = environment of RPL needs to pay attention to the issues presented, and = find a way of addressing them. The way of addressing these issues in a = given deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario. >=20 > JP> Thanks for the clarification; that being said, for the WG to make = sure that nothing is "scenario" dependent and the outcome could indeed = apply to all scenarios, > it might be worth being more explicit. For example, you pointed out to = the MTU issue, to which I mentioned that 15.4g would bring a solution, = so you may want to=20 > explain that you did not use 15.4g and there are a number of such = examples =85. The document is based on the common scenarios of LLN, which means: = constrained power, memory, energy, etc.=20 In another words, it's "LLN-scenario" dependent.=20 For example, regarding the MTU issue, it is said in the ROLL WG charter: - In most cases, LLNs will be employed over link layers with=20 restricted frame-sizes, thus a routing protocol for LLNs should = be specifically adapted for such link layers. and in RFC 4919, the first characteristic of 6lowpan listed: 1. Small packet size. Given that the maximum physical layer packet is 127 bytes, the resulting maximum frame size at the media access control layer is 102 octets. Link-layer security imposes further overhead, which in the maximum case (21 octets of overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32 and AES-CCM-64, respectively), leaves 81 octets for data packets. More assumptions can be found in documents of 6lowpan and roll. = Therefore, IMHO, it's safe to build the experience document based on = those common assumptions. In contrast, it will be verbose to list all = the possible special solutions/technologies.=20 best=20 YI Jiazi http://www.jiaziyi.com Hipercom@LIX, Ecole Polytechnique Route de Saclay 91128 Palaiseau Cedex France >=20 >>=20 >> (For example, a deployment using only L2s which provides guaranteed = bi-directional links for L3 would address this by in the applicability = statement stating "As all L2-links are guaranteed bi-directional, this = addresses the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".) >>=20 >> Thus, we believe that it would actually be misleading (not to = mention, unnecessarily verbose) to put the "details on the scenarios and = testing environments" into this I-D. >>=20 >> Doing so would mislead the reader to believe that the issues = presented only manifest themselves in those precise scenarios - which = definitely isn't the case. >=20 > JP> see the previous comment and tell us what you think; we could = provide other examples. >=20 > Note that we do not oppose to asking to the WG; we just request you = first to add additional information to proceed forward. >=20 > thanks. >=20 > JP and Michael. >=20 > JP. >=20 >>=20 >> Best, >>=20 >> Thomas >>=20 >>> Thanks. >>>=20 >>> JP and Michael. >>>=20 >>>>=20 >>>> Best, >>>>=20 >>>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>>=20 >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_153F70E8-14EE-40AF-949B-200BC3E77848 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Dear = Thomas,

On May 16, 2012, at 2:08 PM, Thomas Heide Clausen = wrote:

Dear JP and = Michael,

Thank you for = your mail.

On May 16, = 2012, at 09:18 , JP Vasseur wrote:

Dear Thomas,

On May 11, 2012, at 8:25 AM, = Thomas Heide Clausen wrote:

Dear = JP, Michael, all

Upon = JPs invitation, draft-clausen-lln-rpl-experiences was presented and = discussed at the Paris = meeting.

The = authors consider the document complete and "done", and are looking to = take it forward in the IETF =
process = for publication as "Informational RFC" in the very near future. =

We = would therefore like to ask the WG chairs, if the ROLL WG is willing to = accept and progress this =
document= towards = publication?

Thanks for your suggestion. So = far we haven't see a lot of discussion/interest from the WG but your = request is
perfectly = fair.

Thank you - I = aim to be fair.

So far there are no details on the scenarios and testing = environments that led to the issues that =
you reported, thus I would suggest you to first include = them so that people interested could be able to = reproduce
it. Once the drat is updated, = we'll be happy to pool the WG.

Does that make sense = ?

Not really. Let = me explain my disagreement.

We tried RPL = (and, I note, several different independent implementations of RPL) in a = number of different scenarios and deployments, and observed the = behaviors exhibited - noting that what we observed across the different = implementations, scenarios and deployments was fairly = universal.

We then went = back to the specification, to understand these behaviors in detail, and = understand their universality as independent from a specific scenario or = deployment or implementation - but rather, as artifacts of the RPL = protocol design.

We therefore = believe that _any_ deployment, scenario or testing environment of RPL = needs to pay attention to the issues presented, and find a way of = addressing them. The way of addressing these issues in a given = deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario.

JP> = Thanks for the clarification; that being said, for the WG to make sure = that nothing is "scenario" dependent and the outcome could indeed apply = to all scenarios,
it might be worth being more explicit. For example, = you pointed out to the MTU issue, to which I mentioned that 15.4g would = bring a solution, so you may want to
explain that you did not use = 15.4g and there are a number of such examples = =85.


The = document is based on the common scenarios of LLN, which means: = constrained power, memory, energy, etc. 
In another = words, it's "LLN-scenario" dependent. 

For = example, regarding the MTU issue, it is said in the ROLL WG = charter:

- = In most cases, LLNs will be employed over link layers = with 
restricted frame-sizes, thus a = routing protocol for LLNs should be
= specifically adapted for such link = layers.

and in RFC = 4919, the first characteristic of 6lowpan listed:
   1.   Small packet size.  =
Given that the maximum physical layer packet
        is 127 bytes, the resulting maximum frame size at the media
        access control layer is 102 octets.  Link-layer security imposes
        further overhead, which in the maximum case (21 octets of
        overhead in the AES-CCM-128 case, versus 9 and 13 for AES-CCM-32
        and AES-CCM-64, respectively), leaves 81 octets for data
        =
packets.


More = assumptions can be found in documents of 6lowpan and roll. Therefore, = IMHO, it's safe to build the experience document based on those common = assumptions. In contrast, it will be verbose to list all the possible = special = solutions/technologies. 

best 

YI Jiazi

Hiper= com@LIX, Ecole Polytechnique
Route de Saclay 91128 = Palaiseau Cedex France




(For example, a = deployment using only L2s which provides guaranteed bi-directional links =  for L3 would address this by in the applicability statement = stating "As all L2-links are guaranteed bi-directional, this addresses = the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".)

Thus, we = believe that it would actually be misleading (not to mention, = unnecessarily verbose) to put the "details on the scenarios and testing = environments" into this I-D.

Doing so would = mislead the reader to believe that the issues presented only manifest = themselves in those precise scenarios - which definitely isn't the = case.

JP> see the previous comment and tell us = what you think; we could provide other examples.

Note that we do = not oppose to asking to the WG; we just request you first to add = additional information to proceed forward.

thanks.

JP and = Michael.

JP.


Best,

Thomas

Thanks.

JP and = Michael.


Best,

Thomas, = Ulrich, Yuichi, Jiazi and = Axel



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



= --Apple-Mail=_153F70E8-14EE-40AF-949B-200BC3E77848-- From jpv@cisco.com Wed May 16 06:54:50 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E355721F85A3 for ; Wed, 16 May 2012 06:54:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.471 X-Spam-Level: X-Spam-Status: No, score=-111.471 tagged_above=-999 required=5 tests=[AWL=1.127, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sf69OpgfOEhQ for ; Wed, 16 May 2012 06:54:49 -0700 (PDT) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 05C9221F859F for ; Wed, 16 May 2012 06:54:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=19710; q=dns/txt; s=iport; t=1337176489; x=1338386089; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=bgJZAtvV4Iey6mUAXx0zQUen7v/op4X8AhsAYHrWEaQ=; b=i8mmGPNX2PK7f60LzPfoHDYQ4TUpwGqkBRIAe1qiEn82/HOQzcLnvfW+ lahyMKXVkamiZUsWHzwCYt+xBbDBVwSaR39ehuj5eCDZB0IHhiFK/Kb3I gcaTQyQ6Zl8GdS+MzK8ThTdXTxbDknuHkBI8rMoz+/F91Nsl2X6Z560hR M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkcHAM+ws0+rRDoJ/2dsb2JhbABEgkVYnnmIKwGJSYEHghUBAQEDARIBZhALGC5XBi4Hh2cEAQubFKASixMZhFpiA5V6gRGEZIhigWmCa4Fd X-IronPort-AV: E=Sophos;i="4.75,603,1330905600"; d="scan'208,217";a="42447795" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-3.cisco.com with ESMTP; 16 May 2012 13:54:48 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4GDsmwm003542; Wed, 16 May 2012 13:54:48 GMT Received: from xfe-sjc-222.amer.cisco.com ([128.107.191.87]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 06:54:48 -0700 Received: from [10.60.114.227] ([10.60.114.227]) by xfe-sjc-222.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 06:54:47 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_BAEB054E-62A1-4344-8E52-3BE0016F6718" From: JP Vasseur In-Reply-To: <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> Date: Wed, 16 May 2012 15:54:42 +0200 Message-Id: References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 16 May 2012 13:54:47.0556 (UTC) FILETIME=[74AC0440:01CD336B] Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 13:54:51 -0000 --Apple-Mail=_BAEB054E-62A1-4344-8E52-3BE0016F6718 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi, On May 16, 2012, at 3:17 PM, Thomas Heide Clausen wrote: >=20 > On May 16, 2012, at 15:04 , JP Vasseur wrote: >=20 >> Dear Thomas, >>=20 >> On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: >>=20 >>> Dear JP and Michael, >>>=20 >>> Thank you for your mail. >>>=20 >>> On May 16, 2012, at 09:18 , JP Vasseur wrote: >>>=20 >>>> Dear Thomas, >>>>=20 >>>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>>>=20 >>>>> Dear JP, Michael, all >>>>>=20 >>>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was = presented and discussed at the Paris meeting. >>>>>=20 >>>>> The authors consider the document complete and "done", and are = looking to take it forward in the IETF=20 >>>>> process for publication as "Informational RFC" in the very near = future.=20 >>>>>=20 >>>>> We would therefore like to ask the WG chairs, if the ROLL WG is = willing to accept and progress this=20 >>>>> document towards publication? >>>>=20 >>>> Thanks for your suggestion. So far we haven't see a lot of = discussion/interest from the WG but your request is >>>> perfectly fair. >>>=20 >>> Thank you - I aim to be fair. >>>=20 >>>> So far there are no details on the scenarios and testing = environments that led to the issues that=20 >>>> you reported, thus I would suggest you to first include them so = that people interested could be able to reproduce >>>> it. Once the drat is updated, we'll be happy to pool the WG. >>>>=20 >>>> Does that make sense ? >>>=20 >>> Not really. Let me explain my disagreement. >>>=20 >>> We tried RPL (and, I note, several different independent = implementations of RPL) in a number of different scenarios and = deployments, and observed the behaviors exhibited - noting that what we = observed across the different implementations, scenarios and deployments = was fairly universal. >>>=20 >>> We then went back to the specification, to understand these = behaviors in detail, and understand their universality as independent = from a specific scenario or deployment or implementation - but rather, = as artifacts of the RPL protocol design. >>>=20 >>> We therefore believe that _any_ deployment, scenario or testing = environment of RPL needs to pay attention to the issues presented, and = find a way of addressing them. The way of addressing these issues in a = given deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario. >>=20 >> JP> Thanks for the clarification; that being said, for the WG to make = sure that nothing is "scenario" dependent and the outcome could indeed = apply to all scenarios, >> it might be worth being more explicit. For example, you pointed out = to the MTU issue, to which I mentioned that 15.4g would bring a = solution, so you may want to=20 >> explain that you did not use 15.4g=20 >=20 > This particular issue is fairly well pointed out in section 6, which = references RFC4919 (cf section 2 hereof) - the particular "small MTU" is = not dependent on the specific 127 octets of a specific L2, but a set of = observations that RPL - when faced with a small MTU - may often not be = able to carry a complete control message in a single fragment. Section = 6, 3rd paragraph is fairly explicit as to this. >=20 > More globally, the draft cites = http://datatracker.ietf.org/wg/roll/charter/ - which (other than making = specific reference to 802.15.4 (and not 15.4g) states that: >=20 > "In most cases, LLNs will be employed over link layers with=20 > restricted frame-sizes, thus a routing protocol for LLNs should = be > specifically adapted for such link layers >=20 > We observe some limits on RPL within the framework that the ROLL = charter has set forth. >=20 > I'm not sure I see what more can be done to address this point. >=20 >> and there are a number of such examples =85. >=20 >=20 > Personally, I do not believe that there are, but we (I think I can = speak for all the authors here) would very much appreciate your being = explicit on these examples - least it's hard to discuss them.=20 Well put it differently, it would be beneficial to provide more details = on your testing scenarios for the WG to make sure that nothing=20 is "scenario-dependent" and to make sure that the outcome could indeed = apply to all scenarios, it might be worth being more explicit. Could you do that before polling the WG ? Thanks. JP. >=20 > Thomas >=20 >>>=20 >>> (For example, a deployment using only L2s which provides guaranteed = bi-directional links for L3 would address this by in the applicability = statement stating "As all L2-links are guaranteed bi-directional, this = addresses the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".) >>>=20 >>> Thus, we believe that it would actually be misleading (not to = mention, unnecessarily verbose) to put the "details on the scenarios and = testing environments" into this I-D. >>>=20 >>> Doing so would mislead the reader to believe that the issues = presented only manifest themselves in those precise scenarios - which = definitely isn't the case. >>=20 >> JP> see the previous comment and tell us what you think; we could = provide other examples. >>=20 >> Note that we do not oppose to asking to the WG; we just request you = first to add additional information to proceed forward. >>=20 >> thanks. >>=20 >> JP and Michael. >>=20 >> JP. >>=20 >>>=20 >>> Best, >>>=20 >>> Thomas >>>=20 >>>> Thanks. >>>>=20 >>>> JP and Michael. >>>>=20 >>>>>=20 >>>>> Best, >>>>>=20 >>>>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_BAEB054E-62A1-4344-8E52-3BE0016F6718 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252

On May 16, = 2012, at 15:04 , JP Vasseur wrote:

Dear = Thomas,

On May 16, 2012, at 2:08 PM, Thomas Heide Clausen = wrote:

Dear JP and = Michael,

Thank you for = your mail.

On May 16, = 2012, at 09:18 , JP Vasseur wrote:

Dear Thomas,

On May 11, 2012, at 8:25 AM, = Thomas Heide Clausen wrote:

Dear = JP, Michael, all

Upon = JPs invitation, draft-clausen-lln-rpl-experiences was presented and = discussed at the Paris = meeting.

The = authors consider the document complete and "done", and are looking to = take it forward in the IETF =
process = for publication as "Informational RFC" in the very near future. =

We = would therefore like to ask the WG chairs, if the ROLL WG is willing to = accept and progress this =
document= towards = publication?

Thanks for your suggestion. So = far we haven't see a lot of discussion/interest from the WG but your = request is
perfectly = fair.

Thank you - I = aim to be fair.

So far there are no details on the scenarios and testing = environments that led to the issues that =
you reported, thus I would suggest you to first include = them so that people interested could be able to = reproduce
it. Once the drat is updated, = we'll be happy to pool the WG.

Does that make sense = ?

Not really. Let = me explain my disagreement.

We tried RPL = (and, I note, several different independent implementations of RPL) in a = number of different scenarios and deployments, and observed the = behaviors exhibited - noting that what we observed across the different = implementations, scenarios and deployments was fairly = universal.

We then went = back to the specification, to understand these behaviors in detail, and = understand their universality as independent from a specific scenario or = deployment or implementation - but rather, as artifacts of the RPL = protocol design.

We therefore = believe that _any_ deployment, scenario or testing environment of RPL = needs to pay attention to the issues presented, and find a way of = addressing them. The way of addressing these issues in a given = deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario.

JP> = Thanks for the clarification; that being said, for the WG to make sure = that nothing is "scenario" dependent and the outcome could indeed apply = to all scenarios,
it might be worth being more explicit. For example, = you pointed out to the MTU issue, to which I mentioned that 15.4g would = bring a solution, so you may want to
explain that you did not use = 15.4g 

This particular = issue is fairly well pointed out in section 6, which references RFC4919 = (cf section 2 hereof) - the particular "small MTU" is not dependent on = the specific 127 octets of a specific L2, but a set of observations that = RPL - when faced with a small MTU - may often not be able to carry a = complete control message in a single fragment. Section 6, 3rd = paragraph is fairly explicit as to this.

More = globally, the draft cites http://datatracker.i= etf.org/wg/roll/charter/ - which (other than making specific = reference to 802.15.4 (and not 15.4g) states that:

"In most cases, LLNs will be = employed over link layers with 
=  restricted frame-sizes, thus a routing protocol for LLNs = should be
=  specifically adapted for such link = layers

We observe some limits on RPL within the framework that the ROLL = charter has set forth.

I'm not sure I see what more can be done to address this = point.

and = there are a number of such examples = =85.

Personally, I do not = believe that there are, but  we (I think I can speak for all = the authors here) would very much appreciate your being explicit on = these examples - least it's hard to discuss = them. 

Well put it = differently, it would be beneficial to provide more details on your = testing scenarios for the WG to make sure that = nothing 
is "scenario-dependent" and to make sure that = the outcome could indeed apply to all scenarios, it might be worth = being more explicit.

Could you do that before = polling the WG = ?

Thanks.

JP.

<= blockquote type=3D"cite">

(For example, a deployment using only L2s which provides = guaranteed bi-directional links  for L3 would address this by in = the applicability statement stating "As all L2-links are guaranteed = bi-directional, this addresses the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".)

Thus, we = believe that it would actually be misleading (not to mention, = unnecessarily verbose) to put the "details on the scenarios and testing = environments" into this I-D.

Doing so would = mislead the reader to believe that the issues presented only manifest = themselves in those precise scenarios - which definitely isn't the = case.

JP> see the previous comment and tell us = what you think; we could provide other = examples.

Note = that we do not oppose to asking to the WG; we just request you first to = add additional information to proceed forward.

thanks.

JP = and Michael.

JP.


Best,

Thomas

Thanks.

JP and = Michael.


Best,

Thomas, = Ulrich, Yuichi, Jiazi and = Axel





= --Apple-Mail=_BAEB054E-62A1-4344-8E52-3BE0016F6718-- From ietf@thomasclausen.org Wed May 16 06:57:02 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99E921F864E for ; Wed, 16 May 2012 06:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.639 X-Spam-Level: X-Spam-Status: No, score=-3.639 tagged_above=-999 required=5 tests=[AWL=0.625, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uk6Y-6oJIKOU for ; Wed, 16 May 2012 06:57:01 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 908CD21F85A3 for ; Wed, 16 May 2012 06:57:01 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 83A5AA30E5 for ; Wed, 16 May 2012 06:57:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 5233B1BDA58B; Wed, 16 May 2012 06:57:01 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id CD78B1BDA594; Wed, 16 May 2012 06:56:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_5151D085-C042-446D-A51F-31CA5018B067" From: Thomas Heide Clausen In-Reply-To: Date: Wed, 16 May 2012 15:56:58 +0200 Message-Id: <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> To: JP Vasseur X-Mailer: Apple Mail (2.1257) Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 13:57:02 -0000 --Apple-Mail=_5151D085-C042-446D-A51F-31CA5018B067 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear JP, On May 16, 2012, at 15:54 , JP Vasseur wrote: > Hi, >=20 > On May 16, 2012, at 3:17 PM, Thomas Heide Clausen wrote: >=20 >>=20 >> On May 16, 2012, at 15:04 , JP Vasseur wrote: >>=20 >>> Dear Thomas, >>>=20 >>> On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: >>>=20 >>>> Dear JP and Michael, >>>>=20 >>>> Thank you for your mail. >>>>=20 >>>> On May 16, 2012, at 09:18 , JP Vasseur wrote: >>>>=20 >>>>> Dear Thomas, >>>>>=20 >>>>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>>>>=20 >>>>>> Dear JP, Michael, all >>>>>>=20 >>>>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was = presented and discussed at the Paris meeting. >>>>>>=20 >>>>>> The authors consider the document complete and "done", and are = looking to take it forward in the IETF=20 >>>>>> process for publication as "Informational RFC" in the very near = future.=20 >>>>>>=20 >>>>>> We would therefore like to ask the WG chairs, if the ROLL WG is = willing to accept and progress this=20 >>>>>> document towards publication? >>>>>=20 >>>>> Thanks for your suggestion. So far we haven't see a lot of = discussion/interest from the WG but your request is >>>>> perfectly fair. >>>>=20 >>>> Thank you - I aim to be fair. >>>>=20 >>>>> So far there are no details on the scenarios and testing = environments that led to the issues that=20 >>>>> you reported, thus I would suggest you to first include them so = that people interested could be able to reproduce >>>>> it. Once the drat is updated, we'll be happy to pool the WG. >>>>>=20 >>>>> Does that make sense ? >>>>=20 >>>> Not really. Let me explain my disagreement. >>>>=20 >>>> We tried RPL (and, I note, several different independent = implementations of RPL) in a number of different scenarios and = deployments, and observed the behaviors exhibited - noting that what we = observed across the different implementations, scenarios and deployments = was fairly universal. >>>>=20 >>>> We then went back to the specification, to understand these = behaviors in detail, and understand their universality as independent = from a specific scenario or deployment or implementation - but rather, = as artifacts of the RPL protocol design. >>>>=20 >>>> We therefore believe that _any_ deployment, scenario or testing = environment of RPL needs to pay attention to the issues presented, and = find a way of addressing them. The way of addressing these issues in a = given deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario. >>>=20 >>> JP> Thanks for the clarification; that being said, for the WG to = make sure that nothing is "scenario" dependent and the outcome could = indeed apply to all scenarios, >>> it might be worth being more explicit. For example, you pointed out = to the MTU issue, to which I mentioned that 15.4g would bring a = solution, so you may want to=20 >>> explain that you did not use 15.4g=20 >>=20 >> This particular issue is fairly well pointed out in section 6, which = references RFC4919 (cf section 2 hereof) - the particular "small MTU" is = not dependent on the specific 127 octets of a specific L2, but a set of = observations that RPL - when faced with a small MTU - may often not be = able to carry a complete control message in a single fragment. Section = 6, 3rd paragraph is fairly explicit as to this. >>=20 >> More globally, the draft cites = http://datatracker.ietf.org/wg/roll/charter/ - which (other than making = specific reference to 802.15.4 (and not 15.4g) states that: >>=20 >> "In most cases, LLNs will be employed over link layers with=20 >> restricted frame-sizes, thus a routing protocol for LLNs should = be >> specifically adapted for such link layers >>=20 >> We observe some limits on RPL within the framework that the ROLL = charter has set forth. >>=20 >> I'm not sure I see what more can be done to address this point. >>=20 >>> and there are a number of such examples =85. >>=20 >>=20 >> Personally, I do not believe that there are, but we (I think I can = speak for all the authors here) would very much appreciate your being = explicit on these examples - least it's hard to discuss them.=20 >=20 > Well put it differently, it would be beneficial to provide more = details on your testing scenarios for the WG to make sure that nothing=20= > is "scenario-dependent" and to make sure that the outcome could indeed = apply to all scenarios, it might be worth being more explicit. >=20 > Could you do that before polling the WG ? >=20 Again, I think that reading the I-D, and the RPL RFC, should provide = sufficient information where necessary.=20 All of the issues we have brought forward can be understood by looking = at the RPL RFC. The "testing scenarios" simply pointed us to what we should look at in = the RPL RFC Best, Thomas > Thanks. >=20 > JP. >=20 >>=20 >> Thomas >>=20 >>>>=20 >>>> (For example, a deployment using only L2s which provides guaranteed = bi-directional links for L3 would address this by in the applicability = statement stating "As all L2-links are guaranteed bi-directional, this = addresses the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".) >>>>=20 >>>> Thus, we believe that it would actually be misleading (not to = mention, unnecessarily verbose) to put the "details on the scenarios and = testing environments" into this I-D. >>>>=20 >>>> Doing so would mislead the reader to believe that the issues = presented only manifest themselves in those precise scenarios - which = definitely isn't the case. >>>=20 >>> JP> see the previous comment and tell us what you think; we could = provide other examples. >>>=20 >>> Note that we do not oppose to asking to the WG; we just request you = first to add additional information to proceed forward. >>>=20 >>> thanks. >>>=20 >>> JP and Michael. >>>=20 >>> JP. >>>=20 >>>>=20 >>>> Best, >>>>=20 >>>> Thomas >>>>=20 >>>>> Thanks. >>>>>=20 >>>>> JP and Michael. >>>>>=20 >>>>>>=20 >>>>>> Best, >>>>>>=20 >>>>>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_5151D085-C042-446D-A51F-31CA5018B067 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = JP,

On May 16, 2012, at 15:54 , JP Vasseur = wrote:

Hi,

On = May 16, 2012, at 3:17 PM, Thomas Heide Clausen wrote:


On May 16, 2012, = at 15:04 , JP Vasseur wrote:

Dear = Thomas,

On May 16, 2012, at 2:08 PM, Thomas Heide Clausen = wrote:

Dear JP and = Michael,

Thank you for = your mail.

On May 16, = 2012, at 09:18 , JP Vasseur wrote:

Dear Thomas,

On May 11, 2012, at 8:25 AM, = Thomas Heide Clausen wrote:

Dear = JP, Michael, all

Upon = JPs invitation, draft-clausen-lln-rpl-experiences was presented and = discussed at the Paris = meeting.

The = authors consider the document complete and "done", and are looking to = take it forward in the IETF =
process = for publication as "Informational RFC" in the very near future. =

We = would therefore like to ask the WG chairs, if the ROLL WG is willing to = accept and progress this =
document= towards = publication?

Thanks for your suggestion. So = far we haven't see a lot of discussion/interest from the WG but your = request is
perfectly = fair.

Thank you - I = aim to be fair.

So far there are no details on the scenarios and testing = environments that led to the issues that =
you reported, thus I would suggest you to first include = them so that people interested could be able to = reproduce
it. Once the drat is updated, = we'll be happy to pool the WG.

Does that make sense = ?

Not really. Let = me explain my disagreement.

We tried RPL = (and, I note, several different independent implementations of RPL) in a = number of different scenarios and deployments, and observed the = behaviors exhibited - noting that what we observed across the different = implementations, scenarios and deployments was fairly = universal.

We then went = back to the specification, to understand these behaviors in detail, and = understand their universality as independent from a specific scenario or = deployment or implementation - but rather, as artifacts of the RPL = protocol design.

We therefore = believe that _any_ deployment, scenario or testing environment of RPL = needs to pay attention to the issues presented, and find a way of = addressing them. The way of addressing these issues in a given = deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario.

JP> = Thanks for the clarification; that being said, for the WG to make sure = that nothing is "scenario" dependent and the outcome could indeed apply = to all scenarios,
it might be worth being more explicit. For example, = you pointed out to the MTU issue, to which I mentioned that 15.4g would = bring a solution, so you may want to
explain that you did not use = 15.4g 

This particular = issue is fairly well pointed out in section 6, which references RFC4919 = (cf section 2 hereof) - the particular "small MTU" is not dependent on = the specific 127 octets of a specific L2, but a set of observations that = RPL - when faced with a small MTU - may often not be able to carry a = complete control message in a single fragment. Section 6, 3rd = paragraph is fairly explicit as to this.

More = globally, the draft cites http://datatracker.i= etf.org/wg/roll/charter/ - which (other than making specific = reference to 802.15.4 (and not 15.4g) states that:

"In most cases, LLNs will be = employed over link layers with 
=  restricted frame-sizes, thus a routing protocol for LLNs = should be
=  specifically adapted for such link = layers

We observe some limits on RPL within the framework that the ROLL = charter has set forth.

I'm not sure I see what more can be done to address this = point.

and = there are a number of such examples = =85.

Personally, I do not = believe that there are, but  we (I think I can speak for all = the authors here) would very much appreciate your being explicit on = these examples - least it's hard to discuss = them. 

Well put it = differently, it would be beneficial to provide more details on your = testing scenarios for the WG to make sure that = nothing 
is "scenario-dependent" and to make sure that = the outcome could indeed apply to all scenarios, it might be worth = being more = explicit.


Best,

Thomas

Thanks.

JP.


(For example, a deployment using only L2s which provides = guaranteed bi-directional links  for L3 would address this by in = the applicability statement stating "As all L2-links are guaranteed = bi-directional, this addresses the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".)

Thus, we = believe that it would actually be misleading (not to mention, = unnecessarily verbose) to put the "details on the scenarios and testing = environments" into this I-D.

Doing so would = mislead the reader to believe that the issues presented only manifest = themselves in those precise scenarios - which definitely isn't the = case.

JP> see the previous comment and tell us = what you think; we could provide other = examples.

Note = that we do not oppose to asking to the WG; we just request you first to = add additional information to proceed forward.

thanks.

JP = and Michael.

JP.


Best,

Thomas

Thanks.

JP and = Michael.


Best,

Thomas, = Ulrich, Yuichi, Jiazi and = Axel






= --Apple-Mail=_5151D085-C042-446D-A51F-31CA5018B067-- From c.chauvenet@watteco.com Wed May 16 07:14:38 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B787421F85BE for ; Wed, 16 May 2012 07:14:38 -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=2.300, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eQgREmBeDPkg for ; Wed, 16 May 2012 07:14:37 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 0D26521F85F7 for ; Wed, 16 May 2012 07:14:30 -0700 (PDT) Received: from mail51-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.23; Wed, 16 May 2012 14:14:23 +0000 Received: from mail51-tx2 (localhost [127.0.0.1]) by mail51-tx2-R.bigfish.com (Postfix) with ESMTP id D962A220213; Wed, 16 May 2012 14:14:23 +0000 (UTC) X-SpamScore: -32 X-BigFish: VPS-32(zz9371Ic89bh1dbaI1432N98dK1447Izz1202hzz1033IL8275dhz2dh2a8h668h839h946hd25he5bh) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT002.eurprd05.prod.outlook.com; RD:none; EFVD:NLI Received: from mail51-tx2 (localhost.localdomain [127.0.0.1]) by mail51-tx2 (MessageSwitch) id 1337177659990672_30664; Wed, 16 May 2012 14:14:19 +0000 (UTC) Received: from TX2EHSMHS038.bigfish.com (unknown [10.9.14.244]) by mail51-tx2.bigfish.com (Postfix) with ESMTP id E85A4380066; Wed, 16 May 2012 14:14:19 +0000 (UTC) Received: from DBXPRD0510HT002.eurprd05.prod.outlook.com (157.56.252.165) by TX2EHSMHS038.bigfish.com (10.9.99.138) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 16 May 2012 14:14:15 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.244]) by DBXPRD0510HT002.eurprd05.prod.outlook.com ([10.255.67.165]) with mapi id 14.16.0152.000; Wed, 16 May 2012 14:13:57 +0000 From: C Chauvenet To: JP Vasseur Thread-Topic: [Roll] Way forward for draft-clausen-lln-rpl-experiences Thread-Index: AQHNLz7f4nHZNQpKzkGVpF0j12dI45bMCZgAgABRMICAAA+CgIAAE3eA Date: Wed, 16 May 2012 14:13:56 +0000 Message-ID: <22B18A3C-B327-4AD6-9D94-901CF225BE98@watteco.com> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.48.33] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 14:14:38 -0000 Hi,=20 I definitely agree that implementation feedback is always good to know, so = your experiences are welcomed. I also think that problems investigations need a complete and exact view, s= o I would encourage you to put much more details about the scenario and the= environment where you experimentations took place. For instance, I would enjoy a "RPL Implementation Description" section in y= ou draft listing the hardware your used, your RPL parameters, the RPL draft= s and mechanisms implemented, your OS etc... If I read a paper with orthogonal observations with the same level of detai= ls as in your draft, then how could I forge my opinion ? Looking at this draft, it seems that it gathers lots of previous discussion= s that occurred during the past year on various mailing lists, and IETF mee= tings. Does your experimentations takes care about these recommendations ? If not, does your draft mention the propositions that have been made to add= ress the problems you point out in your draft ? I think it could be worth to leverage on these previous discussions. Your draft is a list of Description and Observations. Maybe you could add a "Resolution Proposal" section for each problem, gathe= ring previous discussion and your own proposals ? Identifying what is wrong in your implementation is a good first step, but = the hardest part is to propose some corrections. Best Regards, C=E9dric Chauvenet. Le 16 mai 2012 =E0 15:04, JP Vasseur a =E9crit : > Dear Thomas, >=20 > On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: >=20 >> Dear JP and Michael, >>=20 >> Thank you for your mail. >>=20 >> On May 16, 2012, at 09:18 , JP Vasseur wrote: >>=20 >>> Dear Thomas, >>>=20 >>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>>=20 >>>> Dear JP, Michael, all >>>>=20 >>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented a= nd discussed at the Paris meeting. >>>>=20 >>>> The authors consider the document complete and "done", and are looking= to take it forward in the IETF=20 >>>> process for publication as "Informational RFC" in the very near future= .=20 >>>>=20 >>>> We would therefore like to ask the WG chairs, if the ROLL WG is willin= g to accept and progress this=20 >>>> document towards publication? >>>=20 >>> Thanks for your suggestion. So far we haven't see a lot of discussion/i= nterest from the WG but your request is >>> perfectly fair. >>=20 >> Thank you - I aim to be fair. >>=20 >>> So far there are no details on the scenarios and testing environments t= hat led to the issues that=20 >>> you reported, thus I would suggest you to first include them so that pe= ople interested could be able to reproduce >>> it. Once the drat is updated, we'll be happy to pool the WG. >>>=20 >>> Does that make sense ? >>=20 >> Not really. Let me explain my disagreement. >>=20 >> We tried RPL (and, I note, several different independent implementations= of RPL) in a number of different scenarios and deployments, and observed t= he behaviors exhibited - noting that what we observed across the different = implementations, scenarios and deployments was fairly universal. >>=20 >> We then went back to the specification, to understand these behaviors in= detail, and understand their universality as independent from a specific s= cenario or deployment or implementation - but rather, as artifacts of the R= PL protocol design. >>=20 >> We therefore believe that _any_ deployment, scenario or testing environm= ent of RPL needs to pay attention to the issues presented, and find a way o= f addressing them. The way of addressing these issues in a given deployment= or scenario would be appropriate for an "applicability statement" for that= deployment or scenario. >=20 > JP> Thanks for the clarification; that being said, for the WG to make sur= e that nothing is "scenario" dependent and the outcome could indeed apply t= o all scenarios, > it might be worth being more explicit. For example, you pointed out to th= e MTU issue, to which I mentioned that 15.4g would bring a solution, so you= may want to=20 > explain that you did not use 15.4g and there are a number of such example= s =85. >=20 >>=20 >> (For example, a deployment using only L2s which provides guaranteed bi-d= irectional links for L3 would address this by in the applicability stateme= nt stating "As all L2-links are guaranteed bi-directional, this addresses t= he issues raised in section 9 in draft-clausen-lln-rpl-experiences".) >>=20 >> Thus, we believe that it would actually be misleading (not to mention, u= nnecessarily verbose) to put the "details on the scenarios and testing envi= ronments" into this I-D. >>=20 >> Doing so would mislead the reader to believe that the issues presented o= nly manifest themselves in those precise scenarios - which definitely isn't= the case. >=20 > JP> see the previous comment and tell us what you think; we could provide= other examples. >=20 > Note that we do not oppose to asking to the WG; we just request you first= to add additional information to proceed forward. >=20 > thanks. >=20 > JP and Michael. >=20 > JP. >=20 >>=20 >> Best, >>=20 >> Thomas >>=20 >>> Thanks. >>>=20 >>> JP and Michael. >>>=20 >>>>=20 >>>> Best, >>>>=20 >>>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>>=20 >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 From prvs=4766ac5fc=mukul@uwm.edu Wed May 16 07:54:00 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C003221F8625 for ; Wed, 16 May 2012 07:54:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.522 X-Spam-Level: X-Spam-Status: No, score=-7.522 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7K1GTJBM0wUn for ; Wed, 16 May 2012 07:53:59 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 389D621F8609 for ; Wed, 16 May 2012 07:53:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAHi+s09/AAAB/2dsb2JhbABEhXyxKwEBAQMBAQEBIEsLBQcPEQQBAQECAg0ZAikoCAYTG4duBQuoNYlziQUEgSaJbRmEJ4EVA4hjjReQQIMHgUE Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 25FA61FD0C9; Wed, 16 May 2012 09:53:58 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OkXKEQSUvT6O; Wed, 16 May 2012 09:53:57 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 691431FD0C8; Wed, 16 May 2012 09:53:57 -0500 (CDT) Date: Wed, 16 May 2012 09:53:57 -0500 (CDT) From: Mukul Goyal To: C Chauvenet Message-ID: <418765560.417509.1337180037325.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <22B18A3C-B327-4AD6-9D94-901CF225BE98@watteco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 14:54:00 -0000 I agree with Cedric. Issues that Cedric has raised are very basic and shoul= d have already been taken care of in the document. Seriously, do the author= s think that this document would pass the muster for publication in any dec= ent academic journal? Right now, the draft reads more like propaganda than = information: written to bad mouth a protocol on the basis of biased/frivolo= us arguments. Why would the authors completely ignore P2P-RPL even though i= t resolves many issues they have pointed out. There are numerous similar si= ns of omission spread throughout the document. As a result, most conclusion= s the document reaches are open to doubt if not outright incorrect. Sure, R= PL is not a perfect protocol - no protocol is. But this document is not an = unbiased scientific analysis of the protocol. As Pascal said, this document= could have served a valuable constructive purpose. But, perhaps this was n= ot the intention of the authors. This document should be recognized for wha= t it is: a political document written to further a particular destructive a= genda. Thanks Mukul ----- Original Message ----- From: "C Chauvenet" To: "JP Vasseur" Cc: "roll WG" , "Michael Richardson" Sent: Wednesday, May 16, 2012 9:13:56 AM Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences Hi,=20 I definitely agree that implementation feedback is always good to know, so = your experiences are welcomed. I also think that problems investigations need a complete and exact view, s= o I would encourage you to put much more details about the scenario and the= environment where you experimentations took place. For instance, I would enjoy a "RPL Implementation Description" section in y= ou draft listing the hardware your used, your RPL parameters, the RPL draft= s and mechanisms implemented, your OS etc... If I read a paper with orthogonal observations with the same level of detai= ls as in your draft, then how could I forge my opinion ? Looking at this draft, it seems that it gathers lots of previous discussion= s that occurred during the past year on various mailing lists, and IETF mee= tings. Does your experimentations takes care about these recommendations ? If not, does your draft mention the propositions that have been made to add= ress the problems you point out in your draft ? I think it could be worth to leverage on these previous discussions. Your draft is a list of Description and Observations. Maybe you could add a "Resolution Proposal" section for each problem, gathe= ring previous discussion and your own proposals ? Identifying what is wrong in your implementation is a good first step, but = the hardest part is to propose some corrections. Best Regards, C=C3=A9dric Chauvenet. Le 16 mai 2012 =C3=A0 15:04, JP Vasseur a =C3=A9crit : > Dear Thomas, >=20 > On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: >=20 >> Dear JP and Michael, >>=20 >> Thank you for your mail. >>=20 >> On May 16, 2012, at 09:18 , JP Vasseur wrote: >>=20 >>> Dear Thomas, >>>=20 >>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>>=20 >>>> Dear JP, Michael, all >>>>=20 >>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented a= nd discussed at the Paris meeting. >>>>=20 >>>> The authors consider the document complete and "done", and are looking= to take it forward in the IETF=20 >>>> process for publication as "Informational RFC" in the very near future= .=20 >>>>=20 >>>> We would therefore like to ask the WG chairs, if the ROLL WG is willin= g to accept and progress this=20 >>>> document towards publication? >>>=20 >>> Thanks for your suggestion. So far we haven't see a lot of discussion/i= nterest from the WG but your request is >>> perfectly fair. >>=20 >> Thank you - I aim to be fair. >>=20 >>> So far there are no details on the scenarios and testing environments t= hat led to the issues that=20 >>> you reported, thus I would suggest you to first include them so that pe= ople interested could be able to reproduce >>> it. Once the drat is updated, we'll be happy to pool the WG. >>>=20 >>> Does that make sense ? >>=20 >> Not really. Let me explain my disagreement. >>=20 >> We tried RPL (and, I note, several different independent implementations= of RPL) in a number of different scenarios and deployments, and observed t= he behaviors exhibited - noting that what we observed across the different = implementations, scenarios and deployments was fairly universal. >>=20 >> We then went back to the specification, to understand these behaviors in= detail, and understand their universality as independent from a specific s= cenario or deployment or implementation - but rather, as artifacts of the R= PL protocol design. >>=20 >> We therefore believe that _any_ deployment, scenario or testing environm= ent of RPL needs to pay attention to the issues presented, and find a way o= f addressing them. The way of addressing these issues in a given deployment= or scenario would be appropriate for an "applicability statement" for that= deployment or scenario. >=20 > JP> Thanks for the clarification; that being said, for the WG to make sur= e that nothing is "scenario" dependent and the outcome could indeed apply t= o all scenarios, > it might be worth being more explicit. For example, you pointed out to th= e MTU issue, to which I mentioned that 15.4g would bring a solution, so you= may want to=20 > explain that you did not use 15.4g and there are a number of such example= s =E2=80=A6. >=20 >>=20 >> (For example, a deployment using only L2s which provides guaranteed bi-d= irectional links for L3 would address this by in the applicability stateme= nt stating "As all L2-links are guaranteed bi-directional, this addresses t= he issues raised in section 9 in draft-clausen-lln-rpl-experiences".) >>=20 >> Thus, we believe that it would actually be misleading (not to mention, u= nnecessarily verbose) to put the "details on the scenarios and testing envi= ronments" into this I-D. >>=20 >> Doing so would mislead the reader to believe that the issues presented o= nly manifest themselves in those precise scenarios - which definitely isn't= the case. >=20 > JP> see the previous comment and tell us what you think; we could provide= other examples. >=20 > Note that we do not oppose to asking to the WG; we just request you first= to add additional information to proceed forward. >=20 > thanks. >=20 > JP and Michael. >=20 > JP. >=20 >>=20 >> Best, >>=20 >> Thomas >>=20 >>> Thanks. >>>=20 >>> JP and Michael. >>>=20 >>>>=20 >>>> Best, >>>>=20 >>>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>>=20 >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From ietf@thomasclausen.org Wed May 16 08:14:24 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E12D421F865E for ; Wed, 16 May 2012 08:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWFxD9G1KKuJ for ; Wed, 16 May 2012 08:14:23 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id A0AC721F857D for ; Wed, 16 May 2012 08:14:23 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 92A30A31D3 for ; Wed, 16 May 2012 08:14:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 4DA0B1BDB0E3; Wed, 16 May 2012 08:14:22 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [172.20.10.10] (37-8-182-100.coucou-networks.fr [37.8.182.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 9DAE91BDB0DF; Wed, 16 May 2012 08:14:19 -0700 (PDT) References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <22B18A3C-B327-4AD6-9D94-901CF225BE98@watteco.com> In-Reply-To: <22B18A3C-B327-4AD6-9D94-901CF225BE98@watteco.com> Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=utf-8 Message-Id: <0AA713FC-2C91-41E4-80BF-3DA3FF450324@thomasclausen.org> Content-Transfer-Encoding: quoted-printable From: Thomas Heide Clausen Date: Wed, 16 May 2012 17:08:10 +0200 To: C Chauvenet X-Mailer: iPad Mail (9B206) Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 15:14:25 -0000 Dear Cedric, Thank you for your email. Comments below. On 16 May 2012, at 16:13, C Chauvenet wrote: > Hi,=20 >=20 > I definitely agree that implementation feedback is always good to know, so= your experiences are welcomed. >=20 > I also think that problems investigations need a complete and exact view, s= o I would encourage you to put much more details about the scenario and the e= nvironment where you experimentations took place. > For instance, I would enjoy a "RPL Implementation Description" section in y= ou draft listing the hardware your used, your RPL parameters, the RPL drafts= and mechanisms implemented, your OS etc... As I indicated to JP already: 1) this draft is not "just" based on a single scenario, environment or= implementation=20 (and, therefore, not "just" based on a single test).=20 2) the observations that we made during the test_S_ served to make us l= ook at the RPL RFC again, to explain our observations and to generalize them from t= he written word of that RFC. Therefore, I do not think that any such description would bring anything (ot= her than entropy and delay) to the process. The RPL RFC and this I-D is more= than sufficient. As to what features were implemented, that is easy to answer: the RPL RFC (e= xcept for security) to the letter and with the parameters suggested there, a= nd OF0. However, even the parameters are immaterial for the observations lis= ted in this I-D. > If I read a paper with orthogonal observations with the same level of deta= ils as in your draft, then how could I forge my opinion ? I'd suggest reading the indicated parts of the RPL RFC conjointly with this I= -D. Again, the observations that we present in this I-D make exclusive refer= ence to RPL, and not to a specific implementation or deployment. > Looking at this draft, it seems that it gathers lots of previous discussio= ns that occurred during the past year on various mailing lists, and IETF mee= tings. >=20 > Does your experimentations takes care about these recommendations ? Again, the issues raised in this I-D are based on what can be observed from t= he RPL RFC.=20 If there are additional considerations required (which you seem to indicate t= o be the case) which are not reflected in the RPL RFC, in order to overcome t= he issues raised, then that indeed should be a big problem for the IETF and f= or ROLL.... > If not, does your draft mention the propositions that have been made to ad= dress the problems you point out in your draft ? > I think it could be worth to leverage on these previous discussions. I firmly disagree. The IETF and ROLL has published an RFC - that's what this= I-D discusses.=20 Discussing what may have been proposed in other media would be entirely out o= f scope. > Your draft is a list of Description and Observations. > Maybe you could add a "Resolution Proposal" section for each problem, gath= ering previous discussion and your own proposals ? Nope. That's not the objective of this I-D. I would venture that if the WG i= s serious about applicability statements, then those applicability statement= s would be the place for discussion of "how this issue, raised in this I-D, i= s addressed or moot for a given deployment". > Identifying what is wrong in your implementation Considering that these observations are not implementation-specific, but are= directly on the RPL RFC, I venture the observations that there's nothing "w= rong in my implementation" here. Thomas > is a good first step, but the hardest part is to propose some corrections.= > Best Regards, >=20 > C=C3=A9dric Chauvenet. >=20 > Le 16 mai 2012 =C3=A0 15:04, JP Vasseur a =C3=A9crit : >=20 >> Dear Thomas, >>=20 >> On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: >>=20 >>> Dear JP and Michael, >>>=20 >>> Thank you for your mail. >>>=20 >>> On May 16, 2012, at 09:18 , JP Vasseur wrote: >>>=20 >>>> Dear Thomas, >>>>=20 >>>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>>>=20 >>>>> Dear JP, Michael, all >>>>>=20 >>>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented a= nd discussed at the Paris meeting. >>>>>=20 >>>>> The authors consider the document complete and "done", and are looking= to take it forward in the IETF=20 >>>>> process for publication as "Informational RFC" in the very near future= .=20 >>>>>=20 >>>>> We would therefore like to ask the WG chairs, if the ROLL WG is willin= g to accept and progress this=20 >>>>> document towards publication? >>>>=20 >>>> Thanks for your suggestion. So far we haven't see a lot of discussion/i= nterest from the WG but your request is >>>> perfectly fair. >>>=20 >>> Thank you - I aim to be fair. >>>=20 >>>> So far there are no details on the scenarios and testing environments t= hat led to the issues that=20 >>>> you reported, thus I would suggest you to first include them so that pe= ople interested could be able to reproduce >>>> it. Once the drat is updated, we'll be happy to pool the WG. >>>>=20 >>>> Does that make sense ? >>>=20 >>> Not really. Let me explain my disagreement. >>>=20 >>> We tried RPL (and, I note, several different independent implementations= of RPL) in a number of different scenarios and deployments, and observed th= e behaviors exhibited - noting that what we observed across the different im= plementations, scenarios and deployments was fairly universal. >>>=20 >>> We then went back to the specification, to understand these behaviors in= detail, and understand their universality as independent from a specific sc= enario or deployment or implementation - but rather, as artifacts of the RPL= protocol design. >>>=20 >>> We therefore believe that _any_ deployment, scenario or testing environm= ent of RPL needs to pay attention to the issues presented, and find a way of= addressing them. The way of addressing these issues in a given deployment o= r scenario would be appropriate for an "applicability statement" for that de= ployment or scenario. >>=20 >> JP> Thanks for the clarification; that being said, for the WG to make sur= e that nothing is "scenario" dependent and the outcome could indeed apply to= all scenarios, >> it might be worth being more explicit. For example, you pointed out to th= e MTU issue, to which I mentioned that 15.4g would bring a solution, so you m= ay want to=20 >> explain that you did not use 15.4g and there are a number of such example= s =E2=80=A6. >>=20 >>>=20 >>> (For example, a deployment using only L2s which provides guaranteed bi-d= irectional links for L3 would address this by in the applicability statemen= t stating "As all L2-links are guaranteed bi-directional, this addresses the= issues raised in section 9 in draft-clausen-lln-rpl-experiences".) >>>=20 >>> Thus, we believe that it would actually be misleading (not to mention, u= nnecessarily verbose) to put the "details on the scenarios and testing envir= onments" into this I-D. >>>=20 >>> Doing so would mislead the reader to believe that the issues presented o= nly manifest themselves in those precise scenarios - which definitely isn't t= he case. >>=20 >> JP> see the previous comment and tell us what you think; we could provide= other examples. >>=20 >> Note that we do not oppose to asking to the WG; we just request you first= to add additional information to proceed forward. >>=20 >> thanks. >>=20 >> JP and Michael. >>=20 >> JP. >>=20 >>>=20 >>> Best, >>>=20 >>> Thomas >>>=20 >>>> Thanks. >>>>=20 >>>> JP and Michael. >>>>=20 >>>>>=20 >>>>> Best, >>>>>=20 >>>>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 >=20 From richard.kelsey@ember.com Wed May 16 08:43:40 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346EB21F8646 for ; Wed, 16 May 2012 08:43:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.787 X-Spam-Level: X-Spam-Status: No, score=-5.787 tagged_above=-999 required=5 tests=[AWL=0.812, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQDxWMAbw2Mr for ; Wed, 16 May 2012 08:43:39 -0700 (PDT) Received: from p01c12o141.mxlogic.net (p01c12o141.mxlogic.net [208.65.145.64]) by ietfa.amsl.com (Postfix) with ESMTP id 973EC21F8622 for ; Wed, 16 May 2012 08:43:39 -0700 (PDT) Received: from unknown [216.236.254.3] (EHLO p01c12o141.mxlogic.net) by p01c12o141.mxlogic.net(mxl_mta-6.14.0-1) with ESMTP id b2bc3bf4.78dcd940.10378.00-575.26583.p01c12o141.mxlogic.net (envelope-from ); Wed, 16 May 2012 09:43:39 -0600 (MDT) X-MXL-Hash: 4fb3cb2b1fd46aa5-84e560da3125459739ca54a5f4264b3095937173 Received: from unknown [216.236.254.3] (EHLO usmail.ember.com) by p01c12o141.mxlogic.net(mxl_mta-6.14.0-1) over TLS secured channel with ESMTP id 62bc3bf4.0.10358.00-368.26534.p01c12o141.mxlogic.net (envelope-from ); Wed, 16 May 2012 09:43:38 -0600 (MDT) X-MXL-Hash: 4fb3cb2a0288353d-04efcfb51a39a42cafe8f5699d09770e5abd5359 Received: from kelsey-ws.hq.ember.com (192.168.81.75) by usmail.ember.com (192.168.80.105) with Microsoft SMTP Server id 14.2.283.3; Wed, 16 May 2012 11:43:34 -0400 Date: Wed, 16 May 2012 11:40:24 -0400 Message-ID: <87mx5816dz.fsf@kelsey-ws.hq.ember.com> To: Thomas Heide Clausen In-Reply-To: <0AA713FC-2C91-41E4-80BF-3DA3FF450324@thomasclausen.org> (message from Thomas Heide Clausen on Wed, 16 May 2012 17:08:10 +0200) From: Richard Kelsey X-Auto-Response-Suppress: DR, OOF, AutoReply References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <22B18A3C-B327-4AD6-9D94-901CF225BE98@watteco.com> <0AA713FC-2C91-41E4-80BF-3DA3FF450324@thomasclausen.org> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [192.168.81.75] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [216.236.254.3] X-AnalysisOut: [v=2.0 cv=ap0F/1lV c=1 sm=0 a=MYqPJgym4Kx47q1P90kooQ==:17 a] X-AnalysisOut: [=u0NvnAFnSA0A:10 a=xFWF8fZ3eFEA:10 a=saA6nF2ZJaAA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=pJo66KLIAAAA:8 a=-bK6sgto06CcRlQ5rIgA:9 a=Q] X-AnalysisOut: [mq8LIWCQqsA:10] Cc: roll@ietf.org, mcr@sandelman.ca Subject: [Roll] RPL convergence behavior (was: Way forward for draft-clausen-lln-rpl-experiences) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 15:43:40 -0000 > From: Thomas Heide Clausen > Date: Wed, 16 May 2012 17:08:10 +0200 > > Again, the observations that we present in this I-D make > exclusive reference to RPL, and not to a specific > implementation or deployment. While this is largely true, some of the observations are based on experiments, and in those cases the details matter. >From the draft: 13.1. Observations The varying link quality in real-world environments results in frequent changes of the best parent, which triggers a reset of the Trickle timer and thus the emission of DIOs. Therefore Trickle does not converge as well for links that are fluctuating in quality as in theory. A link is neither good nor bad but thinking makes it so. What sort of links were you using? How did you measure link quality? Different techniques have given very different results. -Richard Kelsey From jpv@cisco.com Wed May 16 08:48:55 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A81821F8557 for ; Wed, 16 May 2012 08:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -111.599 X-Spam-Level: X-Spam-Status: No, score=-111.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IRu+ph66p92L for ; Wed, 16 May 2012 08:48:54 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 28C9821F8512 for ; Wed, 16 May 2012 08:48:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=24149; q=dns/txt; s=iport; t=1337183332; x=1338392932; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=q889zGamvX23unaqZ+44qrvcRmrP/EaI7v5vagWJl9A=; b=SlP7K9ohXP8EnpTkeJqQkzL30uUr7XqYwmR0i7v2kWVi/WjaYDckTdZh 8gj8acPRHm5Q1All2mGiuJSiOJaFMmM09tTDCRZ5Qc/eLs8AhbfwtcPRk LWmWByNPfHlr5kIm0RIYPGIK1kzNtGntk2+7A8Gab/DegGJo+PGuCRpAe s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArwGACvLs09Io8UY/2dsb2JhbABEgkVYnnmIKwGKUIIVAQEBAwESAVsLBQsLGCAOVwYnBweHZwULmxugD4sTGYRaYgOVeoERhGSIYoFpgmuBXQ X-IronPort-AV: E=Sophos;i="4.75,603,1330905600"; d="scan'208,217";a="12281308" Received: from vla196-nat.cisco.com (HELO bgl-core-4.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 16 May 2012 15:48:50 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by bgl-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q4GFmnHi029871; Wed, 16 May 2012 15:48:50 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); Wed, 16 May 2012 23:48:49 +0800 Received: from [10.60.114.227] ([10.60.114.227]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 23:48:46 +0800 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_4D3E6E06-A5C3-4FBF-B6C8-466804E886F6" From: JP Vasseur In-Reply-To: <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> Date: Wed, 16 May 2012 17:48:45 +0200 Message-Id: <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 16 May 2012 15:48:46.0993 (UTC) FILETIME=[614B4810:01CD337B] Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 15:48:55 -0000 --Apple-Mail=_4D3E6E06-A5C3-4FBF-B6C8-466804E886F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Thomas, So =85 let me restate a few things: 1) All implementations, reports about implementations and even more = deployment reports are within the scope of our WG. To make it clear, we = were not objecting to anything, just asking for more information about = the ID before polling the WG, that's all. 2) The point of the report is to give enough information for reproduce = the results and prove or disprove . So this document requires more = precision and a better description of which implementation were used, = what tests have been run, =85 (as also pointed out by Cedric on the = mailing list) =3D> this seems what the WG is asking for. 2) We saw very little discussion on the mailing list before and after = your presentation in Paris; it seems that we got emails from non authors = also asking for more details before considering for WG adoption though =85= Again, the work is useful and we try to make it as useful as possible = for the community. Thanks again. JP and Michael. On May 16, 2012, at 3:56 PM, Thomas Heide Clausen wrote: > Dear JP, >=20 > On May 16, 2012, at 15:54 , JP Vasseur wrote: >=20 >> Hi, >>=20 >> On May 16, 2012, at 3:17 PM, Thomas Heide Clausen wrote: >>=20 >>>=20 >>> On May 16, 2012, at 15:04 , JP Vasseur wrote: >>>=20 >>>> Dear Thomas, >>>>=20 >>>> On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: >>>>=20 >>>>> Dear JP and Michael, >>>>>=20 >>>>> Thank you for your mail. >>>>>=20 >>>>> On May 16, 2012, at 09:18 , JP Vasseur wrote: >>>>>=20 >>>>>> Dear Thomas, >>>>>>=20 >>>>>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>>>>>=20 >>>>>>> Dear JP, Michael, all >>>>>>>=20 >>>>>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was = presented and discussed at the Paris meeting. >>>>>>>=20 >>>>>>> The authors consider the document complete and "done", and are = looking to take it forward in the IETF=20 >>>>>>> process for publication as "Informational RFC" in the very near = future.=20 >>>>>>>=20 >>>>>>> We would therefore like to ask the WG chairs, if the ROLL WG is = willing to accept and progress this=20 >>>>>>> document towards publication? >>>>>>=20 >>>>>> Thanks for your suggestion. So far we haven't see a lot of = discussion/interest from the WG but your request is >>>>>> perfectly fair. >>>>>=20 >>>>> Thank you - I aim to be fair. >>>>>=20 >>>>>> So far there are no details on the scenarios and testing = environments that led to the issues that=20 >>>>>> you reported, thus I would suggest you to first include them so = that people interested could be able to reproduce >>>>>> it. Once the drat is updated, we'll be happy to pool the WG. >>>>>>=20 >>>>>> Does that make sense ? >>>>>=20 >>>>> Not really. Let me explain my disagreement. >>>>>=20 >>>>> We tried RPL (and, I note, several different independent = implementations of RPL) in a number of different scenarios and = deployments, and observed the behaviors exhibited - noting that what we = observed across the different implementations, scenarios and deployments = was fairly universal. >>>>>=20 >>>>> We then went back to the specification, to understand these = behaviors in detail, and understand their universality as independent = from a specific scenario or deployment or implementation - but rather, = as artifacts of the RPL protocol design. >>>>>=20 >>>>> We therefore believe that _any_ deployment, scenario or testing = environment of RPL needs to pay attention to the issues presented, and = find a way of addressing them. The way of addressing these issues in a = given deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario. >>>>=20 >>>> JP> Thanks for the clarification; that being said, for the WG to = make sure that nothing is "scenario" dependent and the outcome could = indeed apply to all scenarios, >>>> it might be worth being more explicit. For example, you pointed out = to the MTU issue, to which I mentioned that 15.4g would bring a = solution, so you may want to=20 >>>> explain that you did not use 15.4g=20 >>>=20 >>> This particular issue is fairly well pointed out in section 6, which = references RFC4919 (cf section 2 hereof) - the particular "small MTU" is = not dependent on the specific 127 octets of a specific L2, but a set of = observations that RPL - when faced with a small MTU - may often not be = able to carry a complete control message in a single fragment. Section = 6, 3rd paragraph is fairly explicit as to this. >>>=20 >>> More globally, the draft cites = http://datatracker.ietf.org/wg/roll/charter/ - which (other than making = specific reference to 802.15.4 (and not 15.4g) states that: >>>=20 >>> "In most cases, LLNs will be employed over link layers with=20 >>> restricted frame-sizes, thus a routing protocol for LLNs should = be >>> specifically adapted for such link layers >>>=20 >>> We observe some limits on RPL within the framework that the ROLL = charter has set forth. >>>=20 >>> I'm not sure I see what more can be done to address this point. >>>=20 >>>> and there are a number of such examples =85. >>>=20 >>>=20 >>> Personally, I do not believe that there are, but we (I think I can = speak for all the authors here) would very much appreciate your being = explicit on these examples - least it's hard to discuss them.=20 >>=20 >> Well put it differently, it would be beneficial to provide more = details on your testing scenarios for the WG to make sure that nothing=20= >> is "scenario-dependent" and to make sure that the outcome could = indeed apply to all scenarios, it might be worth being more explicit. >>=20 >=20 >> Could you do that before polling the WG ? >>=20 >=20 > Again, I think that reading the I-D, and the RPL RFC, should provide = sufficient information where necessary.=20 >=20 > All of the issues we have brought forward can be understood by looking = at the RPL RFC. >=20 > The "testing scenarios" simply pointed us to what we should look at in = the RPL RFC >=20 > Best, >=20 > Thomas >=20 >> Thanks. >>=20 >> JP. >>=20 >>>=20 >>> Thomas >>>=20 >>>>>=20 >>>>> (For example, a deployment using only L2s which provides = guaranteed bi-directional links for L3 would address this by in the = applicability statement stating "As all L2-links are guaranteed = bi-directional, this addresses the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".) >>>>>=20 >>>>> Thus, we believe that it would actually be misleading (not to = mention, unnecessarily verbose) to put the "details on the scenarios and = testing environments" into this I-D. >>>>>=20 >>>>> Doing so would mislead the reader to believe that the issues = presented only manifest themselves in those precise scenarios - which = definitely isn't the case. >>>>=20 >>>> JP> see the previous comment and tell us what you think; we could = provide other examples. >>>>=20 >>>> Note that we do not oppose to asking to the WG; we just request you = first to add additional information to proceed forward. >>>>=20 >>>> thanks. >>>>=20 >>>> JP and Michael. >>>>=20 >>>> JP. >>>>=20 >>>>>=20 >>>>> Best, >>>>>=20 >>>>> Thomas >>>>>=20 >>>>>> Thanks. >>>>>>=20 >>>>>> JP and Michael. >>>>>>=20 >>>>>>>=20 >>>>>>> Best, >>>>>>>=20 >>>>>>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_4D3E6E06-A5C3-4FBF-B6C8-466804E886F6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi = Thomas,

So =85 let me restate a few = things:

1) All implementations, reports about = implementations and even more deployment reports are within the = scope of our WG. To make it clear, we were not objecting to anything, = just asking for more information about the ID before polling the WG, = that's all.

2) The point of the report is to = give enough information for reproduce the results and prove or disprove = . So this document requires more precision and a better description of = which implementation were used, what tests have been run, =85 (as also = pointed out by Cedric on the mailing list) =3D> this seems what the = WG is asking for.

2) We saw very little = discussion on the mailing list before and after your presentation in = Paris; it seems that we got emails from non authors also asking for more = details before considering for WG adoption though = =85

Again, the work is useful and we try to = make it as useful as possible for the = community.

Thanks = again.

JP and = Michael.

On May 16, 2012, at 3:56 PM, Thomas = Heide Clausen wrote:

Dear JP,

On = May 16, 2012, at 15:54 , JP Vasseur wrote:

Hi,

On May = 16, 2012, at 3:17 PM, Thomas Heide Clausen wrote:


On May 16, 2012, = at 15:04 , JP Vasseur wrote:

Dear = Thomas,

On May 16, 2012, at 2:08 PM, Thomas Heide Clausen = wrote:

Dear JP and = Michael,

Thank you for = your mail.

On May 16, = 2012, at 09:18 , JP Vasseur wrote:

Dear Thomas,

On May 11, 2012, at 8:25 AM, = Thomas Heide Clausen wrote:

Dear = JP, Michael, all

Upon = JPs invitation, draft-clausen-lln-rpl-experiences was presented and = discussed at the Paris = meeting.

The = authors consider the document complete and "done", and are looking to = take it forward in the IETF =
process = for publication as "Informational RFC" in the very near future. =

We = would therefore like to ask the WG chairs, if the ROLL WG is willing to = accept and progress this =
document= towards = publication?

Thanks for your suggestion. So = far we haven't see a lot of discussion/interest from the WG but your = request is
perfectly = fair.

Thank you - I = aim to be fair.

So far there are no details on the scenarios and testing = environments that led to the issues that =
you reported, thus I would suggest you to first include = them so that people interested could be able to = reproduce
it. Once the drat is updated, = we'll be happy to pool the WG.

Does that make sense = ?

Not really. Let = me explain my disagreement.

We tried RPL = (and, I note, several different independent implementations of RPL) in a = number of different scenarios and deployments, and observed the = behaviors exhibited - noting that what we observed across the different = implementations, scenarios and deployments was fairly = universal.

We then went = back to the specification, to understand these behaviors in detail, and = understand their universality as independent from a specific scenario or = deployment or implementation - but rather, as artifacts of the RPL = protocol design.

We therefore = believe that _any_ deployment, scenario or testing environment of RPL = needs to pay attention to the issues presented, and find a way of = addressing them. The way of addressing these issues in a given = deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario.

JP> = Thanks for the clarification; that being said, for the WG to make sure = that nothing is "scenario" dependent and the outcome could indeed apply = to all scenarios,
it might be worth being more explicit. For example, = you pointed out to the MTU issue, to which I mentioned that 15.4g would = bring a solution, so you may want to
explain that you did not use = 15.4g 

This particular = issue is fairly well pointed out in section 6, which references RFC4919 = (cf section 2 hereof) - the particular "small MTU" is not dependent on = the specific 127 octets of a specific L2, but a set of observations that = RPL - when faced with a small MTU - may often not be able to carry a = complete control message in a single fragment. Section 6, 3rd = paragraph is fairly explicit as to this.

More = globally, the draft cites http://datatracker.i= etf.org/wg/roll/charter/ - which (other than making specific = reference to 802.15.4 (and not 15.4g) states that:

"In most cases, LLNs will be = employed over link layers with 
=  restricted frame-sizes, thus a routing protocol for LLNs = should be
=  specifically adapted for such link = layers

We observe some limits on RPL within the framework that the ROLL = charter has set forth.

I'm not sure I see what more can be done to address this = point.

and = there are a number of such examples = =85.

Personally, I do not = believe that there are, but  we (I think I can speak for all = the authors here) would very much appreciate your being explicit on = these examples - least it's hard to discuss = them. 

Well put it = differently, it would be beneficial to provide more details on your = testing scenarios for the WG to make sure that = nothing 
is "scenario-dependent" and to make sure that = the outcome could indeed apply to all scenarios, it might be worth = being more = explicit.


Best,

Thomas

Thanks.

JP.


(For example, a deployment using only L2s which provides = guaranteed bi-directional links  for L3 would address this by in = the applicability statement stating "As all L2-links are guaranteed = bi-directional, this addresses the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".)

Thus, we = believe that it would actually be misleading (not to mention, = unnecessarily verbose) to put the "details on the scenarios and testing = environments" into this I-D.

Doing so would = mislead the reader to believe that the issues presented only manifest = themselves in those precise scenarios - which definitely isn't the = case.

JP> see the previous comment and tell us = what you think; we could provide other = examples.

Note = that we do not oppose to asking to the WG; we just request you first to = add additional information to proceed forward.

thanks.

JP = and Michael.

JP.


Best,

Thomas

Thanks.

JP and = Michael.


Best,

Thomas, = Ulrich, Yuichi, Jiazi and = Axel







= --Apple-Mail=_4D3E6E06-A5C3-4FBF-B6C8-466804E886F6-- From c.chauvenet@watteco.com Wed May 16 09:48:17 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E6C21F85AD for ; Wed, 16 May 2012 09:48:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.943 X-Spam-Level: X-Spam-Status: No, score=-5.943 tagged_above=-999 required=5 tests=[AWL=1.656, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtEOiR6mD2oj for ; Wed, 16 May 2012 09:48:16 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe001.messaging.microsoft.com [213.199.154.139]) by ietfa.amsl.com (Postfix) with ESMTP id 6A4D621F85AC for ; Wed, 16 May 2012 09:48:15 -0700 (PDT) Received: from mail103-db3-R.bigfish.com (10.3.81.236) by DB3EHSOBE001.bigfish.com (10.3.84.21) with Microsoft SMTP Server id 14.1.225.23; Wed, 16 May 2012 16:48:07 +0000 Received: from mail103-db3 (localhost [127.0.0.1]) by mail103-db3-R.bigfish.com (Postfix) with ESMTP id 45AA03C0305; Wed, 16 May 2012 16:48:07 +0000 (UTC) X-SpamScore: -32 X-BigFish: VPS-32(zz9371Ic89bh1dbaI1432N98dK1447Izz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h946hd25he5bh) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI Received: from mail103-db3 (localhost.localdomain [127.0.0.1]) by mail103-db3 (MessageSwitch) id 1337186884881149_15343; Wed, 16 May 2012 16:48:04 +0000 (UTC) Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.251]) by mail103-db3.bigfish.com (Postfix) with ESMTP id C50422C0075; Wed, 16 May 2012 16:48:04 +0000 (UTC) Received: from DBXPRD0510HT001.eurprd05.prod.outlook.com (157.56.252.165) by DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 16 May 2012 16:48:02 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.244]) by DBXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.67.164]) with mapi id 14.16.0152.000; Wed, 16 May 2012 16:48:08 +0000 From: C Chauvenet To: Thomas Heide Clausen Thread-Topic: [Roll] Way forward for draft-clausen-lln-rpl-experiences Thread-Index: AQHNLz7f4nHZNQpKzkGVpF0j12dI45bMCZgAgABRMICAAA+CgIAAE3eAgAAPKgCAABvrgA== Date: Wed, 16 May 2012 16:48:07 +0000 Message-ID: <4818180C-19D8-4C01-A65C-04DD47B9FCB2@watteco.com> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <22B18A3C-B327-4AD6-9D94-901CF225BE98@watteco.com> <0AA713FC-2C91-41E4-80BF-3DA3FF450324@thomasclausen.org> In-Reply-To: <0AA713FC-2C91-41E4-80BF-3DA3FF450324@thomasclausen.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.48.32] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 16:48:17 -0000 Thomas, See inline, =20 Le 16 mai 2012 =E0 17:08, Thomas Heide Clausen a =E9crit : > Dear Cedric, >=20 > Thank you for your email. Comments below. >=20 > On 16 May 2012, at 16:13, C Chauvenet wrote: >=20 >> Hi,=20 >>=20 >> I definitely agree that implementation feedback is always good to know, = so your experiences are welcomed. >>=20 >> I also think that problems investigations need a complete and exact view= , so I would encourage you to put much more details about the scenario and = the environment where you experimentations took place. >> For instance, I would enjoy a "RPL Implementation Description" section i= n you draft listing the hardware your used, your RPL parameters, the RPL dr= afts and mechanisms implemented, your OS etc... >=20 > As I indicated to JP already: >=20 > 1) this draft is not "just" based on a single scenario, environment or i= mplementation=20 > (and, therefore, not "just" based on a single test).=20 Does it means that your run multiple scenarios ?=20 That would be great. >=20 > 2) the observations that we made during the test_S_ served to make us lo= ok at the RPL > RFC again, to explain our observations and to generalize them from the w= ritten word > of that RFC. >=20 > Therefore, I do not think that any such description would bring anything = (other than entropy and delay) to the process. The RPL RFC and this I-D is = more than sufficient. >=20 > As to what features were implemented, that is easy to answer: the RPL RFC= (except for security) to the letter and with the parameters suggested ther= e, and OF0. However, even the parameters are immaterial for the observation= s listed in this I-D. I think we are progressing on the definition of your RPL implementation : c= ould you also precise what part of the RPL spec you have implemented ? eg. = What mode of Operation and why, what options did you choose to include in D= IO messages, your metrics .... >=20 >> If I read a paper with orthogonal observations with the same level of de= tails as in your draft, then how could I forge my opinion ? >=20 > I'd suggest reading the indicated parts of the RPL RFC conjointly with th= is I-D. Again, the observations that we present in this I-D make exclusive = reference to RPL, and not to a specific implementation or deployment. >=20 >> Looking at this draft, it seems that it gathers lots of previous discuss= ions that occurred during the past year on various mailing lists, and IETF = meetings. >>=20 >> Does your experimentations takes care about these recommendations ? >=20 > Again, the issues raised in this I-D are based on what can be observed fr= om the RPL RFC.=20 >=20 > If there are additional considerations required (which you seem to indica= te to be the case) which are not reflected in the RPL RFC, in order to over= come the issues raised, then that indeed should be a big problem for the IE= TF and for ROLL.... These recommendations were for the problems you pointed out in *Your* imple= mentation. Of course if other implementers are facing to the same problems, they could= rely on it, but I have not heard about similar problems outside your lab f= rom now. >=20 >> If not, does your draft mention the propositions that have been made to = address the problems you point out in your draft ? >> I think it could be worth to leverage on these previous discussions. >=20 > I firmly disagree. The IETF and ROLL has published an RFC - that's what t= his I-D discusses.=20 >=20 > Discussing what may have been proposed in other media would be entirely o= ut of scope. Again, this is not related to the RPL RFC but *your* implementation that re= ceived some guidance regarding its problems. The RPL RFC should not include tips for your implementation, but your imple= mentation and your draft should pay attention to the tips given to you. >=20 >> Your draft is a list of Description and Observations. >> Maybe you could add a "Resolution Proposal" section for each problem, ga= thering previous discussion and your own proposals ? >=20 > Nope. That's not the objective of this I-D. That's too bad, this is what all readers of this draft are looking for ! Without offense, saying "this is bad" without a better proposition seems li= ke half-work !=20 And this is true for most of the discussion topics in life, far away from R= PL ! > I would venture that if the WG is serious about applicability statements,= then those applicability statements would be the place for discussion of "= how this issue, raised in this I-D, is addressed or moot for a given deploy= ment". >=20 >> Identifying what is wrong in your implementation >=20 > Considering that these observations are not implementation-specific, but = are directly on the RPL RFC, I venture the observations that there's nothin= g "wrong in my implementation" here. >=20 As a general comment : RPL is a routing protocol targeted for a very wide a= pplication area.=20 Some may think this is good because it covers a lot of needs. Some may think it is bad because it is wide and not specific enough for the= ir application. Wathever your position, these two arguments are valid, this is all a matter= of viewpoint and tradeoff. So, because RPL is wide enough for multiple application, you have to take s= ome time to tune it correctly, according to your application. One simple choice that every RPL implementers will ave to answer is : Use S= toring or Non Storing Mode ? This is a fondamental design choice that canno= t be made outside a scenario consideration. Be sure that there is no magic RPL tuning that works for all, but multiple = fine RPL tuning for multiple applications. I honestly cannot believe in generic results given the incredibly variety o= f tuning that RPL can have. So my final position is that we disagree on the need of more details in you= r experiments. C=E9dric. > Thomas >=20 >=20 >> is a good first step, but the hardest part is to propose some correction= s. >> Best Regards, >>=20 >> C=E9dric Chauvenet. >>=20 >> Le 16 mai 2012 =E0 15:04, JP Vasseur a =E9crit : >>=20 >>> Dear Thomas, >>>=20 >>> On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: >>>=20 >>>> Dear JP and Michael, >>>>=20 >>>> Thank you for your mail. >>>>=20 >>>> On May 16, 2012, at 09:18 , JP Vasseur wrote: >>>>=20 >>>>> Dear Thomas, >>>>>=20 >>>>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>>>>=20 >>>>>> Dear JP, Michael, all >>>>>>=20 >>>>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented= and discussed at the Paris meeting. >>>>>>=20 >>>>>> The authors consider the document complete and "done", and are looki= ng to take it forward in the IETF=20 >>>>>> process for publication as "Informational RFC" in the very near futu= re.=20 >>>>>>=20 >>>>>> We would therefore like to ask the WG chairs, if the ROLL WG is will= ing to accept and progress this=20 >>>>>> document towards publication? >>>>>=20 >>>>> Thanks for your suggestion. So far we haven't see a lot of discussion= /interest from the WG but your request is >>>>> perfectly fair. >>>>=20 >>>> Thank you - I aim to be fair. >>>>=20 >>>>> So far there are no details on the scenarios and testing environments= that led to the issues that=20 >>>>> you reported, thus I would suggest you to first include them so that = people interested could be able to reproduce >>>>> it. Once the drat is updated, we'll be happy to pool the WG. >>>>>=20 >>>>> Does that make sense ? >>>>=20 >>>> Not really. Let me explain my disagreement. >>>>=20 >>>> We tried RPL (and, I note, several different independent implementatio= ns of RPL) in a number of different scenarios and deployments, and observed= the behaviors exhibited - noting that what we observed across the differen= t implementations, scenarios and deployments was fairly universal. >>>>=20 >>>> We then went back to the specification, to understand these behaviors = in detail, and understand their universality as independent from a specific= scenario or deployment or implementation - but rather, as artifacts of the= RPL protocol design. >>>>=20 >>>> We therefore believe that _any_ deployment, scenario or testing enviro= nment of RPL needs to pay attention to the issues presented, and find a way= of addressing them. The way of addressing these issues in a given deployme= nt or scenario would be appropriate for an "applicability statement" for th= at deployment or scenario. >>>=20 >>> JP> Thanks for the clarification; that being said, for the WG to make s= ure that nothing is "scenario" dependent and the outcome could indeed apply= to all scenarios, >>> it might be worth being more explicit. For example, you pointed out to = the MTU issue, to which I mentioned that 15.4g would bring a solution, so y= ou may want to=20 >>> explain that you did not use 15.4g and there are a number of such examp= les =85. >>>=20 >>>>=20 >>>> (For example, a deployment using only L2s which provides guaranteed bi= -directional links for L3 would address this by in the applicability state= ment stating "As all L2-links are guaranteed bi-directional, this addresses= the issues raised in section 9 in draft-clausen-lln-rpl-experiences".) >>>>=20 >>>> Thus, we believe that it would actually be misleading (not to mention,= unnecessarily verbose) to put the "details on the scenarios and testing en= vironments" into this I-D. >>>>=20 >>>> Doing so would mislead the reader to believe that the issues presented= only manifest themselves in those precise scenarios - which definitely isn= 't the case. >>>=20 >>> JP> see the previous comment and tell us what you think; we could provi= de other examples. >>>=20 >>> Note that we do not oppose to asking to the WG; we just request you fir= st to add additional information to proceed forward. >>>=20 >>> thanks. >>>=20 >>> JP and Michael. >>>=20 >>> JP. >>>=20 >>>>=20 >>>> Best, >>>>=20 >>>> Thomas >>>>=20 >>>>> Thanks. >>>>>=20 >>>>> JP and Michael. >>>>>=20 >>>>>>=20 >>>>>> Best, >>>>>>=20 >>>>>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>>>>=20 >>>>=20 >>>=20 >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>>=20 >>=20 >>=20 >=20 From ulrich@herberg.name Wed May 16 09:58:42 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED66F21F850B for ; Wed, 16 May 2012 09:58:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.879 X-Spam-Level: X-Spam-Status: No, score=-3.879 tagged_above=-999 required=5 tests=[AWL=1.097, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qaKNC4VEfzkk for ; Wed, 16 May 2012 09:58:41 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 36F7B21F847F for ; Wed, 16 May 2012 09:58:41 -0700 (PDT) Received: by qadz3 with SMTP id z3so4994908qad.10 for ; Wed, 16 May 2012 09:58:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Y9Zehv8tuQMAQa90+09uH8RcqNqAgwxk47zOG62OIuk=; b=StcC63hSX6yTFo1G/h92OwzweG1z9bbst8hq2AXZOK56cdiYKoNk/QJgcUBL0OUoxm /bDOAdB3O9e4f1+8jVQiAboLeRp2BdCEps8PisDD019uDVVhIrFOPijjhUDZe6XQKzrm JoKG7OOX3PkAC8g4GKlar8t833hPLEmF5YexY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Y9Zehv8tuQMAQa90+09uH8RcqNqAgwxk47zOG62OIuk=; b=R1VuBN0ntG2GWrd3BDd1S42nEP5hlsCoZ4k6AfMTuapat1Omi3hqPaSxO2IE4E62XA 6y0ve1l5KOY9pqZtPvQScxQMRXH0Sphzzb6TPDLVArFi/I5Om4rPVvb62aYGKh9ZOG21 0ZCIPmu06hK4lTILyz++QcMvKvG7a/6eE+WM3xEPTiC4ReWgCdhgy8mY0COWT5AXHmYK 2tpUhVBFzrHRie0bHB1Lp7SblvxrP6Xu5k23xkBNFDObZrMvOExf9QwVWS2rcShRGVig fyxa3a/RNmdIzW+q+biLRkKVndSNhJWCxyloPfuFm9iKWBFFlYmLXVQ1OyGKP07aJw5Q vNgQ== MIME-Version: 1.0 Received: by 10.229.136.135 with SMTP id r7mr1848389qct.86.1337187520490; Wed, 16 May 2012 09:58:40 -0700 (PDT) Received: by 10.229.229.75 with HTTP; Wed, 16 May 2012 09:58:40 -0700 (PDT) In-Reply-To: <418765560.417509.1337180037325.JavaMail.root@mail17.pantherlink.uwm.edu> References: <22B18A3C-B327-4AD6-9D94-901CF225BE98@watteco.com> <418765560.417509.1337180037325.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Wed, 16 May 2012 09:58:40 -0700 Message-ID: From: Ulrich Herberg To: Mukul Goyal Content-Type: multipart/alternative; boundary=00248c769042282d4104c02a3bfb X-Gm-Message-State: ALoCoQnw9xf2O5GBrVTGqy+M5o9AO1yJWbvuzAuRnW6+PuxbDp1CQb3yZMkV2y82dLoPKkcpe0CO Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 16:58:43 -0000 --00248c769042282d4104c02a3bfb Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Mukul, On Wed, May 16, 2012 at 7:53 AM, Mukul Goyal wrote: > I agree with Cedric. Issues that Cedric has raised are very basic and > should have already been taken care of in the document. Seriously, do the > authors think that this document would pass the muster for publication in > any decent academic journal? I don't know since when that is any criteria for IETF work. Was it a criteria for the standardization of RPL itself? > Right now, the draft reads more like propaganda than information: written > to bad mouth a protocol on the basis of biased/frivolous arguments. I am sorry that you see the draft that way. We have tried to be as objective as possible. Can you point out any concrete paragraph or section that you see as "propaganda"? And honestly, I would have hoped that we can have an objective, argumentative discussion on the mailing list, and not a dismissal of our arguments without any constructive discussion. > Why would the authors completely ignore P2P-RPL even though it resolves > many issues they have pointed out. 1) Because P2P-RPL is not even an RFC yet, whereas RPL is, and is already deployed. 2) There is no dependency from RPL to P2P-RPPL, i.e., it should work stand-alone. 3) P2P-RPL is experimental, RPL is std. track. 4) I thought that ROLL is chartered to provide routing solutions for extremely constrained devices (which was, I assume, one of the reasons to not consider MANET work). One of our arguments in the draft is that RPL is very complex (the specification alone plus necessary companion documents has several hundred pages). Adding P2P-RPL as necessity to mitigate some of the issues would increase the code size even more. > There are numerous similar sins of omission spread throughout the > document. Where? > As a result, most conclusions the document reaches are open to doubt if > not outright incorrect. Is that proof by authority or a real argument? Please be more constructive. > Sure, RPL is not a perfect protocol - no protocol is. But this document i= s > not an unbiased scientific analysis of the protocol. How do you come to that conclusion? We provide concrete, objective arguments. I do not see that in your email. > As Pascal said, this document could have served a valuable constructive > purpose. But, perhaps this was not the intention of the authors. This > document should be recognized for what it is: a political document writte= n > to further a particular destructive agenda. > I really don't know what to say to that non-constructive argument. Best regards Ulrich > > Thanks > Mukul > > ----- Original Message ----- > From: "C Chauvenet" > To: "JP Vasseur" > Cc: "roll WG" , "Michael Richardson" > Sent: Wednesday, May 16, 2012 9:13:56 AM > Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences > > Hi, > > I definitely agree that implementation feedback is always good to know, s= o > your experiences are welcomed. > > I also think that problems investigations need a complete and exact view, > so I would encourage you to put much more details about the scenario and > the environment where you experimentations took place. > For instance, I would enjoy a "RPL Implementation Description" section in > you draft listing the hardware your used, your RPL parameters, the RPL > drafts and mechanisms implemented, your OS etc... > If I read a paper with orthogonal observations with the same level of > details as in your draft, then how could I forge my opinion ? > > Looking at this draft, it seems that it gathers lots of previous > discussions that occurred during the past year on various mailing lists, > and IETF meetings. > > Does your experimentations takes care about these recommendations ? > If not, does your draft mention the propositions that have been made to > address the problems you point out in your draft ? > I think it could be worth to leverage on these previous discussions. > > Your draft is a list of Description and Observations. > Maybe you could add a "Resolution Proposal" section for each problem, > gathering previous discussion and your own proposals ? > Identifying what is wrong in your implementation is a good first step, bu= t > the hardest part is to propose some corrections. > > Best Regards, > > C=E9dric Chauvenet. > > Le 16 mai 2012 =E0 15:04, JP Vasseur a =E9crit : > > > Dear Thomas, > > > > On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: > > > >> Dear JP and Michael, > >> > >> Thank you for your mail. > >> > >> On May 16, 2012, at 09:18 , JP Vasseur wrote: > >> > >>> Dear Thomas, > >>> > >>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: > >>> > >>>> Dear JP, Michael, all > >>>> > >>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented > and discussed at the Paris meeting. > >>>> > >>>> The authors consider the document complete and "done", and are > looking to take it forward in the IETF > >>>> process for publication as "Informational RFC" in the very near > future. > >>>> > >>>> We would therefore like to ask the WG chairs, if the ROLL WG is > willing to accept and progress this > >>>> document towards publication? > >>> > >>> Thanks for your suggestion. So far we haven't see a lot of > discussion/interest from the WG but your request is > >>> perfectly fair. > >> > >> Thank you - I aim to be fair. > >> > >>> So far there are no details on the scenarios and testing environments > that led to the issues that > >>> you reported, thus I would suggest you to first include them so that > people interested could be able to reproduce > >>> it. Once the drat is updated, we'll be happy to pool the WG. > >>> > >>> Does that make sense ? > >> > >> Not really. Let me explain my disagreement. > >> > >> We tried RPL (and, I note, several different independent > implementations of RPL) in a number of different scenarios and deployment= s, > and observed the behaviors exhibited - noting that what we observed acros= s > the different implementations, scenarios and deployments was fairly > universal. > >> > >> We then went back to the specification, to understand these behaviors > in detail, and understand their universality as independent from a specif= ic > scenario or deployment or implementation - but rather, as artifacts of th= e > RPL protocol design. > >> > >> We therefore believe that _any_ deployment, scenario or testing > environment of RPL needs to pay attention to the issues presented, and fi= nd > a way of addressing them. The way of addressing these issues in a given > deployment or scenario would be appropriate for an "applicability > statement" for that deployment or scenario. > > > > JP> Thanks for the clarification; that being said, for the WG to make > sure that nothing is "scenario" dependent and the outcome could indeed > apply to all scenarios, > > it might be worth being more explicit. For example, you pointed out to > the MTU issue, to which I mentioned that 15.4g would bring a solution, so > you may want to > > explain that you did not use 15.4g and there are a number of such > examples =85. > > > >> > >> (For example, a deployment using only L2s which provides guaranteed > bi-directional links for L3 would address this by in the applicability > statement stating "As all L2-links are guaranteed bi-directional, this > addresses the issues raised in section 9 in > draft-clausen-lln-rpl-experiences".) > >> > >> Thus, we believe that it would actually be misleading (not to mention, > unnecessarily verbose) to put the "details on the scenarios and testing > environments" into this I-D. > >> > >> Doing so would mislead the reader to believe that the issues presented > only manifest themselves in those precise scenarios - which definitely > isn't the case. > > > > JP> see the previous comment and tell us what you think; we could > provide other examples. > > > > Note that we do not oppose to asking to the WG; we just request you > first to add additional information to proceed forward. > > > > thanks. > > > > JP and Michael. > > > > JP. > > > >> > >> Best, > >> > >> Thomas > >> > >>> Thanks. > >>> > >>> JP and Michael. > >>> > >>>> > >>>> Best, > >>>> > >>>> Thomas, Ulrich, Yuichi, Jiazi and Axel > >>> > >> > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --00248c769042282d4104c02a3bfb Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Mukul,

On Wed, May 16, 2012 at 7:53 AM, M= ukul Goyal <mukul@uwm.edu> wrote:
I agree with Cedric. Issues that Cedric has raised are very basic and shoul= d have already been taken care of in the document. Seriously, do the author= s think that this document would pass the muster for publication in any dec= ent academic journal?


I don't know since when that is any criteria for IETF work= . Was it a criteria for the standardization of RPL itself?

=A0
=
Right now, the draft reads more like propaganda than information: written t= o bad mouth a protocol on the basis of biased/frivolous arguments.

I am sorry that you see the draft that way. We have tried to b= e as objective as possible. Can you point out any concrete paragraph or sec= tion that you see as "propaganda"? And honestly, I would have hop= ed that we can have an objective, argumentative discussion on the mailing l= ist, and not a dismissal of our arguments without any constructive discussi= on.

=A0
Why would t= he authors completely ignore P2P-RPL even though it resolves many issues th= ey have pointed out.

1) Because P2P-RPL is not even an RFC yet, whereas RPL is, and is = already deployed.
2) There is no dependency from RPL to P2P-RPPL, i.e., = it should work stand-alone.
3) P2P-RPL is experimental, RPL is std. trac= k.
4) I thought that ROLL is chartered to provide routing solutions for extrem= ely constrained devices (which was, I assume, one of the reasons to not con= sider MANET work). One of our arguments in the draft is that RPL is very co= mplex (the specification alone plus necessary companion documents has sever= al hundred pages). Adding P2P-RPL as necessity to mitigate some of the issu= es would increase the code size even more.

=A0
There are nu= merous similar sins of omission spread throughout the document.

Where?
=A0
As a result, most conclusions the document reaches are open to doubt if = not outright incorrect.

Is that proof by authority or a real argument? Please be more cons= tructive.

=A0
Sure, RPL is not a perfect protocol - no protocol is. But this document is= not an unbiased scientific analysis of the protocol.

How do you come to that conclusion? We provide concrete, objective= arguments. I do not see that in your email.

=A0
As Pascal said, this document could have served a valuable constructive pu= rpose. But, perhaps this was not the intention of the authors. This documen= t should be recognized for what it is: a political document written to furt= her a particular destructive agenda.

I really don't know what to say to that non-const= ructive argument.

Best regards
Ulrich

=A0

Thanks
Mukul

----- Original Message -----
From: "C Chauvenet" <c.chauvenet@watteco.com>
To: "JP Vasseur" <jpv@cisco.c= om>
Cc: "roll WG" <roll@ietf.org<= /a>>, "Michael Richardson" <mcr@sandelman.ca>
Sent: Wednesday, May 16, 2012 9:13:56 AM
Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences

Hi,

I definitely agree that implementation feedback is always good to know, so = your experiences are welcomed.

I also think that problems investigations need a complete and exact view, s= o I would encourage you to put much more details about the scenario and the= environment where you experimentations took place.
For instance, I would enjoy a "RPL Implementation Description" se= ction in you draft listing the hardware your used, your RPL parameters, the= RPL drafts and mechanisms implemented, your OS etc...
If I read a paper with orthogonal observations with the same level of detai= ls as in your draft, then how could I forge my opinion ?

Looking at this draft, it seems that it gathers lots of previous discussion= s that occurred during the past year on various mailing lists, and IETF mee= tings.

Does your experimentations takes care about these recommendations ?
If not, does your draft mention the propositions that have been made to add= ress the problems you point out in your draft ?
I think it could be worth to leverage on these previous discussions.

Your draft is a list of Description and Observations.
Maybe you could add a "Resolution Proposal" section for each prob= lem, gathering previous discussion and your own proposals ?
Identifying what is wrong in your implementation is a good first step, but = the hardest part is to propose some corrections.

Best Regards,

C=E9dric Chauvenet.

Le 16 mai 2012 =E0 15:04, JP Vasseur a =E9crit :

> Dear Thomas,
>
> On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote:
>
>> Dear JP and Michael,
>>
>> Thank you for your mail.
>>
>> On May 16, 2012, at 09:18 , JP Vasseur wrote:
>>
>>> Dear Thomas,
>>>
>>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote:
>>>
>>>> Dear JP, Michael, all
>>>>
>>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was= presented and discussed at the Paris meeting.
>>>>
>>>> The authors consider the document complete and "done&= quot;, and are looking to take it forward in the IETF
>>>> process for publication as "Informational RFC" i= n the very near future.
>>>>
>>>> We would therefore like to ask the WG chairs, if the ROLL = WG is willing to accept and progress this
>>>> document towards publication?
>>>
>>> Thanks for your suggestion. So far we haven't see a lot of= discussion/interest from the WG but your request is
>>> perfectly fair.
>>
>> Thank you - I aim to be fair.
>>
>>> So far there are no details on the scenarios and testing envir= onments that led to the issues that
>>> you reported, thus I would suggest you to first include them s= o that people interested could be able to reproduce
>>> it. Once the drat is updated, we'll be happy to pool the W= G.
>>>
>>> Does that make sense ?
>>
>> Not really. Let me explain my disagreement.
>>
>> We tried RPL (and, I note, several different independent implement= ations of RPL) in a number of different scenarios and deployments, and obse= rved the behaviors exhibited - noting that what we observed across the diff= erent implementations, scenarios and deployments was fairly universal.
>>
>> We then went back to the specification, to understand these behavi= ors in detail, and understand their universality as independent from a spec= ific scenario or deployment or implementation - but rather, as artifacts of= the RPL protocol design.
>>
>> We therefore believe that _any_ deployment, scenario or testing en= vironment of RPL needs to pay attention to the issues presented, and find a= way of addressing them. The way of addressing these issues in a given depl= oyment or scenario would be appropriate for an "applicability statemen= t" for that deployment or scenario.
>
> JP> Thanks for the clarification; that being said, for the WG to ma= ke sure that nothing is "scenario" dependent and the outcome coul= d indeed apply to all scenarios,
> it might be worth being more explicit. For example, you pointed out to= the MTU issue, to which I mentioned that 15.4g would bring a solution, so = you may want to
> explain that you did not use 15.4g and there are a number of such exam= ples =85.
>
>>
>> (For example, a deployment using only L2s which provides guarantee= d bi-directional links =A0for L3 would address this by in the applicability= statement stating "As all L2-links are guaranteed bi-directional, thi= s addresses the issues raised in section 9 in draft-clausen-lln-rpl-experie= nces".)
>>
>> Thus, we believe that it would actually be misleading (not to ment= ion, unnecessarily verbose) to put the "details on the scenarios and t= esting environments" into this I-D.
>>
>> Doing so would mislead the reader to believe that the issues prese= nted only manifest themselves in those precise scenarios - which definitely= isn't the case.
>
> JP> see the previous comment and tell us what you think; we could p= rovide other examples.
>
> Note that we do not oppose to asking to the WG; we just request you fi= rst to add additional information to proceed forward.
>
> thanks.
>
> JP and Michael.
>
> JP.
>
>>
>> Best,
>>
>> Thomas
>>
>>> Thanks.
>>>
>>> JP and Michael.
>>>
>>>>
>>>> Best,
>>>>
>>>> Thomas, Ulrich, Yuichi, Jiazi and Axel
>>>
>>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>


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

--00248c769042282d4104c02a3bfb-- From pal@cs.stanford.edu Wed May 16 10:02:59 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82DC421F866C for ; Wed, 16 May 2012 10:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.328 X-Spam-Level: X-Spam-Status: No, score=-6.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6qu5YHprpB1 for ; Wed, 16 May 2012 10:02:54 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id 78F3221F8589 for ; Wed, 16 May 2012 10:02:54 -0700 (PDT) Received: from dn0a210362.sunet ([10.33.3.98]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SUhcj-0005ee-Qq; Wed, 16 May 2012 10:02:53 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: Date: Wed, 16 May 2012 10:02:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> To: JP Vasseur X-Mailer: Apple Mail (2.1257) X-Scan-Signature: acf3039aa8d32d1ac60a71149e52b94c Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 17:02:59 -0000 On May 16, 2012, at 6:54 AM, JP Vasseur wrote: >=20 > Well put it differently, it would be beneficial to provide more = details on your testing scenarios for the WG to make sure that nothing=20= > is "scenario-dependent" and to make sure that the outcome could indeed = apply to all scenarios, it might be worth being more explicit. >=20 > Could you do that before polling the WG ? I think an example of what JP's talking about might be something such as = the question I raised in Paris: what constitutes a "down link" in the = testing? Thomas' response was "no ack after L2 retransmissions"; this is = an assumption about behavior. How many retransmissions? What was the = time spacing? It's not hard to configure 802.11, for example, such that = L2 back off has only a tiny chance of successful delivery in the case of = a hidden terminal. Most wireless protocol implementations today = understand these issues and rely on much longer time frames to consider = a link "down." Phil From ulrich@herberg.name Wed May 16 10:09:22 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CBD921F86F2 for ; Wed, 16 May 2012 10:09:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.923 X-Spam-Level: X-Spam-Status: No, score=-3.923 tagged_above=-999 required=5 tests=[AWL=1.053, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y4tOL8URkrkC for ; Wed, 16 May 2012 10:09:19 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id E518D21F8663 for ; Wed, 16 May 2012 10:09:18 -0700 (PDT) Received: by qcsq13 with SMTP id q13so788432qcs.31 for ; Wed, 16 May 2012 10:09:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=YTBtBCM5VPz/BGkQctUlvS7Bf2IrbjRNp24Vq6u5YdM=; b=tvc9aR/uK1Dbs7FGW8I3Sf7xRBAjNPUMvwp7UyEu+fKZSZs3Acm1UhPZ/5kGJ5XUhZ RugGJBco0PDSUZdq41s6N6zAPkP4EJ6xFFjJY46IGWUdWvh+cHwgZjkV4E/bAOMtFNXd rGsGQK0KyHuQnXwf3IJxzlH9S7nN9dzxu/HLQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=YTBtBCM5VPz/BGkQctUlvS7Bf2IrbjRNp24Vq6u5YdM=; b=DhfmpmKv8KgT2o4kc0SBQ9zd/1p972guKDaEV8E9UkWvBLmlMgns4vGrKRDJZyNWGW 5Q6untHXQ2p7JUxjz5yC0w2V281e3UW9laK0nB2bDoF43zMhDIH5RN4xA1+qHlLlKOye qfcrFUibx0erPPE4qgUYuOMNmA7Wmt2QysrVCu03jTnd+KF2CkbjSyXavEn4jiVpLscw XbPGmUGHerCDSA4dDSELLPeSKlzBm2PE9QqBtruA0rt4QdZshVWnqYzrqk6lDf1vzSsW j0Nuc3VoagE+GEzYLSwjN07/uU0p6EOdvFqKViGZr0kcL1g9rg6G1uXPQplN0wcZnlk8 8RGg== MIME-Version: 1.0 Received: by 10.229.136.135 with SMTP id r7mr1867832qct.86.1337188158071; Wed, 16 May 2012 10:09:18 -0700 (PDT) Received: by 10.229.229.75 with HTTP; Wed, 16 May 2012 10:09:17 -0700 (PDT) In-Reply-To: <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> Date: Wed, 16 May 2012 10:09:17 -0700 Message-ID: From: Ulrich Herberg To: JP Vasseur Content-Type: multipart/alternative; boundary=00248c76904228e2e004c02a6190 X-Gm-Message-State: ALoCoQn77kv9SswkL2OXh/9FjciecJVN2RFm8ZmA5/vTpyFJCQbO9fm2S1CiLOx41hEGFGbmc9g3 Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 17:09:22 -0000 --00248c76904228e2e004c02a6190 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable JP, On Wed, May 16, 2012 at 8:48 AM, JP Vasseur wrote: > Hi Thomas, > > So =85 let me restate a few things: > > 1) All implementations, reports about implementations and even more *depl= oyment > reports* are within the scope of our WG. To make it clear, we were not > objecting to anything, just asking for more information about the ID befo= re > polling the WG, that's all. > We did not intend that draft as "implementation" or "deployment report" about one specific implementation. Many of the observations in the draft are directly concluded from the RPL RFC, and not from an implementation. So I second Thomas that providing more information about a single implementation would not really help. > > 2) The point of the report is to give enough information for reproduce th= e > results and prove or disprove . So this document requires more precision > and a better description of which implementation were used, what tests ha= ve > been run, =85 (as also pointed out by Cedric on the mailing list) =3D> th= is > seems what the WG is asking for. > Again, for a large part of the document, the observations are made from the RPL spec. itself. Take for example the fragmentation issue; this would be observed by any implementation, running on a constrained link layer, such as in scope for ROLL. > > 2) We saw very little discussion on the mailing list before and after you= r > presentation in Paris; it seems that we got emails from non authors also > asking for more details before considering for WG adoption though =85 > Same argument as above. Our draft is not intended as implementation report of a single implementation, but general observations of the RPL RFC. I would hope that there is some discussion about the individual issues that are described in the draft. > > Again, the work is useful and we try to make it as useful as possible for > the community. > Thank you, JP, we appreciate that. Best regards Ulrich > > Thanks again. > > JP and Michael. > > On May 16, 2012, at 3:56 PM, Thomas Heide Clausen wrote: > > Dear JP, > > On May 16, 2012, at 15:54 , JP Vasseur wrote: > > Hi, > > On May 16, 2012, at 3:17 PM, Thomas Heide Clausen wrote: > > > On May 16, 2012, at 15:04 , JP Vasseur wrote: > > Dear Thomas, > > On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: > > Dear JP and Michael, > > > Thank you for your mail. > > > On May 16, 2012, at 09:18 , JP Vasseur wrote: > > > Dear Thomas, > > > On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: > > > Dear JP, Michael, all > > > Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented and > discussed at the Paris meeting. > > > The authors consider the document complete and "done", and are looking to > take it forward in the IETF > > process for publication as "Informational RFC" in the very near future. > > > We would therefore like to ask the WG chairs, if the ROLL WG is willing t= o > accept and progress this > > document towards publication? > > > Thanks for your suggestion. So far we haven't see a lot of > discussion/interest from the WG but your request is > > perfectly fair. > > > Thank you - I aim to be fair. > > > So far there are no details on the scenarios and testing environments tha= t > led to the issues that > > you reported, thus I would suggest you to first include them so that > people interested could be able to reproduce > > it. Once the drat is updated, we'll be happy to pool the WG. > > > Does that make sense ? > > > Not really. Let me explain my disagreement. > > > We tried RPL (and, I note, several different independent implementations > of RPL) in a number of different scenarios and deployments, and observed > the behaviors exhibited - noting that what we observed across the differe= nt > implementations, scenarios and deployments was fairly universal. > > > We then went back to the specification, to understand these behaviors in > detail, and understand their universality as independent from a specific > scenario or deployment or implementation - but rather, as artifacts of th= e > RPL protocol design. > > > We therefore believe that _any_ deployment, scenario or testing > environment of RPL needs to pay attention to the issues presented, and fi= nd > a way of addressing them. The way of addressing these issues in a given > deployment or scenario would be appropriate for an "applicability > statement" for that deployment or scenario. > > > JP> Thanks for the clarification; that being said, for the WG to make sur= e > that nothing is "scenario" dependent and the outcome could indeed apply t= o > all scenarios, > it might be worth being more explicit. For example, you pointed out to th= e > MTU issue, to which I mentioned that 15.4g would bring a solution, so you > may want to > explain that you did not use 15.4g > > > This particular issue is fairly well pointed out in section 6, which > references RFC4919 (cf section 2 hereof) - the particular "small MTU" is > not dependent on the specific 127 octets of a specific L2, but a set of > observations that RPL - when faced with a small MTU - may often not be ab= le > to carry a complete control message in a single fragment. Section 6, 3rd > paragraph is fairly explicit as to this. > > More globally, the draft cites > http://datatracker.ietf.org/wg/roll/charter/ - which (other than making > specific reference to 802.15.4 (and not 15.4g) states that: > > "In most cases, LLNs will be employed over link layers with > restricted frame-sizes, thus a routing protocol for LLNs should be > specifically adapted for such link layers > > We observe some limits on RPL within the framework that the ROLL charter > has set forth. > > I'm not sure I see what more can be done to address this point. > > and there are a number of such examples =85. > > > Personally, I do not believe that there are, but we (I think I can speak > for all the authors here) would very much appreciate your being explicit = on > these examples - least it's hard to discuss them. > > > Well put it differently, it would be beneficial to provide *more details > on your testing scenarios* for the WG to make sure that nothing > is "scenario-dependent" and to make sure that the outcome could indeed > apply to all scenarios, it might be worth being more explicit. > > Could you do that before polling the WG ? > > > Again, I think that reading the I-D, and the RPL RFC, should provide > sufficient information where necessary. > > All of the issues we have brought forward can be understood by looking at > the RPL RFC. > > The "testing scenarios" simply pointed us to what we should look at in th= e > RPL RFC > > Best, > > Thomas > > Thanks. > > JP. > > > Thomas > > > (For example, a deployment using only L2s which provides guaranteed > bi-directional links for L3 would address this by in the applicability > statement stating "As all L2-links are guaranteed bi-directional, this > addresses the issues raised in section 9 in > draft-clausen-lln-rpl-experiences".) > > > Thus, we believe that it would actually be misleading (not to mention, > unnecessarily verbose) to put the "details on the scenarios and testing > environments" into this I-D. > > > Doing so would mislead the reader to believe that the issues presented > only manifest themselves in those precise scenarios - which definitely > isn't the case. > > > JP> see the previous comment and tell us what you think; we could provide > other examples. > > Note that we do not oppose to asking to the WG; we just request you first > to add additional information to proceed forward. > > thanks. > > JP and Michael. > > JP. > > > Best, > > > Thomas > > > Thanks. > > > JP and Michael. > > > > Best, > > > Thomas, Ulrich, Yuichi, Jiazi and Axel > > > > > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --00248c76904228e2e004c02a6190 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable JP,

On Wed, May 16, 2012 at 8:48 AM, JP V= asseur <jpv@cisco.com> wrote:
Hi Thomas,

So =85 le= t me restate a few things:

1) All implementations,= reports about implementations and even more deployment reports are = within the scope of our WG. To make it clear, we were not objecting to anyt= hing, just asking for more information about the ID before polling the WG, = that's all.


We did not intend that draft as "imple= mentation" or "deployment report" about one specific impleme= ntation. Many of the observations in the draft are directly concluded from = the RPL RFC, and not from an implementation. So I second Thomas that provid= ing more information about a single implementation would not really help. <= br>
=A0

2) The point of the report is= to give enough information for reproduce the results and prove or disprove= . So this document requires more precision and a better description of whi= ch implementation were used, what tests have been run, =85 (as also pointed= out by Cedric on the mailing list) =3D> this seems what the WG is askin= g for.

Again, for a large part of the document, the ob= servations are made from the RPL spec. itself. Take for example the fragmen= tation issue; this would be observed by any implementation, running on a co= nstrained link layer, such as in scope for ROLL.
=A0

2) We saw very little discussion on= the mailing list before and after your presentation in Paris; it seems tha= t we got emails from non authors also asking for more details before consid= ering for WG adoption though =85

Same argument as above. Our draft is not intend= ed as implementation report of a single implementation, but general observa= tions of the RPL RFC. I would hope that there is some discussion about the = individual issues that are described in the draft.

=A0

Again, the work is useful and= we try to make it as useful as possible for the community.

Thank you, JP, we appreciate that.

Best = regards
Ulrich


=A0

Thanks again.
=

JP and Michael.

On May 16, 2012, at 3:56 PM, Thomas Heide Clausen wrote:

<= blockquote type=3D"cite">
Dear JP,

On May 16, 2= 012, at 15:54 , JP Vasseur wrote:

Hi,

On May 16, 2012, at 3:1= 7 PM, Thomas Heide Clausen wrote:


=
On May 16, 2012, at 15:04 , JP Vasseur wrote:

Dear Thomas,

On May 16, 2012, at 2:08 PM, Thomas Hei= de Clausen wrote:

Dear JP and Michael,

Thank you for = your mail.

On May 16, 2012, at 09:18 , JP Vasseur wrote:

Dear Thomas,
=

On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote:

<= /blockquote>
Dear JP, Michael, all

Upon JPs invitation, draft-cl= ausen-lln-rpl-experiences was presented and discussed at the Paris meeting.=

The authors consider the document complete and "done", and are lo= oking to take it forward in the IETF
process for publication as "Informational RFC" in the very near f= uture.

We would therefore like to ask the WG chairs, if the ROLL W= G is willing to accept and progress this
document towards publication?
=

Thanks for your suggest= ion. So far we haven't see a lot of discussion/interest from the WG but= your request is
perfectly fair.

=
Thank you - I aim to be fair.

So far there are no details on the scenarios and = testing environments that led to the issues that
you reported, thus = I would suggest you to first include them so that people interested could b= e able to reproduce
it. Once the drat is updated, we'll be happy to pool the WG.
<= br>
Does that = make sense ?

Not really. Let me explain my disagreem= ent.

We tried RPL (and, I note, several different independent implementat= ions of RPL) in a number of different scenarios and deployments, and observ= ed the behaviors exhibited - noting that what we observed across the differ= ent implementations, scenarios and deployments was fairly universal.

We then went back to the specification, to understand these behavior= s in detail, and understand their universality as independent from a specif= ic scenario or deployment or implementation - but rather, as artifacts of t= he RPL protocol design.

We therefore believe that _any_ deployment, scenario or testing envi= ronment of RPL needs to pay attention to the issues presented, and find a w= ay of addressing them. The way of addressing these issues in a given deploy= ment or scenario would be appropriate for an "applicability statement&= quot; for that deployment or scenario.

JP> Thanks for the clarification; that being said, for = the WG to make sure that nothing is "scenario" dependent and the = outcome could indeed apply to all scenarios,
it might be worth being mor= e explicit. For example, you pointed out to the MTU issue, to which I menti= oned that 15.4g would bring a solution, so you may want to
explain that you did not use 15.4g=A0

=
This particular issue is fairly well pointed out in section 6, which r= eferences RFC4919 (cf section 2 hereof) - the particular "small MTU&qu= ot; is not dependent on the specific 127 octets of a specific L2, but a set= of observations that RPL - when faced with a small MTU - may often not be = able to carry a complete control message in a single fragment.=A0Section 6,= 3rd paragraph is fairly explicit as to this.

More globally, the draft cites http://datatracker.ietf.= org/wg/roll/charter/ - which (other than making specific reference to 8= 02.15.4 (and not 15.4g) states that:<= /div>

"In most cases, LLNs wil= l be employed over link layers with=A0
=A0restricte= d frame-sizes, thus a routing protocol for LLNs should be
=A0specifically=A0a= dapted for such link layers

We observe some limits on RPL within the framework that the ROLL cha= rter has set forth.

I'm not sure I see what more can be done to address this point.<= /span>

and there are a number of such examples =85.

Personally, I do not believe that there are, but=A0=A0w= e (I think I can speak for all the authors here) would very much appreciate= your being explicit on these examples - least it's hard to discuss the= m.=A0

Well put it differently, it would be= beneficial to provide more details on your testing scenarios=A0for = the WG to make sure that nothing=A0
is "scenario-dependent&q= uot; and to make sure that the outcome could indeed apply to all scenarios,= =A0it might be worth being more explicit.

Could you do t= hat before polling the WG ?


Again, I think that reading the I-D, and the RPL RFC, s= hould provide sufficient information where necessary.=A0

All of the issues we have brought forward can be understood by looki= ng at the RPL RFC.

The "testing scenarios" simply pointed us to = what we should look at in the RPL RFC

Best,
<= div>
Thomas

Thanks.

JP.


Thomas<= /div>


=
(For example, a deployment using only L2s which p= rovides guaranteed bi-directional links =A0for L3 would address this by in = the applicability statement stating "As all L2-links are guaranteed bi= -directional, this addresses the issues raised in section 9 in draft-clause= n-lln-rpl-experiences".)

Thus, we believe that it would actually be misleading (not to mentio= n, unnecessarily verbose) to put the "details on the scenarios and tes= ting environments" into this I-D.

Doing so would mislead the reader to believe that the issues present= ed only manifest themselves in those precise scenarios - which definitely i= sn't the case.

JP> see the previous comment and tell us what you think= ; we could provide other examples.

Note that we do not oppose to asking to the WG; we just re= quest you first to add additional information to proceed forward.

thanks.

JP and Michael.

JP.


Best,

Thomas

Thanks.

JP and Michael.


Best,

Thomas, Ulrich, Yuichi, Jiazi= and Axel







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


--00248c76904228e2e004c02a6190-- From jpv@cisco.com Wed May 16 10:09:31 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041A721F873D for ; Wed, 16 May 2012 10:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.53 X-Spam-Level: X-Spam-Status: No, score=-110.53 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3YPrdk+rUD8K for ; Wed, 16 May 2012 10:09:30 -0700 (PDT) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id D007321F8722 for ; Wed, 16 May 2012 10:09:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=1101; q=dns/txt; s=iport; t=1337188170; x=1338397770; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=vNWeHAHfQ3O0uXIxYAIzeppdO3QqXF51QD3H2b01TOM=; b=TOf67rLQmk1hWGpYIrqCCJvq5tVtzO79AyHyMENc9z/fSUA+zAOrrMQu JeQV/OCVW/yww4DleBGt0xV3YB9Mc+CgDbr3Pd/tSlFEr6Fq+zU/7e2mw O3/cSWdTRZwMLpcQa1At3xIkqjJvuKZGdbkTfKgH4kPfE6CsuwpljqE9j k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkEFAIvTs0+rRDoH/2dsb2JhbABEDoMPsG6BB4IVAQEBAwESAWYQCw4KLlcGNYdnBAGbI6AFixOEc2IDlXqFdYhigWmCMDs X-IronPort-AV: E=Sophos;i="4.75,604,1330905600"; d="scan'208";a="45051113" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 16 May 2012 17:09:19 +0000 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4GH9J0v010185; Wed, 16 May 2012 17:09:19 GMT Received: from xfe-sjc-231.amer.cisco.com ([128.107.191.114]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 10:09:18 -0700 Received: from [10.60.114.227] ([10.60.114.227]) by xfe-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 May 2012 10:09:18 -0700 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: JP Vasseur In-Reply-To: Date: Wed, 16 May 2012 19:05:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5925112F-9E74-44C8-AA87-D9E80055E870@cisco.com> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> To: Philip Levis X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 16 May 2012 17:09:18.0385 (UTC) FILETIME=[A1073210:01CD3386] Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 17:09:31 -0000 indeed On May 16, 2012, at 7:02 PM, Philip Levis wrote: >=20 > On May 16, 2012, at 6:54 AM, JP Vasseur wrote: >>=20 >> Well put it differently, it would be beneficial to provide more = details on your testing scenarios for the WG to make sure that nothing=20= >> is "scenario-dependent" and to make sure that the outcome could = indeed apply to all scenarios, it might be worth being more explicit. >>=20 >> Could you do that before polling the WG ? >=20 > I think an example of what JP's talking about might be something such = as the question I raised in Paris: what constitutes a "down link" in the = testing? Thomas' response was "no ack after L2 retransmissions"; this is = an assumption about behavior. How many retransmissions? What was the = time spacing? It's not hard to configure 802.11, for example, such that = L2 back off has only a tiny chance of successful delivery in the case of = a hidden terminal. Most wireless protocol implementations today = understand these issues and rely on much longer time frames to consider = a link "down." >=20 > Phil >=20 From ietf@thomasclausen.org Wed May 16 10:11:37 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D66F21F86F9 for ; Wed, 16 May 2012 10:11:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.709 X-Spam-Level: X-Spam-Status: No, score=-3.709 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, GB_I_INVITATION=-2, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YipdqitKvmy6 for ; Wed, 16 May 2012 10:11:32 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9E121F873A for ; Wed, 16 May 2012 10:11:32 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id F28B35581DD for ; Wed, 16 May 2012 10:11:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id C42931BDC2F5; Wed, 16 May 2012 10:11:31 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id 8072D1BDC2F3; Wed, 16 May 2012 10:11:30 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: multipart/alternative; boundary="Apple-Mail=_279EEB1E-9ECD-4904-AE76-530DC427E76E" From: Thomas Heide Clausen In-Reply-To: <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> Date: Wed, 16 May 2012 19:11:28 +0200 Message-Id: References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1257) Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 17:11:37 -0000 --Apple-Mail=_279EEB1E-9ECD-4904-AE76-530DC427E76E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear JP, Michael, On May 16, 2012, at 17:48 , JP Vasseur wrote: > Hi Thomas, >=20 > So =85 let me restate a few things: >=20 > 1) All implementations, reports about implementations and even more = deployment reports are within the scope of our WG. To make it clear, we = were not objecting to anything, just asking for more information about = the ID before polling the WG, that's all. >=20 This I-D is, however, neither an implementation report nor a deployment = report. It is a report on observations on that which has been published = in the RPL RFC. These can be made even without an implementation. We did conduct experiments, which lead us to observe phenomenons which = we didn't expect. We then turned to the axioms (in this case, the RPL = RFC) to explain those phenomenons - that explanation is this I-D. (Or, do you believe that the anecdote about apple hitting Isaac Newton = in the head is fundamental to understanding gravity?) > 2) The point of the report is to give enough information for reproduce = the results and prove or disprove . So this document requires more = precision and a better description of which implementation were used, = what tests have been run, =85 (as also pointed out by Cedric on the = mailing list) =3D> this seems what the WG is asking for. No, that is precisely the point, it doesn't. For example:=20 o the state required for storing/non-storing mode does = *not* depend on a=20 specific implementation and deployment, but is an = artifact from the RPL design. o the message-size of RPL is not dependent on a specific = implementation and deployment, but is an artifact from the RPL design. o the use of links "upwards" based on receipt of traffic = "downwards" (i.e. the unidirectional link issue) is not dependent on a specific = implementation and deployment, but is an artifact from the RPL design. o the unknown-by-source MTU issues for data-traffic when = using non-storing mode=20 is not dependent on a specific implementation and = deployment, but is an artifact from the RPL design. I could go on, but then it'd be easier to just paste the whole I-D into = this email. > 2) We saw very little discussion on the mailing list before and after = your presentation in Paris; it seems that we got emails from non authors = also asking for more details before considering for WG adoption though =85= My observation is, however, that as the details requested are immaterial = to the observations in the I-D, there must be other reasons for which = they are requested..... > Again, the work is useful and we try to make it as useful as possible = for the community. >=20 That is not what transpires from these emails. Thomas > Thanks again. >=20 > JP and Michael. >=20 > On May 16, 2012, at 3:56 PM, Thomas Heide Clausen wrote: >=20 >> Dear JP, >>=20 >> On May 16, 2012, at 15:54 , JP Vasseur wrote: >>=20 >>> Hi, >>>=20 >>> On May 16, 2012, at 3:17 PM, Thomas Heide Clausen wrote: >>>=20 >>>>=20 >>>> On May 16, 2012, at 15:04 , JP Vasseur wrote: >>>>=20 >>>>> Dear Thomas, >>>>>=20 >>>>> On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: >>>>>=20 >>>>>> Dear JP and Michael, >>>>>>=20 >>>>>> Thank you for your mail. >>>>>>=20 >>>>>> On May 16, 2012, at 09:18 , JP Vasseur wrote: >>>>>>=20 >>>>>>> Dear Thomas, >>>>>>>=20 >>>>>>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>>>>>>=20 >>>>>>>> Dear JP, Michael, all >>>>>>>>=20 >>>>>>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was = presented and discussed at the Paris meeting. >>>>>>>>=20 >>>>>>>> The authors consider the document complete and "done", and are = looking to take it forward in the IETF=20 >>>>>>>> process for publication as "Informational RFC" in the very near = future.=20 >>>>>>>>=20 >>>>>>>> We would therefore like to ask the WG chairs, if the ROLL WG is = willing to accept and progress this=20 >>>>>>>> document towards publication? >>>>>>>=20 >>>>>>> Thanks for your suggestion. So far we haven't see a lot of = discussion/interest from the WG but your request is >>>>>>> perfectly fair. >>>>>>=20 >>>>>> Thank you - I aim to be fair. >>>>>>=20 >>>>>>> So far there are no details on the scenarios and testing = environments that led to the issues that=20 >>>>>>> you reported, thus I would suggest you to first include them so = that people interested could be able to reproduce >>>>>>> it. Once the drat is updated, we'll be happy to pool the WG. >>>>>>>=20 >>>>>>> Does that make sense ? >>>>>>=20 >>>>>> Not really. Let me explain my disagreement. >>>>>>=20 >>>>>> We tried RPL (and, I note, several different independent = implementations of RPL) in a number of different scenarios and = deployments, and observed the behaviors exhibited - noting that what we = observed across the different implementations, scenarios and deployments = was fairly universal. >>>>>>=20 >>>>>> We then went back to the specification, to understand these = behaviors in detail, and understand their universality as independent = from a specific scenario or deployment or implementation - but rather, = as artifacts of the RPL protocol design. >>>>>>=20 >>>>>> We therefore believe that _any_ deployment, scenario or testing = environment of RPL needs to pay attention to the issues presented, and = find a way of addressing them. The way of addressing these issues in a = given deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario. >>>>>=20 >>>>> JP> Thanks for the clarification; that being said, for the WG to = make sure that nothing is "scenario" dependent and the outcome could = indeed apply to all scenarios, >>>>> it might be worth being more explicit. For example, you pointed = out to the MTU issue, to which I mentioned that 15.4g would bring a = solution, so you may want to=20 >>>>> explain that you did not use 15.4g=20 >>>>=20 >>>> This particular issue is fairly well pointed out in section 6, = which references RFC4919 (cf section 2 hereof) - the particular "small = MTU" is not dependent on the specific 127 octets of a specific L2, but a = set of observations that RPL - when faced with a small MTU - may often = not be able to carry a complete control message in a single fragment. = Section 6, 3rd paragraph is fairly explicit as to this. >>>>=20 >>>> More globally, the draft cites = http://datatracker.ietf.org/wg/roll/charter/ - which (other than making = specific reference to 802.15.4 (and not 15.4g) states that: >>>>=20 >>>> "In most cases, LLNs will be employed over link layers with=20 >>>> restricted frame-sizes, thus a routing protocol for LLNs should = be >>>> specifically adapted for such link layers >>>>=20 >>>> We observe some limits on RPL within the framework that the ROLL = charter has set forth. >>>>=20 >>>> I'm not sure I see what more can be done to address this point. >>>>=20 >>>>> and there are a number of such examples =85. >>>>=20 >>>>=20 >>>> Personally, I do not believe that there are, but we (I think I can = speak for all the authors here) would very much appreciate your being = explicit on these examples - least it's hard to discuss them.=20 >>>=20 >>> Well put it differently, it would be beneficial to provide more = details on your testing scenarios for the WG to make sure that nothing=20= >>> is "scenario-dependent" and to make sure that the outcome could = indeed apply to all scenarios, it might be worth being more explicit. >>>=20 >>=20 >>> Could you do that before polling the WG ? >>>=20 >>=20 >> Again, I think that reading the I-D, and the RPL RFC, should provide = sufficient information where necessary.=20 >>=20 >> All of the issues we have brought forward can be understood by = looking at the RPL RFC. >>=20 >> The "testing scenarios" simply pointed us to what we should look at = in the RPL RFC >>=20 >> Best, >>=20 >> Thomas >>=20 >>> Thanks. >>>=20 >>> JP. >>>=20 >>>>=20 >>>> Thomas >>>>=20 >>>>>>=20 >>>>>> (For example, a deployment using only L2s which provides = guaranteed bi-directional links for L3 would address this by in the = applicability statement stating "As all L2-links are guaranteed = bi-directional, this addresses the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".) >>>>>>=20 >>>>>> Thus, we believe that it would actually be misleading (not to = mention, unnecessarily verbose) to put the "details on the scenarios and = testing environments" into this I-D. >>>>>>=20 >>>>>> Doing so would mislead the reader to believe that the issues = presented only manifest themselves in those precise scenarios - which = definitely isn't the case. >>>>>=20 >>>>> JP> see the previous comment and tell us what you think; we could = provide other examples. >>>>>=20 >>>>> Note that we do not oppose to asking to the WG; we just request = you first to add additional information to proceed forward. >>>>>=20 >>>>> thanks. >>>>>=20 >>>>> JP and Michael. >>>>>=20 >>>>> JP. >>>>>=20 >>>>>>=20 >>>>>> Best, >>>>>>=20 >>>>>> Thomas >>>>>>=20 >>>>>>> Thanks. >>>>>>>=20 >>>>>>> JP and Michael. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Best, >>>>>>>>=20 >>>>>>>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>=20 >=20 --Apple-Mail=_279EEB1E-9ECD-4904-AE76-530DC427E76E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = JP, Michael,

On May 16, 2012, at 17:48 , JP Vasseur = wrote:

Hi = Thomas,

So =85 let me restate a few = things:

1) All implementations, reports about = implementations and even more deployment reports are within the = scope of our WG. To make it clear, we were not objecting to anything, = just asking for more information about the ID before polling the WG, = that's = all.


This I-D = is, however, neither an implementation report nor a deployment report. = It is a report on observations on that which has been published in the = RPL RFC. These can be made even without an = implementation.

We did conduct experiments, = which lead us to observe phenomenons which we didn't expect. We then = turned to the axioms (in this case, the RPL RFC) to explain those = phenomenons - that explanation is this = I-D.

(Or, do you believe that the anecdote = about apple hitting Isaac Newton in the head is fundamental to = understanding gravity?)

2) The point of the report = is to give enough information for reproduce the results and prove or = disprove . So this document requires more precision and a better = description of which implementation were used, what tests have been run, = =85 (as also pointed out by Cedric on the mailing list) =3D> this = seems what the WG is asking = for.

No, that is precisely the = point, it doesn't.

For = example: 

o the state required for = storing/non-storing mode does *not* depend on a 
= specific implementation and deployment, but is an artifact from = the RPL design.

o the message-size of RPL is not = dependent on a specific implementation and deployment,
= but is an artifact from the RPL = design.

o the use of links "upwards" based = on receipt of traffic "downwards" (i.e. the = unidirectional
link issue) is not = dependent on a specific implementation and deployment,
= but is an artifact from the RPL = design.

o the unknown-by-source MTU issues = for data-traffic when using non-storing mode 
= is not dependent on a specific implementation and = deployment,
but is an artifact from the RPL = design.

I could go on, but then it'd be easier = to just paste the whole I-D into this = email.

2) We saw very little = discussion on the mailing list before and after your presentation in = Paris; it seems that we got emails from non authors also asking for more = details before considering for WG adoption though = =85

My observation is, however, = that as the details requested are immaterial to the observations in the = I-D, there must be other reasons for which they are = requested.....

Again, the work is useful = and we try to make it as useful as possible for the = community.


That is = not what transpires from these = emails.

Thomas

Thanks = again.

JP and = Michael.

On May 16, 2012, at 3:56 PM, Thomas = Heide Clausen wrote:

Dear JP,

On = May 16, 2012, at 15:54 , JP Vasseur wrote:

Hi,

On May = 16, 2012, at 3:17 PM, Thomas Heide Clausen wrote:


On May 16, 2012, = at 15:04 , JP Vasseur wrote:

Dear = Thomas,

On May 16, 2012, at 2:08 PM, Thomas Heide Clausen = wrote:

Dear JP and = Michael,

Thank you for = your mail.

On May 16, = 2012, at 09:18 , JP Vasseur wrote:

Dear Thomas,

On May 11, 2012, at 8:25 AM, = Thomas Heide Clausen wrote:

Dear = JP, Michael, all

Upon = JPs invitation, draft-clausen-lln-rpl-experiences was presented and = discussed at the Paris = meeting.

The = authors consider the document complete and "done", and are looking to = take it forward in the IETF =
process = for publication as "Informational RFC" in the very near future. =

We = would therefore like to ask the WG chairs, if the ROLL WG is willing to = accept and progress this =
document= towards = publication?

Thanks for your suggestion. So = far we haven't see a lot of discussion/interest from the WG but your = request is
perfectly = fair.

Thank you - I = aim to be fair.

So far there are no details on the scenarios and testing = environments that led to the issues that =
you reported, thus I would suggest you to first include = them so that people interested could be able to = reproduce
it. Once the drat is updated, = we'll be happy to pool the WG.

Does that make sense = ?

Not really. Let = me explain my disagreement.

We tried RPL = (and, I note, several different independent implementations of RPL) in a = number of different scenarios and deployments, and observed the = behaviors exhibited - noting that what we observed across the different = implementations, scenarios and deployments was fairly = universal.

We then went = back to the specification, to understand these behaviors in detail, and = understand their universality as independent from a specific scenario or = deployment or implementation - but rather, as artifacts of the RPL = protocol design.

We therefore = believe that _any_ deployment, scenario or testing environment of RPL = needs to pay attention to the issues presented, and find a way of = addressing them. The way of addressing these issues in a given = deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario.

JP> = Thanks for the clarification; that being said, for the WG to make sure = that nothing is "scenario" dependent and the outcome could indeed apply = to all scenarios,
it might be worth being more explicit. For example, = you pointed out to the MTU issue, to which I mentioned that 15.4g would = bring a solution, so you may want to
explain that you did not use = 15.4g 

This particular = issue is fairly well pointed out in section 6, which references RFC4919 = (cf section 2 hereof) - the particular "small MTU" is not dependent on = the specific 127 octets of a specific L2, but a set of observations that = RPL - when faced with a small MTU - may often not be able to carry a = complete control message in a single fragment. Section 6, 3rd = paragraph is fairly explicit as to this.

More = globally, the draft cites http://datatracker.i= etf.org/wg/roll/charter/ - which (other than making specific = reference to 802.15.4 (and not 15.4g) states that:

"In most cases, LLNs will be = employed over link layers with 
=  restricted frame-sizes, thus a routing protocol for LLNs = should be
=  specifically adapted for such link = layers

We observe some limits on RPL within the framework that the ROLL = charter has set forth.

I'm not sure I see what more can be done to address this = point.

and = there are a number of such examples = =85.

Personally, I do not = believe that there are, but  we (I think I can speak for all = the authors here) would very much appreciate your being explicit on = these examples - least it's hard to discuss = them. 

Well put it = differently, it would be beneficial to provide more details on your = testing scenarios for the WG to make sure that = nothing 
is "scenario-dependent" and to make sure that = the outcome could indeed apply to all scenarios, it might be worth = being more = explicit.


Best,

Thomas

Thanks.

JP.


(For example, a deployment using only L2s which provides = guaranteed bi-directional links  for L3 would address this by in = the applicability statement stating "As all L2-links are guaranteed = bi-directional, this addresses the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".)

Thus, we = believe that it would actually be misleading (not to mention, = unnecessarily verbose) to put the "details on the scenarios and testing = environments" into this I-D.

Doing so would = mislead the reader to believe that the issues presented only manifest = themselves in those precise scenarios - which definitely isn't the = case.

JP> see the previous comment and tell us = what you think; we could provide other = examples.

Note = that we do not oppose to asking to the WG; we just request you first to = add additional information to proceed forward.

thanks.

JP = and Michael.

JP.


Best,

Thomas

Thanks.

JP and = Michael.


Best,

Thomas, = Ulrich, Yuichi, Jiazi and = Axel








= --Apple-Mail=_279EEB1E-9ECD-4904-AE76-530DC427E76E-- From ietf@thomasclausen.org Wed May 16 10:37:34 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 628A921F8513 for ; Wed, 16 May 2012 10:37:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.765 X-Spam-Level: X-Spam-Status: No, score=-4.765 tagged_above=-999 required=5 tests=[AWL=1.500, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDhuDDesIk2k for ; Wed, 16 May 2012 10:37:33 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1529021F8512 for ; Wed, 16 May 2012 10:37:33 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id F2A3B558073 for ; Wed, 16 May 2012 10:37:32 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id D73381BDC703; Wed, 16 May 2012 10:37:32 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id C38E41BDC6FF; Wed, 16 May 2012 10:37:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Thomas Heide Clausen In-Reply-To: <4818180C-19D8-4C01-A65C-04DD47B9FCB2@watteco.com> Date: Wed, 16 May 2012 19:37:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <22B18A3C-B327-4AD6-9D94-901CF225BE98@watteco.com> <0AA713FC-2C91-41E4-80BF-3DA3FF450324@thomasclausen.org> <4818180C-19D8-4C01-A65C-04DD47B9FCB2@watteco.com> To: C Chauvenet X-Mailer: Apple Mail (2.1257) Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 17:37:34 -0000 Dear Cedric, On May 16, 2012, at 18:48 , C Chauvenet wrote: > Thomas, > See inline, =20 >=20 > Le 16 mai 2012 =E0 17:08, Thomas Heide Clausen a =E9crit : >=20 >> Dear Cedric, >>=20 >> Thank you for your email. Comments below. >>=20 >> On 16 May 2012, at 16:13, C Chauvenet = wrote: >>=20 >>> Hi,=20 >>>=20 >>> I definitely agree that implementation feedback is always good to = know, so your experiences are welcomed. >>>=20 >>> I also think that problems investigations need a complete and exact = view, so I would encourage you to put much more details about the = scenario and the environment where you experimentations took place. >>> For instance, I would enjoy a "RPL Implementation Description" = section in you draft listing the hardware your used, your RPL = parameters, the RPL drafts and mechanisms implemented, your OS etc... >>=20 >> As I indicated to JP already: >>=20 >> 1) this draft is not "just" based on a single scenario, environment = or implementation=20 >> (and, therefore, not "just" based on a single test).=20 >=20 > Does it means that your run multiple scenarios ?=20 > That would be great. >=20 As indicated elsewhere, yes. Although its details are immaterial to this = discussion, >>=20 >> 2) the observations that we made during the test_S_ served to make = us look at the RPL >> RFC again, to explain our observations and to generalize them = from the written word >> of that RFC. >>=20 >> Therefore, I do not think that any such description would bring = anything (other than entropy and delay) to the process. The RPL RFC and = this I-D is more than sufficient. >>=20 >> As to what features were implemented, that is easy to answer: the RPL = RFC (except for security) to the letter and with the parameters = suggested there, and OF0. However, even the parameters are immaterial = for the observations listed in this I-D. >=20 > I think we are progressing on the definition of your RPL = implementation : could you also precise what part of the RPL spec you = have implemented ? eg. What mode of Operation and why, what options did = you choose to include in DIO messages, your metrics .... >=20 1) All the relevant details are included in the I-D 2) Again, the observations in that I-D can be made from looking = (now that we know what to look for) in the RPL RFC 3) The experiments only served to help us see "what to look for" in = the RPL RFC. 4) See also email that I recently sent to JP. >>=20 >>> If I read a paper with orthogonal observations with the same level = of details as in your draft, then how could I forge my opinion ? >>=20 >> I'd suggest reading the indicated parts of the RPL RFC conjointly = with this I-D. Again, the observations that we present in this I-D make = exclusive reference to RPL, and not to a specific implementation or = deployment. >>=20 >>> Looking at this draft, it seems that it gathers lots of previous = discussions that occurred during the past year on various mailing lists, = and IETF meetings. >>>=20 >>> Does your experimentations takes care about these recommendations ? >>=20 >> Again, the issues raised in this I-D are based on what can be = observed from the RPL RFC.=20 >>=20 >> If there are additional considerations required (which you seem to = indicate to be the case) which are not reflected in the RPL RFC, in = order to overcome the issues raised, then that indeed should be a big = problem for the IETF and for ROLL.... >=20 > These recommendations were for the problems you pointed out in *Your* = implementation. > Of course if other implementers are facing to the same problems, they = could rely on it, but I have not heard about similar problems outside = your lab from now. These are not implementation problems, these are artifacts from the RPL = RFC design choices. >>=20 >>> If not, does your draft mention the propositions that have been made = to address the problems you point out in your draft ? >>> I think it could be worth to leverage on these previous discussions. >>=20 >> I firmly disagree. The IETF and ROLL has published an RFC - that's = what this I-D discusses.=20 >>=20 >> Discussing what may have been proposed in other media would be = entirely out of scope. >=20 > Again, this is not related to the RPL RFC but *your* implementation = that received some guidance regarding its problems. > The RPL RFC should not include tips for your implementation, but your = implementation and your draft should pay attention to the tips given to = you. >=20 This has nothing to do with "tips for [my] implementation whatsoever. = See examples I gave in reply to JP. >>=20 >>> Your draft is a list of Description and Observations. >>> Maybe you could add a "Resolution Proposal" section for each = problem, gathering previous discussion and your own proposals ? >>=20 >> Nope. That's not the objective of this I-D. >=20 > That's too bad, this is what all readers of this draft are looking for = ! It would be great to have that, so please write such a draft, addressing = the issues that this I-D has presented. I am personally a great fan also of interoperability reports (something = which ROLL doesn't have either and which is not the point of this I-D = either) > Without offense, saying "this is bad" without a better proposition = seems like half-work !=20 > And this is true for most of the discussion topics in life, far away = from RPL ! >=20 >> I would venture that if the WG is serious about applicability = statements, then those applicability statements would be the place for = discussion of "how this issue, raised in this I-D, is addressed or moot = for a given deployment". >>=20 >>> Identifying what is wrong in your implementation >>=20 >> Considering that these observations are not implementation-specific, = but are directly on the RPL RFC, I venture the observations that there's = nothing "wrong in my implementation" here. >>=20 >=20 > As a general comment : RPL is a routing protocol targeted for a very = wide application area.=20 > Some may think this is good because it covers a lot of needs. > Some may think it is bad because it is wide and not specific enough = for their application. > Wathever your position, these two arguments are valid, this is all a = matter of viewpoint and tradeoff. I disagree here, Cedric, but this thread is not the place for that = particular discussion. > So, because RPL is wide enough for multiple application, you have to = take some time to tune it correctly, according to your application. I disagree here, Cedric, but this thread is not the place for that = particular discussion. This I-D does *not* discuss a specific = application or deployment, but merely reflects on RPL, as published by = the ROLL working group. > One simple choice that every RPL implementers will ave to answer is : = Use Storing or Non Storing Mode ? This is a fondamental design choice = that cannot be made outside a scenario consideration. I agree here. And, this I-D provides some observations - for example about storage = requirements, and about requirements for all RPL routers in (for = example, for storing node) the case that the DODAG root can fail and = floating DODAGs created. This has nothing to do with a specific implementation, deployment, = experiment, scenario or application, but is an artifact of a fundamental = design choice made in RPL. > Be sure that there is no magic RPL tuning that works for all, but = multiple fine RPL tuning for multiple applications. > I honestly cannot believe in generic results given the incredibly = variety of tuning that RPL can have. This is, again, not a matter of "tuning of parameters" at all. That's = not what the I-D describes, or aims at describing. > So my final position is that we disagree on the need of more details = in your experiments. I'm afraid that I disagree for this I-D. That's not the point of it, and = I think that it is fairly clear in the I-D that it's not (as well as it = is clear what the point is, and what the goals are for it) I think that it would be interesting to have another I-D describe = parameter tunings etc for a given application. I would expect that to be = part of what the applicability statements were supposed to do. It's, = however, still not in this I-D that it should be done. Thomas > C=E9dric. >=20 >> Thomas >>=20 >>=20 >>> is a good first step, but the hardest part is to propose some = corrections. >>> Best Regards, >>>=20 >>> C=E9dric Chauvenet. >>>=20 >>> Le 16 mai 2012 =E0 15:04, JP Vasseur a =E9crit : >>>=20 >>>> Dear Thomas, >>>>=20 >>>> On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: >>>>=20 >>>>> Dear JP and Michael, >>>>>=20 >>>>> Thank you for your mail. >>>>>=20 >>>>> On May 16, 2012, at 09:18 , JP Vasseur wrote: >>>>>=20 >>>>>> Dear Thomas, >>>>>>=20 >>>>>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>>>>>=20 >>>>>>> Dear JP, Michael, all >>>>>>>=20 >>>>>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was = presented and discussed at the Paris meeting. >>>>>>>=20 >>>>>>> The authors consider the document complete and "done", and are = looking to take it forward in the IETF=20 >>>>>>> process for publication as "Informational RFC" in the very near = future.=20 >>>>>>>=20 >>>>>>> We would therefore like to ask the WG chairs, if the ROLL WG is = willing to accept and progress this=20 >>>>>>> document towards publication? >>>>>>=20 >>>>>> Thanks for your suggestion. So far we haven't see a lot of = discussion/interest from the WG but your request is >>>>>> perfectly fair. >>>>>=20 >>>>> Thank you - I aim to be fair. >>>>>=20 >>>>>> So far there are no details on the scenarios and testing = environments that led to the issues that=20 >>>>>> you reported, thus I would suggest you to first include them so = that people interested could be able to reproduce >>>>>> it. Once the drat is updated, we'll be happy to pool the WG. >>>>>>=20 >>>>>> Does that make sense ? >>>>>=20 >>>>> Not really. Let me explain my disagreement. >>>>>=20 >>>>> We tried RPL (and, I note, several different independent = implementations of RPL) in a number of different scenarios and = deployments, and observed the behaviors exhibited - noting that what we = observed across the different implementations, scenarios and deployments = was fairly universal. >>>>>=20 >>>>> We then went back to the specification, to understand these = behaviors in detail, and understand their universality as independent = from a specific scenario or deployment or implementation - but rather, = as artifacts of the RPL protocol design. >>>>>=20 >>>>> We therefore believe that _any_ deployment, scenario or testing = environment of RPL needs to pay attention to the issues presented, and = find a way of addressing them. The way of addressing these issues in a = given deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario. >>>>=20 >>>> JP> Thanks for the clarification; that being said, for the WG to = make sure that nothing is "scenario" dependent and the outcome could = indeed apply to all scenarios, >>>> it might be worth being more explicit. For example, you pointed out = to the MTU issue, to which I mentioned that 15.4g would bring a = solution, so you may want to=20 >>>> explain that you did not use 15.4g and there are a number of such = examples =85. >>>>=20 >>>>>=20 >>>>> (For example, a deployment using only L2s which provides = guaranteed bi-directional links for L3 would address this by in the = applicability statement stating "As all L2-links are guaranteed = bi-directional, this addresses the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".) >>>>>=20 >>>>> Thus, we believe that it would actually be misleading (not to = mention, unnecessarily verbose) to put the "details on the scenarios and = testing environments" into this I-D. >>>>>=20 >>>>> Doing so would mislead the reader to believe that the issues = presented only manifest themselves in those precise scenarios - which = definitely isn't the case. >>>>=20 >>>> JP> see the previous comment and tell us what you think; we could = provide other examples. >>>>=20 >>>> Note that we do not oppose to asking to the WG; we just request you = first to add additional information to proceed forward. >>>>=20 >>>> thanks. >>>>=20 >>>> JP and Michael. >>>>=20 >>>> JP. >>>>=20 >>>>>=20 >>>>> Best, >>>>>=20 >>>>> Thomas >>>>>=20 >>>>>> Thanks. >>>>>>=20 >>>>>> JP and Michael. >>>>>>=20 >>>>>>>=20 >>>>>>> Best, >>>>>>>=20 >>>>>>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>=20 >>>=20 >>=20 >=20 >=20 From thomas@thomasclausen.org Wed May 16 10:52:06 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 089C321F8617 for ; Wed, 16 May 2012 10:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.265 X-Spam-Level: X-Spam-Status: No, score=-3.265 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, GB_I_INVITATION=-2, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ryM1rJQRqSR for ; Wed, 16 May 2012 10:52:05 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1E03621F8552 for ; Wed, 16 May 2012 10:52:05 -0700 (PDT) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 1007FA30AD for ; Wed, 16 May 2012 10:52:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id B56CF1BDC899; Wed, 16 May 2012 10:52:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.0.1.2] (sphinx.lix.polytechnique.fr [129.104.11.1]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id AEA5D1BDC8A7; Wed, 16 May 2012 10:52:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Thomas Heide Clausen In-Reply-To: <418765560.417509.1337180037325.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Wed, 16 May 2012 19:52:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <418765560.417509.1337180037325.JavaMail.root@mail17.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1257) Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 17:52:06 -0000 Dear Mukul, On May 16, 2012, at 16:53 , Mukul Goyal wrote: > I agree with Cedric. Issues that Cedric has raised are very basic and = should have already been taken care of in the document. Seriously, do = the authors think that this document would pass the muster for = publication in any decent academic journal? I'm not sure that I follow this argument above. Was this a requirement = for publication of the other ROLL documents? Engineering !=3D Research ? > Right now, the draft reads more like propaganda than information: = written to bad mouth a protocol on the basis of biased/frivolous = arguments. I am sorry, I take exception to those insinuations and accusations. > Why would the authors completely ignore P2P-RPL even though it = resolves many issues they have pointed out. If RPL normatively required P2P-RPL, or if P2P-RPL was intended as = "Obsoletes RPL", then this argument would have weight. As it is, IIRC, = P2P-RPL is aiming for Experimental, and isn't an RFC? > There are numerous similar sins of omission spread throughout the = document. As a result, most conclusions the document reaches are open to = doubt if not outright incorrect. I am sorry, I also take exception to the above insult - dispensed = without supporting evidence. > Sure, RPL is not a perfect protocol - no protocol is. But this = document is not an unbiased scientific analysis of the protocol. I am sorry, I also take exception to the above insult - dispensed = without supporting evidence. > As Pascal said, this document could have served a valuable = constructive purpose. But, perhaps this was not the intention of the = authors. I am sorry, I also take exception to the above insinuations and = accusations. - dispensed without supporting evidence. > This document should be recognized for what it is: a political = document written to further a particular destructive agenda. I am sorry, I also take exception to the above insult, insinuations and = accusations. - dispensed without supporting evidence. May I suggest that the discussion be brought up a notch, to address the = technical issues raised in this I-D?=20 Thomas (who, fortunately, is equipped with a relatively thick skin) >=20 > Thanks > Mukul >=20 > ----- Original Message ----- > From: "C Chauvenet" > To: "JP Vasseur" > Cc: "roll WG" , "Michael Richardson" > Sent: Wednesday, May 16, 2012 9:13:56 AM > Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences >=20 > Hi,=20 >=20 > I definitely agree that implementation feedback is always good to = know, so your experiences are welcomed. >=20 > I also think that problems investigations need a complete and exact = view, so I would encourage you to put much more details about the = scenario and the environment where you experimentations took place. > For instance, I would enjoy a "RPL Implementation Description" section = in you draft listing the hardware your used, your RPL parameters, the = RPL drafts and mechanisms implemented, your OS etc... > If I read a paper with orthogonal observations with the same level of = details as in your draft, then how could I forge my opinion ? >=20 > Looking at this draft, it seems that it gathers lots of previous = discussions that occurred during the past year on various mailing lists, = and IETF meetings. >=20 > Does your experimentations takes care about these recommendations ? > If not, does your draft mention the propositions that have been made = to address the problems you point out in your draft ? > I think it could be worth to leverage on these previous discussions. >=20 > Your draft is a list of Description and Observations. > Maybe you could add a "Resolution Proposal" section for each problem, = gathering previous discussion and your own proposals ? > Identifying what is wrong in your implementation is a good first step, = but the hardest part is to propose some corrections. >=20 > Best Regards, >=20 > C=E9dric Chauvenet. >=20 > Le 16 mai 2012 =E0 15:04, JP Vasseur a =E9crit : >=20 >> Dear Thomas, >>=20 >> On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: >>=20 >>> Dear JP and Michael, >>>=20 >>> Thank you for your mail. >>>=20 >>> On May 16, 2012, at 09:18 , JP Vasseur wrote: >>>=20 >>>> Dear Thomas, >>>>=20 >>>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>>>=20 >>>>> Dear JP, Michael, all >>>>>=20 >>>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was = presented and discussed at the Paris meeting. >>>>>=20 >>>>> The authors consider the document complete and "done", and are = looking to take it forward in the IETF=20 >>>>> process for publication as "Informational RFC" in the very near = future.=20 >>>>>=20 >>>>> We would therefore like to ask the WG chairs, if the ROLL WG is = willing to accept and progress this=20 >>>>> document towards publication? >>>>=20 >>>> Thanks for your suggestion. So far we haven't see a lot of = discussion/interest from the WG but your request is >>>> perfectly fair. >>>=20 >>> Thank you - I aim to be fair. >>>=20 >>>> So far there are no details on the scenarios and testing = environments that led to the issues that=20 >>>> you reported, thus I would suggest you to first include them so = that people interested could be able to reproduce >>>> it. Once the drat is updated, we'll be happy to pool the WG. >>>>=20 >>>> Does that make sense ? >>>=20 >>> Not really. Let me explain my disagreement. >>>=20 >>> We tried RPL (and, I note, several different independent = implementations of RPL) in a number of different scenarios and = deployments, and observed the behaviors exhibited - noting that what we = observed across the different implementations, scenarios and deployments = was fairly universal. >>>=20 >>> We then went back to the specification, to understand these = behaviors in detail, and understand their universality as independent = from a specific scenario or deployment or implementation - but rather, = as artifacts of the RPL protocol design. >>>=20 >>> We therefore believe that _any_ deployment, scenario or testing = environment of RPL needs to pay attention to the issues presented, and = find a way of addressing them. The way of addressing these issues in a = given deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario. >>=20 >> JP> Thanks for the clarification; that being said, for the WG to make = sure that nothing is "scenario" dependent and the outcome could indeed = apply to all scenarios, >> it might be worth being more explicit. For example, you pointed out = to the MTU issue, to which I mentioned that 15.4g would bring a = solution, so you may want to=20 >> explain that you did not use 15.4g and there are a number of such = examples =85. >>=20 >>>=20 >>> (For example, a deployment using only L2s which provides guaranteed = bi-directional links for L3 would address this by in the applicability = statement stating "As all L2-links are guaranteed bi-directional, this = addresses the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".) >>>=20 >>> Thus, we believe that it would actually be misleading (not to = mention, unnecessarily verbose) to put the "details on the scenarios and = testing environments" into this I-D. >>>=20 >>> Doing so would mislead the reader to believe that the issues = presented only manifest themselves in those precise scenarios - which = definitely isn't the case. >>=20 >> JP> see the previous comment and tell us what you think; we could = provide other examples. >>=20 >> Note that we do not oppose to asking to the WG; we just request you = first to add additional information to proceed forward. >>=20 >> thanks. >>=20 >> JP and Michael. >>=20 >> JP. >>=20 >>>=20 >>> Best, >>>=20 >>> Thomas >>>=20 >>>> Thanks. >>>>=20 >>>> JP and Michael. >>>>=20 >>>>>=20 >>>>> Best, >>>>>=20 >>>>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >>=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From prvs=4766ac5fc=mukul@uwm.edu Wed May 16 11:25:47 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EC9121F865A for ; Wed, 16 May 2012 11:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.59 X-Spam-Level: X-Spam-Status: No, score=-7.59 tagged_above=-999 required=5 tests=[AWL=1.009, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxGCDu3VnamU for ; Wed, 16 May 2012 11:25:46 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id E9BD421F860E for ; Wed, 16 May 2012 11:25:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAIvTs09/AAAB/2dsb2JhbABEhXyxKwEBAQMBAQEBIEsLBQcPEQQBAQECAg0ZAikoCAYTG4duBQuoLYlniQUEgSaJbRmEJ4EVA4hjjReQQIMHgUE Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 0A46912E3BA; Wed, 16 May 2012 13:25:45 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id misVvOC6omyP; Wed, 16 May 2012 13:25:44 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 864D812E3AE; Wed, 16 May 2012 13:25:44 -0500 (CDT) Date: Wed, 16 May 2012 13:25:44 -0500 (CDT) From: Mukul Goyal To: Ulrich Herberg Message-ID: <1011855243.422503.1337192744447.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 18:25:47 -0000 >>Seriously, do the authors think that this document would pass the muster = for publication in any decent academic journal?=20 >I don't know since when that is any criteria for IETF work. Was it a crite= ria for the standardization of RPL itself?=20 RPL is a protocol specification whereas your document is an analysis of its= performance. The performance analysis papers fall in academic domain and m= ust follow a certain rigor and have a certain level of details when referri= ng to experimental work. Your document fails to do so. =C2=A0=20 >>Right now, the draft reads more like propaganda than information: written= to bad mouth a protocol on the basis of biased/frivolous arguments.=20 >I am sorry that you see the draft that way. We have tried to be as objecti= ve as possible. Can you point out any concrete paragraph or section that yo= u see as "propaganda"? And honestly, I would have hoped that we can have an= objective, argumentative discussion on the mailing list, and not a dismiss= al of our arguments without any constructive discussion.=20 The problem is that the document is so biased that it is hard to see it any= other way. A section-by-section review of the document coming in a couple = of days.=20 >>Why would the authors completely ignore P2P-RPL even though it resolves m= any issues they have pointed out.=20 >1) Because P2P-RPL is not even an RFC yet, whereas RPL is, and is already = deployed.=20 So, you basically throw to dustbin 2+ years of hard work people have done o= n P2P-RPL? Even though it is designed to solve precisely the problems you h= ighlight in your document? Same goes for the compression problem. The worki= ng group spent so much time deliberating on the problem and how best to sol= ve it. But your document conveniently chose to ignore all that discussion. = At the very least, your document could have been complete by listing all th= e issues people pointed out.=20 >2) There is no dependency from RPL to P2P-RPPL, i.e., it should work stand= -alone. Then, no protocol should ever be extended. Each protocol must work well in = all possible scenarios. =20 >3) P2P-RPL is experimental, RPL is std. track.=20 So, P2P-RPL would never become standards track? >4) I thought that ROLL is chartered to provide routing solutions for extre= mely constrained devices (which was, I assume, one of the reasons to not co= nsider MANET work). One of our arguments in the draft is that RPL is very c= omplex (the specification alone plus necessary companion documents has seve= ral hundred pages). Adding P2P-RPL as necessity to mitigate some of the iss= ues would increase the code size even more.=20 Two points: 1. A long RFC does not necessarily mean a complex protocol. Do you need to = implement every thing in RPL RFC for a particular deployment? It would have= been much more useful if your document had identified the minimal set of R= PL features that MUST be present in each deployment. =C2=A0=20 2. If you had added 34 pages of P2P-RPL to 157 pages of RPL RFC, it would n= ot worsen the RPL's "complexity" too much. Would it? But then you would hav= e much less to complain about RPL in your document. >>There are numerous similar sins of omission spread throughout the documen= t.=20 >Where?=20 Some additional sins I pointed out above. Please wait for my detailed revie= w for a more complete list. =C2=A0=20 >>As a result, most conclusions the document reaches are open to doubt if n= ot outright incorrect.=20 >Is that proof by authority or a real argument? Please be more constructive= .=20 You reached the conclusions you reached based on incomplete arguments or by= generalizing things that you saw in specific implementations/deployments. = That is why these conclusions are doubtful. =C2=A0=20 >>Sure, RPL is not a perfect protocol - no protocol is. But this document i= s not an unbiased scientific analysis of the protocol.=20 >How do you come to that conclusion? We provide concrete, objective argumen= ts. I do not see that in your email.=20 Please see the previous comment. =C2=A0=20 >>As Pascal said, this document could have served a valuable constructive p= urpose. But, perhaps this was not the intention of the authors. This docume= nt should be recognized for what it is: a political document written to fur= ther a particular destructive agenda.=20 >I really don't know what to say to that non-constructive argument.=20 Rather than guiding a reader how to deploy RPL and avoid the potential pitf= alls, your message is that RPL is so fundamentally flawed that it should be= dumped altogether. This is any thing but constructive. Thanks Mukul =C2=A0=20 Thanks=20 Mukul=20 ----- Original Message -----=20 From: "C Chauvenet" < c.chauvenet@watteco.com >=20 To: "JP Vasseur" < jpv@cisco.com >=20 Cc: "roll WG" < roll@ietf.org >, "Michael Richardson" < mcr@sandelman.ca >= =20 Sent: Wednesday, May 16, 2012 9:13:56 AM=20 Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences=20 Hi,=20 I definitely agree that implementation feedback is always good to know, so = your experiences are welcomed.=20 I also think that problems investigations need a complete and exact view, s= o I would encourage you to put much more details about the scenario and the= environment where you experimentations took place.=20 For instance, I would enjoy a "RPL Implementation Description" section in y= ou draft listing the hardware your used, your RPL parameters, the RPL draft= s and mechanisms implemented, your OS etc...=20 If I read a paper with orthogonal observations with the same level of detai= ls as in your draft, then how could I forge my opinion ?=20 Looking at this draft, it seems that it gathers lots of previous discussion= s that occurred during the past year on various mailing lists, and IETF mee= tings.=20 Does your experimentations takes care about these recommendations ?=20 If not, does your draft mention the propositions that have been made to add= ress the problems you point out in your draft ?=20 I think it could be worth to leverage on these previous discussions.=20 Your draft is a list of Description and Observations.=20 Maybe you could add a "Resolution Proposal" section for each problem, gathe= ring previous discussion and your own proposals ?=20 Identifying what is wrong in your implementation is a good first step, but = the hardest part is to propose some corrections.=20 Best Regards,=20 C=C3=A9dric Chauvenet.=20 Le 16 mai 2012 =C3=A0 15:04, JP Vasseur a =C3=A9crit :=20 > Dear Thomas,=20 >=20 > On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote:=20 >=20 >> Dear JP and Michael,=20 >>=20 >> Thank you for your mail.=20 >>=20 >> On May 16, 2012, at 09:18 , JP Vasseur wrote:=20 >>=20 >>> Dear Thomas,=20 >>>=20 >>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote:=20 >>>=20 >>>> Dear JP, Michael, all=20 >>>>=20 >>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented a= nd discussed at the Paris meeting.=20 >>>>=20 >>>> The authors consider the document complete and "done", and are looking= to take it forward in the IETF=20 >>>> process for publication as "Informational RFC" in the very near future= .=20 >>>>=20 >>>> We would therefore like to ask the WG chairs, if the ROLL WG is willin= g to accept and progress this=20 >>>> document towards publication?=20 >>>=20 >>> Thanks for your suggestion. So far we haven't see a lot of discussion/i= nterest from the WG but your request is=20 >>> perfectly fair.=20 >>=20 >> Thank you - I aim to be fair.=20 >>=20 >>> So far there are no details on the scenarios and testing environments t= hat led to the issues that=20 >>> you reported, thus I would suggest you to first include them so that pe= ople interested could be able to reproduce=20 >>> it. Once the drat is updated, we'll be happy to pool the WG.=20 >>>=20 >>> Does that make sense ?=20 >>=20 >> Not really. Let me explain my disagreement.=20 >>=20 >> We tried RPL (and, I note, several different independent implementations= of RPL) in a number of different scenarios and deployments, and observed t= he behaviors exhibited - noting that what we observed across the different = implementations, scenarios and deployments was fairly universal.=20 >>=20 >> We then went back to the specification, to understand these behaviors in= detail, and understand their universality as independent from a specific s= cenario or deployment or implementation - but rather, as artifacts of the R= PL protocol design.=20 >>=20 >> We therefore believe that _any_ deployment, scenario or testing environm= ent of RPL needs to pay attention to the issues presented, and find a way o= f addressing them. The way of addressing these issues in a given deployment= or scenario would be appropriate for an "applicability statement" for that= deployment or scenario.=20 >=20 > JP> Thanks for the clarification; that being said, for the WG to make sur= e that nothing is "scenario" dependent and the outcome could indeed apply t= o all scenarios,=20 > it might be worth being more explicit. For example, you pointed out to th= e MTU issue, to which I mentioned that 15.4g would bring a solution, so you= may want to=20 > explain that you did not use 15.4g and there are a number of such example= s =E2=80=A6.=20 >=20 >>=20 >> (For example, a deployment using only L2s which provides guaranteed bi-d= irectional links =C2=A0for L3 would address this by in the applicability st= atement stating "As all L2-links are guaranteed bi-directional, this addres= ses the issues raised in section 9 in draft-clausen-lln-rpl-experiences".)= =20 >>=20 >> Thus, we believe that it would actually be misleading (not to mention, u= nnecessarily verbose) to put the "details on the scenarios and testing envi= ronments" into this I-D.=20 >>=20 >> Doing so would mislead the reader to believe that the issues presented o= nly manifest themselves in those precise scenarios - which definitely isn't= the case.=20 >=20 > JP> see the previous comment and tell us what you think; we could provide= other examples.=20 >=20 > Note that we do not oppose to asking to the WG; we just request you first= to add additional information to proceed forward.=20 >=20 > thanks.=20 >=20 > JP and Michael.=20 >=20 > JP.=20 >=20 >>=20 >> Best,=20 >>=20 >> Thomas=20 >>=20 >>> Thanks.=20 >>>=20 >>> JP and Michael.=20 >>>=20 >>>>=20 >>>> Best,=20 >>>>=20 >>>> Thomas, Ulrich, Yuichi, Jiazi and Axel=20 >>>=20 >>=20 >=20 > _______________________________________________=20 > Roll mailing list=20 > Roll@ietf.org=20 > https://www.ietf.org/mailman/listinfo/roll=20 >=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 From admin@ipv6it.org Wed May 16 11:39:09 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2E4721F869D for ; Wed, 16 May 2012 11:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.995 X-Spam-Level: X-Spam-Status: No, score=-4.995 tagged_above=-999 required=5 tests=[AWL=2.604, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kDKHZVJ-NUv for ; Wed, 16 May 2012 11:39:07 -0700 (PDT) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5B83621F86D1 for ; Wed, 16 May 2012 11:39:07 -0700 (PDT) Received: by bkty8 with SMTP id y8so1049783bkt.31 for ; Wed, 16 May 2012 11:39:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=6grDQtjjsFJ7vv6tBlKaAUJ7HYwECx1KFH9e421G2X4=; b=Ohrch7MCuqcbKRiHc13wbAM9csnf/OYzr8SpJXa/noZsHjC+McEsPgcnOcp+WU+X6A 9/PhxChzVVCivs4Q2RJ1tXsW2nQA6iNqP0ihvwCDp/cDkMYt0Jo6UmBj0/aZEzozPnhj mz6lfiQp1mH/wTldjEMPqXjb8AC9cDwqvp5Tf3Lhl/VFKgC2WpjZod5rgJhkRHmxk3uf 5xEb7Biqp6LOA8ttLYkP6zuSZlKPK7Om3hK5jBgzXG1YIc7ASunyy19thE8ftsU8MxjF zBfnGFYD+P+YGGuknZWo9qKrmesBbWW+AEHJPuernVVFyAgPRMiZciVwvj6ce55B2eaQ BMWQ== Received: by 10.204.156.213 with SMTP id y21mr1548428bkw.91.1337193546296; Wed, 16 May 2012 11:39:06 -0700 (PDT) Received: from [127.0.0.1] ([87.18.133.188]) by mx.google.com with ESMTPS id e20sm6956641bkw.3.2012.05.16.11.39.04 (version=SSLv3 cipher=OTHER); Wed, 16 May 2012 11:39:05 -0700 (PDT) Message-ID: <4FB3F442.3080404@ipv6it.org> Date: Wed, 16 May 2012 20:38:58 +0200 From: Federico Consoli User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Thomas Heide Clausen References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <22B18A3C-B327-4AD6-9D94-901CF225BE98@watteco.com> <0AA713FC-2C91-41E4-80BF-3DA3FF450324@thomasclausen.org> <4818180C-19D8-4C01-A65C-04DD47B9FCB2@watteco.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Gm-Message-State: ALoCoQn2XfSyS/i0zniwikc9QJhoILErMW7Gn7Om/jCJB0J1Sy1/6ZMWME7WsLTvWXmytceNYl2N Cc: Roll@ietf.org Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 18:39:09 -0000 Il 16/05/2012 19.37, Thomas Heide Clausen ha scritto: > Dear Cedric, > > On May 16, 2012, at 18:48 , C Chauvenet wrote: > >> Thomas, >> See inline, >> >> Le 16 mai 2012 à 17:08, Thomas Heide Clausen a écrit : >> >>> Dear Cedric, >>> >>> Thank you for your email. Comments below. >>> >>> On 16 May 2012, at 16:13, C Chauvenet wrote: >>> >>>> Hi, >>>> >>>> I definitely agree that implementation feedback is always good to know, so your experiences are welcomed. >>>> >>>> I also think that problems investigations need a complete and exact view, so I would encourage you to put much more details about the scenario and the environment where you experimentations took place. >>>> For instance, I would enjoy a "RPL Implementation Description" section in you draft listing the hardware your used, your RPL parameters, the RPL drafts and mechanisms implemented, your OS etc... >>> As I indicated to JP already: >>> >>> 1) this draft is not "just" based on a single scenario, environment or implementation >>> (and, therefore, not "just" based on a single test). >> Does it means that your run multiple scenarios ? >> That would be great. >> > As indicated elsewhere, yes. Although its details are immaterial to this discussion, > >>> 2) the observations that we made during the test_S_ served to make us look at the RPL >>> RFC again, to explain our observations and to generalize them from the written word >>> of that RFC. >>> >>> Therefore, I do not think that any such description would bring anything (other than entropy and delay) to the process. The RPL RFC and this I-D is more than sufficient. >>> >>> As to what features were implemented, that is easy to answer: the RPL RFC (except for security) to the letter and with the parameters suggested there, and OF0. However, even the parameters are immaterial for the observations listed in this I-D. >> I think we are progressing on the definition of your RPL implementation : could you also precise what part of the RPL spec you have implemented ? eg. What mode of Operation and why, what options did you choose to include in DIO messages, your metrics .... >> > 1) All the relevant details are included in the I-D > 2) Again, the observations in that I-D can be made from looking (now that we know what to look for) > in the RPL RFC > 3) The experiments only served to help us see "what to look for" in the RPL RFC. > 4) See also email that I recently sent to JP. Hi Thomas, I have a question about this part, in particular Chapter 13 and its observation. "The varying link quality in real-world environments results in frequent changes of the best parent, which triggers a reset of the Trickle timer and thus the emission of DIOs." 1) Why you reset trickle when you change preferred parent? RFC 6550 Section 8.3 does not say that the change of the preferred parent MUST be considered inconsistencies with respect to the Trickle timer. -- The scenario in the draft is: "69 RPL Routers (MSP430-based wireless sensor routers with IEEE 802.15.4, .. were positioned in a fixed grid topology." I think you miss the distance between nodes. Without the distance I can not know the number of neighbors of each node, then the parameter K could also be "infinite" or else very binding. However I think that conclusions like these (Section 13 - 13.1) depend on the type of scenario and it is very difficult to generalize. Federico >>>> If I read a paper with orthogonal observations with the same level of details as in your draft, then how could I forge my opinion ? >>> I'd suggest reading the indicated parts of the RPL RFC conjointly with this I-D. Again, the observations that we present in this I-D make exclusive reference to RPL, and not to a specific implementation or deployment. >>> >>>> Looking at this draft, it seems that it gathers lots of previous discussions that occurred during the past year on various mailing lists, and IETF meetings. >>>> >>>> Does your experimentations takes care about these recommendations ? >>> Again, the issues raised in this I-D are based on what can be observed from the RPL RFC. >>> >>> If there are additional considerations required (which you seem to indicate to be the case) which are not reflected in the RPL RFC, in order to overcome the issues raised, then that indeed should be a big problem for the IETF and for ROLL.... >> These recommendations were for the problems you pointed out in *Your* implementation. >> Of course if other implementers are facing to the same problems, they could rely on it, but I have not heard about similar problems outside your lab from now. > These are not implementation problems, these are artifacts from the RPL RFC design choices. > >>>> If not, does your draft mention the propositions that have been made to address the problems you point out in your draft ? >>>> I think it could be worth to leverage on these previous discussions. >>> I firmly disagree. The IETF and ROLL has published an RFC - that's what this I-D discusses. >>> >>> Discussing what may have been proposed in other media would be entirely out of scope. >> Again, this is not related to the RPL RFC but *your* implementation that received some guidance regarding its problems. >> The RPL RFC should not include tips for your implementation, but your implementation and your draft should pay attention to the tips given to you. >> > This has nothing to do with "tips for [my] implementation whatsoever. See examples I gave in reply to JP. > > >>>> Your draft is a list of Description and Observations. >>>> Maybe you could add a "Resolution Proposal" section for each problem, gathering previous discussion and your own proposals ? >>> Nope. That's not the objective of this I-D. >> That's too bad, this is what all readers of this draft are looking for ! > It would be great to have that, so please write such a draft, addressing the issues that this I-D has presented. > > I am personally a great fan also of interoperability reports (something which ROLL doesn't have either and which is not the point of this I-D either) > >> Without offense, saying "this is bad" without a better proposition seems like half-work ! >> And this is true for most of the discussion topics in life, far away from RPL ! >>> I would venture that if the WG is serious about applicability statements, then those applicability statements would be the place for discussion of "how this issue, raised in this I-D, is addressed or moot for a given deployment". >>> >>>> Identifying what is wrong in your implementation >>> Considering that these observations are not implementation-specific, but are directly on the RPL RFC, I venture the observations that there's nothing "wrong in my implementation" here. >>> >> As a general comment : RPL is a routing protocol targeted for a very wide application area. >> Some may think this is good because it covers a lot of needs. >> Some may think it is bad because it is wide and not specific enough for their application. >> Wathever your position, these two arguments are valid, this is all a matter of viewpoint and tradeoff. > I disagree here, Cedric, but this thread is not the place for that particular discussion. >> So, because RPL is wide enough for multiple application, you have to take some time to tune it correctly, according to your application. > I disagree here, Cedric, but this thread is not the place for that particular discussion. This I-D does *not* discuss a specific application or deployment, but merely reflects on RPL, as published by the ROLL working group. > >> One simple choice that every RPL implementers will ave to answer is : Use Storing or Non Storing Mode ? This is a fondamental design choice that cannot be made outside a scenario consideration. > I agree here. > > And, this I-D provides some observations - for example about storage requirements, and about requirements for all RPL routers in (for example, for storing node) the case that the DODAG root can fail and floating DODAGs created. > > This has nothing to do with a specific implementation, deployment, experiment, scenario or application, but is an artifact of a fundamental design choice made in RPL. > >> Be sure that there is no magic RPL tuning that works for all, but multiple fine RPL tuning for multiple applications. >> I honestly cannot believe in generic results given the incredibly variety of tuning that RPL can have. > This is, again, not a matter of "tuning of parameters" at all. That's not what the I-D describes, or aims at describing. > >> So my final position is that we disagree on the need of more details in your experiments. > I'm afraid that I disagree for this I-D. That's not the point of it, and I think that it is fairly clear in the I-D that it's not (as well as it is clear what the point is, and what the goals are for it) > > I think that it would be interesting to have another I-D describe parameter tunings etc for a given application. I would expect that to be part of what the applicability statements were supposed to do. It's, however, still not in this I-D that it should be done. > > Thomas > >> Cédric. >> >>> Thomas >>> >>> >>>> is a good first step, but the hardest part is to propose some corrections. >>>> Best Regards, >>>> >>>> Cédric Chauvenet. >>>> >>>> Le 16 mai 2012 à 15:04, JP Vasseur a écrit : >>>> >>>>> Dear Thomas, >>>>> >>>>> On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: >>>>> >>>>>> Dear JP and Michael, >>>>>> >>>>>> Thank you for your mail. >>>>>> >>>>>> On May 16, 2012, at 09:18 , JP Vasseur wrote: >>>>>> >>>>>>> Dear Thomas, >>>>>>> >>>>>>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>>>>>> >>>>>>>> Dear JP, Michael, all >>>>>>>> >>>>>>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented and discussed at the Paris meeting. >>>>>>>> >>>>>>>> The authors consider the document complete and "done", and are looking to take it forward in the IETF >>>>>>>> process for publication as "Informational RFC" in the very near future. >>>>>>>> >>>>>>>> We would therefore like to ask the WG chairs, if the ROLL WG is willing to accept and progress this >>>>>>>> document towards publication? >>>>>>> Thanks for your suggestion. So far we haven't see a lot of discussion/interest from the WG but your request is >>>>>>> perfectly fair. >>>>>> Thank you - I aim to be fair. >>>>>> >>>>>>> So far there are no details on the scenarios and testing environments that led to the issues that >>>>>>> you reported, thus I would suggest you to first include them so that people interested could be able to reproduce >>>>>>> it. Once the drat is updated, we'll be happy to pool the WG. >>>>>>> >>>>>>> Does that make sense ? >>>>>> Not really. Let me explain my disagreement. >>>>>> >>>>>> We tried RPL (and, I note, several different independent implementations of RPL) in a number of different scenarios and deployments, and observed the behaviors exhibited - noting that what we observed across the different implementations, scenarios and deployments was fairly universal. >>>>>> >>>>>> We then went back to the specification, to understand these behaviors in detail, and understand their universality as independent from a specific scenario or deployment or implementation - but rather, as artifacts of the RPL protocol design. >>>>>> >>>>>> We therefore believe that _any_ deployment, scenario or testing environment of RPL needs to pay attention to the issues presented, and find a way of addressing them. The way of addressing these issues in a given deployment or scenario would be appropriate for an "applicability statement" for that deployment or scenario. >>>>> JP> Thanks for the clarification; that being said, for the WG to make sure that nothing is "scenario" dependent and the outcome could indeed apply to all scenarios, >>>>> it might be worth being more explicit. For example, you pointed out to the MTU issue, to which I mentioned that 15.4g would bring a solution, so you may want to >>>>> explain that you did not use 15.4g and there are a number of such examples …. >>>>> >>>>>> (For example, a deployment using only L2s which provides guaranteed bi-directional links for L3 would address this by in the applicability statement stating "As all L2-links are guaranteed bi-directional, this addresses the issues raised in section 9 in draft-clausen-lln-rpl-experiences".) >>>>>> >>>>>> Thus, we believe that it would actually be misleading (not to mention, unnecessarily verbose) to put the "details on the scenarios and testing environments" into this I-D. >>>>>> >>>>>> Doing so would mislead the reader to believe that the issues presented only manifest themselves in those precise scenarios - which definitely isn't the case. >>>>> JP> see the previous comment and tell us what you think; we could provide other examples. >>>>> >>>>> Note that we do not oppose to asking to the WG; we just request you first to add additional information to proceed forward. >>>>> >>>>> thanks. >>>>> >>>>> JP and Michael. >>>>> >>>>> JP. >>>>> >>>>>> Best, >>>>>> >>>>>> Thomas >>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> JP and Michael. >>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>>>> _______________________________________________ >>>>> 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 Wed May 16 12:34:41 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F276921F86CF for ; Wed, 16 May 2012 12:34:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.965 X-Spam-Level: X-Spam-Status: No, score=-3.965 tagged_above=-999 required=5 tests=[AWL=1.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Baxh57J6L3p for ; Wed, 16 May 2012 12:34:39 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8FD21F85ED for ; Wed, 16 May 2012 12:34:39 -0700 (PDT) Received: by qcsq13 with SMTP id q13so923476qcs.31 for ; Wed, 16 May 2012 12:34:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=qGJbcwTK2mAZ1cQjOBC0OsQD0tE77hrwFIH2BpRllI4=; b=lyJDJzbXtvies2laAAGnUNbq/A4AJcdGmz6v3d+bIzQps3BZQfjQvnw4WadHrEZ4yG tL8ChxjxS2skgimmDD1nKSh04LJBN6DPAt++xzLn28tPAyIVOljnXmIX3AAs6CUqmpAT yCgZr0MKjwY0r5tKwdlXIqR0kHtpEOFhT3090= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=qGJbcwTK2mAZ1cQjOBC0OsQD0tE77hrwFIH2BpRllI4=; b=G4kTWuxIL1ht6IBTt2IW2Hm3gVZ9yztndp8I+3vaCUsNuhBDnRT6W4so9z+YzcE1OM VXpNyewpKzKHwZgMO5HgOtBjPGpGdnNPAm8mS7ByOw7NKokhzxyCYoUqFFk/sH/+DJZ6 oYsr+cToQk8FY2oiCJq0dxRsXQStSaB4GV0zOMamF+SzaW7A19FRAAS0dyvNPishrQ3v XZqZnT+ppBR0KtRgaQ8hglIz0dn8d/nzx91b0rNZ4ajZL3SlgxFyn401G2vc16ggifkL hLgQj9qntSEyoB7TX5MDjs3SulkhVR5R0MFuSrF66jc5xX2XQ11bwYwXHQZgWTuT93hq nKIw== MIME-Version: 1.0 Received: by 10.224.189.19 with SMTP id dc19mr11923597qab.76.1337196878884; Wed, 16 May 2012 12:34:38 -0700 (PDT) Received: by 10.229.229.75 with HTTP; Wed, 16 May 2012 12:34:37 -0700 (PDT) In-Reply-To: <1011855243.422503.1337192744447.JavaMail.root@mail17.pantherlink.uwm.edu> References: <1011855243.422503.1337192744447.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Wed, 16 May 2012 12:34:37 -0700 Message-ID: From: Ulrich Herberg To: Mukul Goyal Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQmLCDe9s4qqAkNKJ3T4oRXiwCaYBk23cHun8Pe2yCL8JZihUg5YvNgbr8nzritDFpjzxRzr Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 19:34:41 -0000 Mukul, On Wed, May 16, 2012 at 11:25 AM, Mukul Goyal wrote: > > >>Seriously, do the authors think that this document would pass the muste= r for publication in any decent academic journal? > > >I don't know since when that is any criteria for IETF work. Was it a cri= teria for the standardization of RPL itself? > > RPL is a protocol specification whereas your document is an analysis of i= ts performance. No, our draft is not a performance analysis, but outlines observations of the RPL RFC. > The performance analysis papers fall in academic domain No. The IETF is about engineering, not academic research. Our draft was submitted as Internet Draft to the IETF, and not as academic publication. > and must follow a certain rigor and have a certain level of details when = referring to experimental work. As Thomas noted, all the observations were directly based on the RPL RFC; the experiments only triggered the deeper investigation of the RPL RFC, and the observations described in our draft do not depend on a specific implementation. > Your document fails to do so. This is an assertion, not a constructive argument. > >>Right now, the draft reads more like propaganda than information: writt= en to bad mouth a protocol on the basis of biased/frivolous arguments. > > >I am sorry that you see the draft that way. We have tried to be as objec= tive as possible. Can you point out any concrete paragraph or section that = you see as "propaganda"? And honestly, I would have hoped that we can have = an objective, argumentative discussion on the mailing list, and not a dismi= ssal of our arguments without any constructive discussion. > > The problem is that the document is so biased that it is hard to see it a= ny other way. This is an assertion, not a constructive argument. > A section-by-section review of the document coming in a couple of days. Thank you, we appreciate that! > >>Why would the authors completely ignore P2P-RPL even though it resolves= many issues they have pointed out. > > >1) Because P2P-RPL is not even an RFC yet, whereas RPL is, and is alread= y deployed. > > So, you basically throw to dustbin 2+ years of hard work people have done= on P2P-RPL? That is not what I said. > Even though it is designed to solve precisely the problems you highlight = in your document? Does that mean you agree that the problems mentioned in our draft are accurate for RPL? In that case, I wonder why we need a companion document to solve these problems in the first place, and why they have not been solved in RPL. As written further down in this email, I would like to point out again that P2P-RPL is Experimental, and therefore "solving all the problems [we] highlight" in the Standards Tracks RPL document is only possible to a very limited degree. The P2P-RPL also does not officially "update" (in IETF terminology) RPL. > Same goes for the compression problem. The working group spent so much ti= me deliberating on the problem and how best to solve it. I would very much like to discuss how to solve it. Our observations are based on the RPL RFC (and other standards that are related); any previous discussions on mailing lists only is irrelevant for these observations. It would be very helpful if you pointed out concrete suggestions to the appropriate sections in our draft. > But your document conveniently chose to ignore all that discussion. At th= e very least, your document could have been complete by listing all the iss= ues people pointed out. Pointed out where? Our draft is based on the RPL standards, not previous discussions on mailing lists. > >2) There is no dependency from RPL to P2P-RPPL, i.e., it should work sta= nd-alone. > > Then, no protocol should ever be extended. Each protocol must work well i= n all possible scenarios. RPL is not "extended" by P2P-RPL. I don't see that the latter officially updates or obsoletes the RFC. That would be impossible anyway, since P2P-RPL is Experimental. > >3) P2P-RPL is experimental, RPL is std. track. > > So, P2P-RPL would never become standards track? I understood that the current understanding of the ROLL WG is that P2P-RPL is Experimental. It is, of course, possible to submit a new draft in some years with intended Std. Track to update/obsolete the Experimental version. But such a draft is not even planned, as far as I know. Looking at other WGs, that process usually takes between 5-10 years, for gaining enough experience before publishing a new document as std track. > >4) I thought that ROLL is chartered to provide routing solutions for ext= remely constrained devices (which was, I assume, one of the reasons to not = consider MANET work). One of our arguments in the draft is that RPL is very= complex (the specification alone plus necessary companion documents has se= veral hundred pages). Adding P2P-RPL as necessity to mitigate some of the i= ssues would increase the code size even more. > > Two points: > > 1. A long RFC does not necessarily mean a complex protocol. Well, not necessarily; but it may be an indication. > Do you need to implement every thing in RPL RFC for a particular deployme= nt? It would have been much more useful if your document had identified the= minimal set of RPL features that MUST be present in each deployment. I disagree. Such a recommendation should be made by the applicability statements. Our draft does not give recommendations for implementers in specific deployments, but describes general observations of RPL. > 2. If you had added 34 pages of P2P-RPL to 157 pages of RPL RFC, it would= not worsen the RPL's "complexity" too much. Would it? But then you would h= ave much less to complain about RPL in your document. First, see my argument above (P2P-RPL does not "update" the RPL specification, as Experimental draft). Then, there is not just the RPL RFC, but also other required (read: "normative") documents, which add to the already long RFC. I really thought that we are talking about extremely constrained devices, but it seems to me from your argument, that the devices are actually not that constrained, so that it does not really matter much whether to add another protocol. > >>There are numerous similar sins of omission spread throughout the docum= ent. > > >Where? > > Some additional sins I pointed out above. Please wait for my detailed rev= iew for a more complete list. Okay. > >>As a result, most conclusions the document reaches are open to doubt if= not outright incorrect. > > >Is that proof by authority or a real argument? Please be more constructi= ve. > > You reached the conclusions you reached based on incomplete arguments or = by generalizing things that you saw in specific implementations/deployments= . That is why these conclusions are doubtful. I disagree. These observations are based on the RPL RFC, and not on specific implementations or deployments. We have delivered concrete observations in the draft; just doubting them without counter-proof is not constructive. > >>Sure, RPL is not a perfect protocol - no protocol is. But this document= is not an unbiased scientific analysis of the protocol. > > >How do you come to that conclusion? We provide concrete, objective argum= ents. I do not see that in your email. > > Please see the previous comment. > > > >>As Pascal said, this document could have served a valuable constructive= purpose. But, perhaps this was not the intention of the authors. This docu= ment should be recognized for what it is: a political document written to f= urther a particular destructive agenda. > > > >I really don't know what to say to that non-constructive argument. > > Rather than guiding a reader how to deploy RPL and avoid the potential pi= tfalls, your message is that RPL is so fundamentally flawed that it should = be dumped altogether. This is any thing but constructive. I think we made it clear what our goals are (they are also described in the draft). Regards Ulrich > > > ----- Original Message ----- > From: "C Chauvenet" < c.chauvenet@watteco.com > > To: "JP Vasseur" < jpv@cisco.com > > Cc: "roll WG" < roll@ietf.org >, "Michael Richardson" < mcr@sandelman.ca = > > > Sent: Wednesday, May 16, 2012 9:13:56 AM > Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences > > > > Hi, > > I definitely agree that implementation feedback is always good to know, s= o your experiences are welcomed. > > I also think that problems investigations need a complete and exact view,= so I would encourage you to put much more details about the scenario and t= he environment where you experimentations took place. > For instance, I would enjoy a "RPL Implementation Description" section in= you draft listing the hardware your used, your RPL parameters, the RPL dra= fts and mechanisms implemented, your OS etc... > If I read a paper with orthogonal observations with the same level of det= ails as in your draft, then how could I forge my opinion ? > > Looking at this draft, it seems that it gathers lots of previous discussi= ons that occurred during the past year on various mailing lists, and IETF m= eetings. > > Does your experimentations takes care about these recommendations ? > If not, does your draft mention the propositions that have been made to a= ddress the problems you point out in your draft ? > I think it could be worth to leverage on these previous discussions. > > Your draft is a list of Description and Observations. > Maybe you could add a "Resolution Proposal" section for each problem, gat= hering previous discussion and your own proposals ? > Identifying what is wrong in your implementation is a good first step, bu= t the hardest part is to propose some corrections. > > Best Regards, > > C=E9dric Chauvenet. > > Le 16 mai 2012 =E0 15:04, JP Vasseur a =E9crit : > > > Dear Thomas, > > > > On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: > > > >> Dear JP and Michael, > >> > >> Thank you for your mail. > >> > >> On May 16, 2012, at 09:18 , JP Vasseur wrote: > >> > >>> Dear Thomas, > >>> > >>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: > >>> > >>>> Dear JP, Michael, all > >>>> > >>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was presented= and discussed at the Paris meeting. > >>>> > >>>> The authors consider the document complete and "done", and are looki= ng to take it forward in the IETF > >>>> process for publication as "Informational RFC" in the very near futu= re. > >>>> > >>>> We would therefore like to ask the WG chairs, if the ROLL WG is will= ing to accept and progress this > >>>> document towards publication? > >>> > >>> Thanks for your suggestion. So far we haven't see a lot of discussion= /interest from the WG but your request is > >>> perfectly fair. > >> > >> Thank you - I aim to be fair. > >> > >>> So far there are no details on the scenarios and testing environments= that led to the issues that > >>> you reported, thus I would suggest you to first include them so that = people interested could be able to reproduce > >>> it. Once the drat is updated, we'll be happy to pool the WG. > >>> > >>> Does that make sense ? > >> > >> Not really. Let me explain my disagreement. > >> > >> We tried RPL (and, I note, several different independent implementatio= ns of RPL) in a number of different scenarios and deployments, and observed= the behaviors exhibited - noting that what we observed across the differen= t implementations, scenarios and deployments was fairly universal. > >> > >> We then went back to the specification, to understand these behaviors = in detail, and understand their universality as independent from a specific= scenario or deployment or implementation - but rather, as artifacts of the= RPL protocol design. > >> > >> We therefore believe that _any_ deployment, scenario or testing enviro= nment of RPL needs to pay attention to the issues presented, and find a way= of addressing them. The way of addressing these issues in a given deployme= nt or scenario would be appropriate for an "applicability statement" for th= at deployment or scenario. > > > > JP> Thanks for the clarification; that being said, for the WG to make s= ure that nothing is "scenario" dependent and the outcome could indeed apply= to all scenarios, > > it might be worth being more explicit. For example, you pointed out to = the MTU issue, to which I mentioned that 15.4g would bring a solution, so y= ou may want to > > explain that you did not use 15.4g and there are a number of such examp= les =85. > > > >> > >> (For example, a deployment using only L2s which provides guaranteed bi= -directional links =A0for L3 would address this by in the applicability sta= tement stating "As all L2-links are guaranteed bi-directional, this address= es the issues raised in section 9 in draft-clausen-lln-rpl-experiences".) > >> > >> Thus, we believe that it would actually be misleading (not to mention,= unnecessarily verbose) to put the "details on the scenarios and testing en= vironments" into this I-D. > >> > >> Doing so would mislead the reader to believe that the issues presented= only manifest themselves in those precise scenarios - which definitely isn= 't the case. > > > > JP> see the previous comment and tell us what you think; we could provi= de other examples. > > > > Note that we do not oppose to asking to the WG; we just request you fir= st to add additional information to proceed forward. > > > > thanks. > > > > JP and Michael. > > > > JP. > > > >> > >> Best, > >> > >> Thomas > >> > >>> Thanks. > >>> > >>> JP and Michael. > >>> > >>>> > >>>> Best, > >>>> > >>>> Thomas, Ulrich, Yuichi, Jiazi and Axel > >>> > >> > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From cedric-2.lavenu@edf.fr Wed May 16 12:43:26 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A9821F86E5; Wed, 16 May 2012 12:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.334 X-Spam-Level: X-Spam-Status: No, score=-9.334 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, GB_I_INVITATION=-2, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OaCkSQc6dqk1; Wed, 16 May 2012 12:43:23 -0700 (PDT) Received: from mtagate2.edf.fr (mtagate2.edf.fr [192.54.193.62]) by ietfa.amsl.com (Postfix) with ESMTP id E2CBA21F8627; Wed, 16 May 2012 12:43:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.75,604,1330902000"; d="scan'208";a="129595891" Received: from unknown (HELO XHUB003AU.notes.edfgdf.fr) ([10.122.19.74]) by CLAF1MTA2.edf.fr with ESMTP; 16 May 2012 21:33:59 +0200 In-Reply-To: <1011855243.422503.1337192744447.JavaMail.root@mail17.pantherlink.uwm.edu> References: <1011855243.422503.1337192744447.JavaMail.root@mail17.pantherlink.uwm.edu> To: mukul@uwm.edu MIME-Version: 1.0 X-KeepSent: B3A451E3:58CCD380-C1257A00:0067A6CF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1FP5 SHF142 March 12, 2011 From: Cedric-2 LAVENU Message-ID: Date: Wed, 16 May 2012 21:43:11 +0200 Content-Type: multipart/alternative; boundary="=_alternative 006C539AC1257A00_=" Cc: roll-bounces@ietf.org, roll@ietf.org, mcr@sandelman.ca Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 19:43:26 -0000 Message en plusieurs parties au format MIME --=_alternative 006C539AC1257A00_= MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RGVhciBNdWt1bCwgYWxsLA0KDQpJIHRoaW5rIHRoYXQgdGhlIG1haW4gZ29hbCBvZiB0aGF0IGRv dW1lbnQgaXMgdG8gcmFpc2UgaXNzdWVzIHRoYXQgYXJlIA0KaW5oZXJlbnQgdG8gdGhlIFJQTCBS RkMuDQpJbiBteSBvcGluaW9uLCB0aGlzIEktRCBoYXMgYmVlbiBzdWJtaXR0ZWQgdG8gcmFpc2Ug c29tZSBjb25jZXJucyBhYm91dCANCnRoZSBvcGVyYXRpb24gb2YgUlBMLg0KQXMgaXQgaGFzIGJl ZW4gYnJvdWdodCB1cCBzZXZlcmFsIHRpbWVzLCBhcyBhbnkgb3RoZXIgcHJvdG9jb2wsIHRoZSBS UEwgDQpzcGVjaWZpY2F0aW9uIHdpbGwgZXZvbHZlIGluIG9yZGVyIHRvIHRha2UgaW50byBhY2Nv dW50IG9ic2VydmF0aW9ucyANCmxpc3RlZCBvdmVyIHRpbWUuDQoNCkFzIEpQIG1lbnRpb25lZCwg aXQgc2VlbXMgdGhhdCBjb25zdHJ1Y3RpdmUgd29yayBpcyBuZWVkZWQgd2l0aGluIFJPTEwgdG8g DQpmaXggdGhlIGlkZW50aWZpZWQgZ2FwcyBvZiB0aGUgY3VycmVudCBzcGVjLiBUaGUgcmVzcG9u c2UgdG8gdGhhdCBtYXkgYmUgDQp0aGUgYWRkaXRpb24gb2YgbmV3IG1lY2hhbmlzbXMgd2l0aGlu IGZ1dHVyZSB2ZXJzaW9ucyBvZiB0aGUgc3BlYywgb3IgYSANCmNsZWFyIHN0YXRlbWVudCBhYm91 dCB0aGUgbGltaXRhdGlvbnMgb2YgdGhlIHByb3RvY29sLg0KDQpGcm9tIHdoYXQgaGFzIGJlZW4g cHJldmlvdXNseSBzYWlkIG9uIHRoZSBtYWlsaW5nIGxpc3QsIEkgYWdyZWUgdGhhdCB0aW1lIA0K aGFzIHRvIGJlIGludmVzdGVkIHRvIHR1bmUgdGhlIHByb3RvY29sIGZvciBlYWNoIGRpZmZlcmVu dCBhcHBsaWNhdGlvbiANCmV0Yy4uLiBidXQgZnJvbSB3aGF0IEkgdW5kZXJzdGFuZCwgdHVuaW5n IGFuIGFscmVhZHkgZXhpc3Rpbmcgc2V0IG9mIA0KcGFyYW1ldGVycyB3aWxsIG5vdCBmaWxsIHRo ZSB0ZWNobmljYWwgZ2FwcyBvZiBhIHNwZWMuIEFzIGFuIGVuZC11c2VyIEknbSANCmV2ZW4gbW9y ZSBjb25jZXJuZWQgYWJvdXQgdGhhdCwgc2luY2UgZWFjaCB2ZW5kb3IgbWF5IGhhdmUgaXRzIG93 biB3YXkgdG8gDQpmaWxsIHRoZSBnYXBzIGFuZCB0byBtYWtlIHRoZSBwcm90b2NvbCB3b3JrIGlu IGEgcGFydGljdWxhciBlbnZpcm9ubWVudC4gDQpIb3dldmVyLCBpbnRlcm9wZXJhYmlsaXR5IGlz IG5vdCBndWFyYW50ZWVkLCB3aGljaCBpcyBhIG1ham9yIGNvbmNlcm4gZm9yIA0KZW5kLXVzZXJz IHRhcmdldGluZyBtYXNzaXZlIG11bHRpLXZlbmRvciByb2xsLW91dHMuDQoNCkkgdGhpbmsgaXQn cyBpbiB0aGUgc2NvcGUgb2YgdGhlIHdvcmtpbmcgZ3JvdXAgdG8gYWRkcmVzcyBlYWNoIHNpbmds ZSANCmNvbmNlcm4gaWRlbnRpZmllZCBpbiBvcmRlciB0byBhdm9pZCB0aGVzZSBpbnRlcm9wIGlz c3VlcyBpbiB0aGUgd2lkZXN0IA0KcG9zc2libGUgYXBwbGljYXRpb24gYXJlYS4NCg0KQmVzdCBy ZWdhcmRzLA0KQ8OpZHJpYw0KDQpyb2xsLWJvdW5jZXNAaWV0Zi5vcmcgYSDDqWNyaXQgc3VyIDE2 LzA1LzIwMTIgMjA6MjU6NDQgOg0KDQo+IG11a3VsQHV3bS5lZHUgDQo+IEVudm95w6kgcGFyIDog cm9sbC1ib3VuY2VzQGlldGYub3JnDQo+IA0KPiAxNi8wNS8yMDEyIDIwOjI1DQo+IA0KPiBBDQo+ IA0KPiB1bHJpY2hAaGVyYmVyZy5uYW1lDQo+IA0KPiBjYw0KPiANCj4gcm9sbEBpZXRmLm9yZywg bWNyQHNhbmRlbG1hbi5jYQ0KPiANCj4gT2JqZXQNCj4gDQo+IFJlOiBbUm9sbF0gV2F5IGZvcndh cmQgZm9yIGRyYWZ0LWNsYXVzZW4tbGxuLXJwbC1leHBlcmllbmNlcw0KPiANCj4gPj5TZXJpb3Vz bHksIGRvIHRoZSBhdXRob3JzIHRoaW5rIHRoYXQgdGhpcyBkb2N1bWVudCB3b3VsZCBwYXNzIHRo ZSANCj4gbXVzdGVyIGZvciBwdWJsaWNhdGlvbiBpbiBhbnkgZGVjZW50IGFjYWRlbWljIGpvdXJu YWw/IA0KPiANCj4gPkkgZG9uJ3Qga25vdyBzaW5jZSB3aGVuIHRoYXQgaXMgYW55IGNyaXRlcmlh IGZvciBJRVRGIHdvcmsuIFdhcyBpdCANCj4gYSBjcml0ZXJpYSBmb3IgdGhlIHN0YW5kYXJkaXph dGlvbiBvZiBSUEwgaXRzZWxmPyANCj4gDQo+IFJQTCBpcyBhIHByb3RvY29sIHNwZWNpZmljYXRp b24gd2hlcmVhcyB5b3VyIGRvY3VtZW50IGlzIGFuIGFuYWx5c2lzDQo+IG9mIGl0cyBwZXJmb3Jt YW5jZS4gVGhlIHBlcmZvcm1hbmNlIGFuYWx5c2lzIHBhcGVycyBmYWxsIGluIGFjYWRlbWljDQo+ IGRvbWFpbiBhbmQgbXVzdCBmb2xsb3cgYSBjZXJ0YWluIHJpZ29yIGFuZCBoYXZlIGEgY2VydGFp biBsZXZlbCBvZiANCj4gZGV0YWlscyB3aGVuIHJlZmVycmluZyB0byBleHBlcmltZW50YWwgd29y ay4gWW91ciBkb2N1bWVudCBmYWlscyB0byBkbyANCnNvLg0KPiANCj4gICANCj4gPj5SaWdodCBu b3csIHRoZSBkcmFmdCByZWFkcyBtb3JlIGxpa2UgcHJvcGFnYW5kYSB0aGFuIGluZm9ybWF0aW9u OiANCj4gd3JpdHRlbiB0byBiYWQgbW91dGggYSBwcm90b2NvbCBvbiB0aGUgYmFzaXMgb2YgYmlh c2VkL2ZyaXZvbG91cyANCmFyZ3VtZW50cy4gDQo+IA0KPiA+SSBhbSBzb3JyeSB0aGF0IHlvdSBz ZWUgdGhlIGRyYWZ0IHRoYXQgd2F5LiBXZSBoYXZlIHRyaWVkIHRvIGJlIGFzIA0KPiBvYmplY3Rp dmUgYXMgcG9zc2libGUuIENhbiB5b3UgcG9pbnQgb3V0IGFueSBjb25jcmV0ZSBwYXJhZ3JhcGgg b3IgDQo+IHNlY3Rpb24gdGhhdCB5b3Ugc2VlIGFzICJwcm9wYWdhbmRhIj8gQW5kIGhvbmVzdGx5 LCBJIHdvdWxkIGhhdmUgDQo+IGhvcGVkIHRoYXQgd2UgY2FuIGhhdmUgYW4gb2JqZWN0aXZlLCBh cmd1bWVudGF0aXZlIGRpc2N1c3Npb24gb24gdGhlDQo+IG1haWxpbmcgbGlzdCwgYW5kIG5vdCBh IGRpc21pc3NhbCBvZiBvdXIgYXJndW1lbnRzIHdpdGhvdXQgYW55IA0KPiBjb25zdHJ1Y3RpdmUg ZGlzY3Vzc2lvbi4gDQo+IA0KPiBUaGUgcHJvYmxlbSBpcyB0aGF0IHRoZSBkb2N1bWVudCBpcyBz byBiaWFzZWQgdGhhdCBpdCBpcyBoYXJkIHRvIHNlZQ0KPiBpdCBhbnkgb3RoZXIgd2F5LiBBIHNl Y3Rpb24tYnktc2VjdGlvbiByZXZpZXcgb2YgdGhlIGRvY3VtZW50IGNvbWluZw0KPiBpbiBhIGNv dXBsZSBvZiBkYXlzLiANCj4gDQo+ID4+V2h5IHdvdWxkIHRoZSBhdXRob3JzIGNvbXBsZXRlbHkg aWdub3JlIFAyUC1SUEwgZXZlbiB0aG91Z2ggaXQgDQo+IHJlc29sdmVzIG1hbnkgaXNzdWVzIHRo ZXkgaGF2ZSBwb2ludGVkIG91dC4gDQo+IA0KPiA+MSkgQmVjYXVzZSBQMlAtUlBMIGlzIG5vdCBl dmVuIGFuIFJGQyB5ZXQsIHdoZXJlYXMgUlBMIGlzLCBhbmQgaXMgDQo+IGFscmVhZHkgZGVwbG95 ZWQuIA0KPiANCj4gU28sIHlvdSBiYXNpY2FsbHkgdGhyb3cgdG8gZHVzdGJpbiAyKyB5ZWFycyBv ZiBoYXJkIHdvcmsgcGVvcGxlIGhhdmUNCj4gZG9uZSBvbiBQMlAtUlBMPyBFdmVuIHRob3VnaCBp dCBpcyBkZXNpZ25lZCB0byBzb2x2ZSBwcmVjaXNlbHkgdGhlIA0KPiBwcm9ibGVtcyB5b3UgaGln aGxpZ2h0IGluIHlvdXIgZG9jdW1lbnQ/IFNhbWUgZ29lcyBmb3IgdGhlIA0KPiBjb21wcmVzc2lv biBwcm9ibGVtLiBUaGUgd29ya2luZyBncm91cCBzcGVudCBzbyBtdWNoIHRpbWUgDQo+IGRlbGli ZXJhdGluZyBvbiB0aGUgcHJvYmxlbSBhbmQgaG93IGJlc3QgdG8gc29sdmUgaXQuIEJ1dCB5b3Vy IA0KPiBkb2N1bWVudCBjb252ZW5pZW50bHkgY2hvc2UgdG8gaWdub3JlIGFsbCB0aGF0IGRpc2N1 c3Npb24uIEF0IHRoZSANCj4gdmVyeSBsZWFzdCwgeW91ciBkb2N1bWVudCBjb3VsZCBoYXZlIGJl ZW4gY29tcGxldGUgYnkgbGlzdGluZyBhbGwgDQo+IHRoZSBpc3N1ZXMgcGVvcGxlIHBvaW50ZWQg b3V0LiANCj4gDQo+ID4yKSBUaGVyZSBpcyBubyBkZXBlbmRlbmN5IGZyb20gUlBMIHRvIFAyUC1S UFBMLCBpLmUuLCBpdCBzaG91bGQgDQo+IHdvcmsgc3RhbmQtYWxvbmUuDQo+IA0KPiBUaGVuLCBu byBwcm90b2NvbCBzaG91bGQgZXZlciBiZSBleHRlbmRlZC4gRWFjaCBwcm90b2NvbCBtdXN0IHdv cmsgDQo+IHdlbGwgaW4gYWxsIHBvc3NpYmxlIHNjZW5hcmlvcy4NCj4gDQo+ID4zKSBQMlAtUlBM IGlzIGV4cGVyaW1lbnRhbCwgUlBMIGlzIHN0ZC4gdHJhY2suIA0KPiANCj4gU28sIFAyUC1SUEwg d291bGQgbmV2ZXIgYmVjb21lIHN0YW5kYXJkcyB0cmFjaz8NCj4gDQo+ID40KSBJIHRob3VnaHQg dGhhdCBST0xMIGlzIGNoYXJ0ZXJlZCB0byBwcm92aWRlIHJvdXRpbmcgc29sdXRpb25zIA0KPiBm b3IgZXh0cmVtZWx5IGNvbnN0cmFpbmVkIGRldmljZXMgKHdoaWNoIHdhcywgSSBhc3N1bWUsIG9u ZSBvZiB0aGUgDQo+IHJlYXNvbnMgdG8gbm90IGNvbnNpZGVyIE1BTkVUIHdvcmspLiBPbmUgb2Yg b3VyIGFyZ3VtZW50cyBpbiB0aGUgDQo+IGRyYWZ0IGlzIHRoYXQgUlBMIGlzIHZlcnkgY29tcGxl eCAodGhlIHNwZWNpZmljYXRpb24gYWxvbmUgcGx1cyANCj4gbmVjZXNzYXJ5IGNvbXBhbmlvbiBk b2N1bWVudHMgaGFzIHNldmVyYWwgaHVuZHJlZCBwYWdlcykuIEFkZGluZyANCj4gUDJQLVJQTCBh cyBuZWNlc3NpdHkgdG8gbWl0aWdhdGUgc29tZSBvZiB0aGUgaXNzdWVzIHdvdWxkIGluY3JlYXNl IA0KPiB0aGUgY29kZSBzaXplIGV2ZW4gbW9yZS4gDQo+IA0KPiBUd28gcG9pbnRzOg0KPiANCj4g MS4gQSBsb25nIFJGQyBkb2VzIG5vdCBuZWNlc3NhcmlseSBtZWFuIGEgY29tcGxleCBwcm90b2Nv bC4gRG8geW91IA0KPiBuZWVkIHRvIGltcGxlbWVudCBldmVyeSB0aGluZyBpbiBSUEwgUkZDIGZv ciBhIHBhcnRpY3VsYXIgDQo+IGRlcGxveW1lbnQ/IEl0IHdvdWxkIGhhdmUgYmVlbiBtdWNoIG1v cmUgdXNlZnVsIGlmIHlvdXIgZG9jdW1lbnQgaGFkDQo+IGlkZW50aWZpZWQgdGhlIG1pbmltYWwg c2V0IG9mIFJQTCBmZWF0dXJlcyB0aGF0IE1VU1QgYmUgcHJlc2VudCBpbiANCj4gZWFjaCBkZXBs b3ltZW50LiAgICANCj4gDQo+IDIuIElmIHlvdSBoYWQgYWRkZWQgMzQgcGFnZXMgb2YgUDJQLVJQ TCB0byAxNTcgcGFnZXMgb2YgUlBMIFJGQywgaXQgDQo+IHdvdWxkIG5vdCB3b3JzZW4gdGhlIFJQ TCdzICJjb21wbGV4aXR5IiB0b28gbXVjaC4gV291bGQgaXQ/IEJ1dCB0aGVuDQo+IHlvdSB3b3Vs ZCBoYXZlIG11Y2ggbGVzcyB0byBjb21wbGFpbiBhYm91dCBSUEwgaW4geW91ciBkb2N1bWVudC4N Cj4gDQo+ID4+VGhlcmUgYXJlIG51bWVyb3VzIHNpbWlsYXIgc2lucyBvZiBvbWlzc2lvbiBzcHJl YWQgdGhyb3VnaG91dCB0aGUgDQpkb2N1bWVudC4gDQo+IA0KPiA+V2hlcmU/IA0KPiANCj4gU29t ZSBhZGRpdGlvbmFsIHNpbnMgSSBwb2ludGVkIG91dCBhYm92ZS4gUGxlYXNlIHdhaXQgZm9yIG15 IA0KPiBkZXRhaWxlZCByZXZpZXcgZm9yIGEgbW9yZSBjb21wbGV0ZSBsaXN0Lg0KPiAgIA0KPiAN Cj4gPj5BcyBhIHJlc3VsdCwgbW9zdCBjb25jbHVzaW9ucyB0aGUgZG9jdW1lbnQgcmVhY2hlcyBh cmUgb3BlbiB0byANCj4gZG91YnQgaWYgbm90IG91dHJpZ2h0IGluY29ycmVjdC4gDQo+IA0KPiA+ SXMgdGhhdCBwcm9vZiBieSBhdXRob3JpdHkgb3IgYSByZWFsIGFyZ3VtZW50PyBQbGVhc2UgYmUg bW9yZSANCmNvbnN0cnVjdGl2ZS4gDQo+IA0KPiBZb3UgcmVhY2hlZCB0aGUgY29uY2x1c2lvbnMg eW91IHJlYWNoZWQgYmFzZWQgb24gaW5jb21wbGV0ZSANCj4gYXJndW1lbnRzIG9yIGJ5IGdlbmVy YWxpemluZyB0aGluZ3MgdGhhdCB5b3Ugc2F3IGluIHNwZWNpZmljIA0KPiBpbXBsZW1lbnRhdGlv bnMvZGVwbG95bWVudHMuIFRoYXQgaXMgd2h5IHRoZXNlIGNvbmNsdXNpb25zIGFyZSBkb3VidGZ1 bC4NCj4gICANCj4gDQo+ID4+U3VyZSwgUlBMIGlzIG5vdCBhIHBlcmZlY3QgcHJvdG9jb2wgLSBu byBwcm90b2NvbCBpcy4gQnV0IHRoaXMgDQo+IGRvY3VtZW50IGlzIG5vdCBhbiB1bmJpYXNlZCBz Y2llbnRpZmljIGFuYWx5c2lzIG9mIHRoZSBwcm90b2NvbC4gDQo+IA0KPiA+SG93IGRvIHlvdSBj b21lIHRvIHRoYXQgY29uY2x1c2lvbj8gV2UgcHJvdmlkZSBjb25jcmV0ZSwgb2JqZWN0aXZlIA0K PiBhcmd1bWVudHMuIEkgZG8gbm90IHNlZSB0aGF0IGluIHlvdXIgZW1haWwuIA0KPiANCj4gUGxl YXNlIHNlZSB0aGUgcHJldmlvdXMgY29tbWVudC4NCj4gICANCj4gDQo+ID4+QXMgUGFzY2FsIHNh aWQsIHRoaXMgZG9jdW1lbnQgY291bGQgaGF2ZSBzZXJ2ZWQgYSB2YWx1YWJsZSANCj4gY29uc3Ry dWN0aXZlIHB1cnBvc2UuIEJ1dCwgcGVyaGFwcyB0aGlzIHdhcyBub3QgdGhlIGludGVudGlvbiBv ZiB0aGUNCj4gYXV0aG9ycy4gVGhpcyBkb2N1bWVudCBzaG91bGQgYmUgcmVjb2duaXplZCBmb3Ig d2hhdCBpdCBpczogYSANCj4gcG9saXRpY2FsIGRvY3VtZW50IHdyaXR0ZW4gdG8gZnVydGhlciBh IHBhcnRpY3VsYXIgZGVzdHJ1Y3RpdmUgYWdlbmRhLiANCj4gDQo+IA0KPiA+SSByZWFsbHkgZG9u J3Qga25vdyB3aGF0IHRvIHNheSB0byB0aGF0IG5vbi1jb25zdHJ1Y3RpdmUgYXJndW1lbnQuIA0K PiANCj4gUmF0aGVyIHRoYW4gZ3VpZGluZyBhIHJlYWRlciBob3cgdG8gZGVwbG95IFJQTCBhbmQg YXZvaWQgdGhlIA0KPiBwb3RlbnRpYWwgcGl0ZmFsbHMsIHlvdXIgbWVzc2FnZSBpcyB0aGF0IFJQ TCBpcyBzbyBmdW5kYW1lbnRhbGx5IA0KPiBmbGF3ZWQgdGhhdCBpdCBzaG91bGQgYmUgZHVtcGVk IGFsdG9nZXRoZXIuIFRoaXMgaXMgYW55IHRoaW5nIGJ1dCANCj4gY29uc3RydWN0aXZlLg0KPiAN Cj4gVGhhbmtzDQo+IE11a3VsDQo+ICAgDQo+IA0KPiANCj4gVGhhbmtzIA0KPiBNdWt1bCANCj4g DQo+IA0KPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KPiBGcm9tOiAiQyBDaGF1dmVu ZXQiIDwgYy5jaGF1dmVuZXRAd2F0dGVjby5jb20gPiANCj4gVG86ICJKUCBWYXNzZXVyIiA8IGpw dkBjaXNjby5jb20gPiANCj4gQ2M6ICJyb2xsIFdHIiA8IHJvbGxAaWV0Zi5vcmcgPiwgIk1pY2hh ZWwgUmljaGFyZHNvbiIgPCBtY3JAc2FuZGVsbWFuLmNhIA0KPiANCj4gDQo+IFNlbnQ6IFdlZG5l c2RheSwgTWF5IDE2LCAyMDEyIDk6MTM6NTYgQU0gDQo+IFN1YmplY3Q6IFJlOiBbUm9sbF0gV2F5 IGZvcndhcmQgZm9yIGRyYWZ0LWNsYXVzZW4tbGxuLXJwbC1leHBlcmllbmNlcyANCj4gDQo+IA0K PiANCj4gSGksIA0KPiANCj4gSSBkZWZpbml0ZWx5IGFncmVlIHRoYXQgaW1wbGVtZW50YXRpb24g ZmVlZGJhY2sgaXMgYWx3YXlzIGdvb2QgdG8gDQo+IGtub3csIHNvIHlvdXIgZXhwZXJpZW5jZXMg YXJlIHdlbGNvbWVkLiANCj4gDQo+IEkgYWxzbyB0aGluayB0aGF0IHByb2JsZW1zIGludmVzdGln YXRpb25zIG5lZWQgYSBjb21wbGV0ZSBhbmQgZXhhY3QgDQo+IHZpZXcsIHNvIEkgd291bGQgZW5j b3VyYWdlIHlvdSB0byBwdXQgbXVjaCBtb3JlIGRldGFpbHMgYWJvdXQgdGhlIA0KPiBzY2VuYXJp byBhbmQgdGhlIGVudmlyb25tZW50IHdoZXJlIHlvdSBleHBlcmltZW50YXRpb25zIHRvb2sgcGxh Y2UuIA0KPiBGb3IgaW5zdGFuY2UsIEkgd291bGQgZW5qb3kgYSAiUlBMIEltcGxlbWVudGF0aW9u IERlc2NyaXB0aW9uIiANCj4gc2VjdGlvbiBpbiB5b3UgZHJhZnQgbGlzdGluZyB0aGUgaGFyZHdh cmUgeW91ciB1c2VkLCB5b3VyIFJQTCANCj4gcGFyYW1ldGVycywgdGhlIFJQTCBkcmFmdHMgYW5k IG1lY2hhbmlzbXMgaW1wbGVtZW50ZWQsIHlvdXIgT1MgZXRjLi4uIA0KPiBJZiBJIHJlYWQgYSBw YXBlciB3aXRoIG9ydGhvZ29uYWwgb2JzZXJ2YXRpb25zIHdpdGggdGhlIHNhbWUgbGV2ZWwgDQo+ IG9mIGRldGFpbHMgYXMgaW4geW91ciBkcmFmdCwgdGhlbiBob3cgY291bGQgSSBmb3JnZSBteSBv cGluaW9uID8gDQo+IA0KPiBMb29raW5nIGF0IHRoaXMgZHJhZnQsIGl0IHNlZW1zIHRoYXQgaXQg Z2F0aGVycyBsb3RzIG9mIHByZXZpb3VzIA0KPiBkaXNjdXNzaW9ucyB0aGF0IG9jY3VycmVkIGR1 cmluZyB0aGUgcGFzdCB5ZWFyIG9uIHZhcmlvdXMgbWFpbGluZyANCj4gbGlzdHMsIGFuZCBJRVRG IG1lZXRpbmdzLiANCj4gDQo+IERvZXMgeW91ciBleHBlcmltZW50YXRpb25zIHRha2VzIGNhcmUg YWJvdXQgdGhlc2UgcmVjb21tZW5kYXRpb25zID8gDQo+IElmIG5vdCwgZG9lcyB5b3VyIGRyYWZ0 IG1lbnRpb24gdGhlIHByb3Bvc2l0aW9ucyB0aGF0IGhhdmUgYmVlbiBtYWRlDQo+IHRvIGFkZHJl c3MgdGhlIHByb2JsZW1zIHlvdSBwb2ludCBvdXQgaW4geW91ciBkcmFmdCA/IA0KPiBJIHRoaW5r IGl0IGNvdWxkIGJlIHdvcnRoIHRvIGxldmVyYWdlIG9uIHRoZXNlIHByZXZpb3VzIGRpc2N1c3Np b25zLiANCj4gDQo+IFlvdXIgZHJhZnQgaXMgYSBsaXN0IG9mIERlc2NyaXB0aW9uIGFuZCBPYnNl cnZhdGlvbnMuIA0KPiBNYXliZSB5b3UgY291bGQgYWRkIGEgIlJlc29sdXRpb24gUHJvcG9zYWwi IHNlY3Rpb24gZm9yIGVhY2ggDQo+IHByb2JsZW0sIGdhdGhlcmluZyBwcmV2aW91cyBkaXNjdXNz aW9uIGFuZCB5b3VyIG93biBwcm9wb3NhbHMgPyANCj4gSWRlbnRpZnlpbmcgd2hhdCBpcyB3cm9u ZyBpbiB5b3VyIGltcGxlbWVudGF0aW9uIGlzIGEgZ29vZCBmaXJzdCANCj4gc3RlcCwgYnV0IHRo ZSBoYXJkZXN0IHBhcnQgaXMgdG8gcHJvcG9zZSBzb21lIGNvcnJlY3Rpb25zLiANCj4gDQo+IEJl c3QgUmVnYXJkcywgDQo+IA0KPiBDw6lkcmljIENoYXV2ZW5ldC4gDQo+IA0KPiBMZSAxNiBtYWkg MjAxMiDDoCAxNTowNCwgSlAgVmFzc2V1ciBhIMOpY3JpdCA6IA0KPiANCj4gPiBEZWFyIFRob21h cywgDQo+ID4gDQo+ID4gT24gTWF5IDE2LCAyMDEyLCBhdCAyOjA4IFBNLCBUaG9tYXMgSGVpZGUg Q2xhdXNlbiB3cm90ZTogDQo+ID4gDQo+ID4+IERlYXIgSlAgYW5kIE1pY2hhZWwsIA0KPiA+PiAN Cj4gPj4gVGhhbmsgeW91IGZvciB5b3VyIG1haWwuIA0KPiA+PiANCj4gPj4gT24gTWF5IDE2LCAy MDEyLCBhdCAwOToxOCAsIEpQIFZhc3NldXIgd3JvdGU6IA0KPiA+PiANCj4gPj4+IERlYXIgVGhv bWFzLCANCj4gPj4+IA0KPiA+Pj4gT24gTWF5IDExLCAyMDEyLCBhdCA4OjI1IEFNLCBUaG9tYXMg SGVpZGUgQ2xhdXNlbiB3cm90ZTogDQo+ID4+PiANCj4gPj4+PiBEZWFyIEpQLCBNaWNoYWVsLCBh bGwgDQo+ID4+Pj4gDQo+ID4+Pj4gVXBvbiBKUHMgaW52aXRhdGlvbiwgZHJhZnQtY2xhdXNlbi1s bG4tcnBsLWV4cGVyaWVuY2VzIHdhcyANCj4gcHJlc2VudGVkIGFuZCBkaXNjdXNzZWQgYXQgdGhl IFBhcmlzIG1lZXRpbmcuIA0KPiA+Pj4+IA0KPiA+Pj4+IFRoZSBhdXRob3JzIGNvbnNpZGVyIHRo ZSBkb2N1bWVudCBjb21wbGV0ZSBhbmQgImRvbmUiLCBhbmQgYXJlIA0KPiBsb29raW5nIHRvIHRh a2UgaXQgZm9yd2FyZCBpbiB0aGUgSUVURiANCj4gPj4+PiBwcm9jZXNzIGZvciBwdWJsaWNhdGlv biBhcyAiSW5mb3JtYXRpb25hbCBSRkMiIGluIHRoZSB2ZXJ5IG5lYXIgDQpmdXR1cmUuIA0KPiA+ Pj4+IA0KPiA+Pj4+IFdlIHdvdWxkIHRoZXJlZm9yZSBsaWtlIHRvIGFzayB0aGUgV0cgY2hhaXJz LCBpZiB0aGUgUk9MTCBXRyBpcw0KPiB3aWxsaW5nIHRvIGFjY2VwdCBhbmQgcHJvZ3Jlc3MgdGhp cyANCj4gPj4+PiBkb2N1bWVudCB0b3dhcmRzIHB1YmxpY2F0aW9uPyANCj4gPj4+IA0KPiA+Pj4g VGhhbmtzIGZvciB5b3VyIHN1Z2dlc3Rpb24uIFNvIGZhciB3ZSBoYXZlbid0IHNlZSBhIGxvdCBv ZiANCj4gZGlzY3Vzc2lvbi9pbnRlcmVzdCBmcm9tIHRoZSBXRyBidXQgeW91ciByZXF1ZXN0IGlz IA0KPiA+Pj4gcGVyZmVjdGx5IGZhaXIuIA0KPiA+PiANCj4gPj4gVGhhbmsgeW91IC0gSSBhaW0g dG8gYmUgZmFpci4gDQo+ID4+IA0KPiA+Pj4gU28gZmFyIHRoZXJlIGFyZSBubyBkZXRhaWxzIG9u IHRoZSBzY2VuYXJpb3MgYW5kIHRlc3RpbmcgDQo+IGVudmlyb25tZW50cyB0aGF0IGxlZCB0byB0 aGUgaXNzdWVzIHRoYXQgDQo+ID4+PiB5b3UgcmVwb3J0ZWQsIHRodXMgSSB3b3VsZCBzdWdnZXN0 IHlvdSB0byBmaXJzdCBpbmNsdWRlIHRoZW0gc28gDQo+IHRoYXQgcGVvcGxlIGludGVyZXN0ZWQg Y291bGQgYmUgYWJsZSB0byByZXByb2R1Y2UgDQo+ID4+PiBpdC4gT25jZSB0aGUgZHJhdCBpcyB1 cGRhdGVkLCB3ZSdsbCBiZSBoYXBweSB0byBwb29sIHRoZSBXRy4gDQo+ID4+PiANCj4gPj4+IERv ZXMgdGhhdCBtYWtlIHNlbnNlID8gDQo+ID4+IA0KPiA+PiBOb3QgcmVhbGx5LiBMZXQgbWUgZXhw bGFpbiBteSBkaXNhZ3JlZW1lbnQuIA0KPiA+PiANCj4gPj4gV2UgdHJpZWQgUlBMIChhbmQsIEkg bm90ZSwgc2V2ZXJhbCBkaWZmZXJlbnQgaW5kZXBlbmRlbnQgDQo+IGltcGxlbWVudGF0aW9ucyBv ZiBSUEwpIGluIGEgbnVtYmVyIG9mIGRpZmZlcmVudCBzY2VuYXJpb3MgYW5kIA0KPiBkZXBsb3lt ZW50cywgYW5kIG9ic2VydmVkIHRoZSBiZWhhdmlvcnMgZXhoaWJpdGVkIC0gbm90aW5nIHRoYXQg d2hhdA0KPiB3ZSBvYnNlcnZlZCBhY3Jvc3MgdGhlIGRpZmZlcmVudCBpbXBsZW1lbnRhdGlvbnMs IHNjZW5hcmlvcyBhbmQgDQo+IGRlcGxveW1lbnRzIHdhcyBmYWlybHkgdW5pdmVyc2FsLiANCj4g Pj4gDQo+ID4+IFdlIHRoZW4gd2VudCBiYWNrIHRvIHRoZSBzcGVjaWZpY2F0aW9uLCB0byB1bmRl cnN0YW5kIHRoZXNlIA0KPiBiZWhhdmlvcnMgaW4gZGV0YWlsLCBhbmQgdW5kZXJzdGFuZCB0aGVp ciB1bml2ZXJzYWxpdHkgYXMgDQo+IGluZGVwZW5kZW50IGZyb20gYSBzcGVjaWZpYyBzY2VuYXJp byBvciBkZXBsb3ltZW50IG9yIGltcGxlbWVudGF0aW9uDQo+IC0gYnV0IHJhdGhlciwgYXMgYXJ0 aWZhY3RzIG9mIHRoZSBSUEwgcHJvdG9jb2wgZGVzaWduLiANCj4gPj4gDQo+ID4+IFdlIHRoZXJl Zm9yZSBiZWxpZXZlIHRoYXQgX2FueV8gZGVwbG95bWVudCwgc2NlbmFyaW8gb3IgdGVzdGluZyAN Cj4gZW52aXJvbm1lbnQgb2YgUlBMIG5lZWRzIHRvIHBheSBhdHRlbnRpb24gdG8gdGhlIGlzc3Vl cyBwcmVzZW50ZWQsIA0KPiBhbmQgZmluZCBhIHdheSBvZiBhZGRyZXNzaW5nIHRoZW0uIFRoZSB3 YXkgb2YgYWRkcmVzc2luZyB0aGVzZSANCj4gaXNzdWVzIGluIGEgZ2l2ZW4gZGVwbG95bWVudCBv ciBzY2VuYXJpbyB3b3VsZCBiZSBhcHByb3ByaWF0ZSBmb3IgYW4NCj4gImFwcGxpY2FiaWxpdHkg c3RhdGVtZW50IiBmb3IgdGhhdCBkZXBsb3ltZW50IG9yIHNjZW5hcmlvLiANCj4gPiANCj4gPiBK UD4gVGhhbmtzIGZvciB0aGUgY2xhcmlmaWNhdGlvbjsgdGhhdCBiZWluZyBzYWlkLCBmb3IgdGhl IFdHIHRvIA0KPiBtYWtlIHN1cmUgdGhhdCBub3RoaW5nIGlzICJzY2VuYXJpbyIgZGVwZW5kZW50 IGFuZCB0aGUgb3V0Y29tZSBjb3VsZA0KPiBpbmRlZWQgYXBwbHkgdG8gYWxsIHNjZW5hcmlvcywg DQo+ID4gaXQgbWlnaHQgYmUgd29ydGggYmVpbmcgbW9yZSBleHBsaWNpdC4gRm9yIGV4YW1wbGUs IHlvdSBwb2ludGVkIA0KPiBvdXQgdG8gdGhlIE1UVSBpc3N1ZSwgdG8gd2hpY2ggSSBtZW50aW9u ZWQgdGhhdCAxNS40ZyB3b3VsZCBicmluZyBhIA0KPiBzb2x1dGlvbiwgc28geW91IG1heSB3YW50 IHRvIA0KPiA+IGV4cGxhaW4gdGhhdCB5b3UgZGlkIG5vdCB1c2UgMTUuNGcgYW5kIHRoZXJlIGFy ZSBhIG51bWJlciBvZiBzdWNoIA0KPiBleGFtcGxlcyDigKYuIA0KPiA+IA0KPiA+PiANCj4gPj4g KEZvciBleGFtcGxlLCBhIGRlcGxveW1lbnQgdXNpbmcgb25seSBMMnMgd2hpY2ggcHJvdmlkZXMg DQo+IGd1YXJhbnRlZWQgYmktZGlyZWN0aW9uYWwgbGlua3MgIGZvciBMMyB3b3VsZCBhZGRyZXNz IHRoaXMgYnkgaW4gdGhlDQo+IGFwcGxpY2FiaWxpdHkgc3RhdGVtZW50IHN0YXRpbmcgIkFzIGFs bCBMMi1saW5rcyBhcmUgZ3VhcmFudGVlZCBiaS0NCj4gZGlyZWN0aW9uYWwsIHRoaXMgYWRkcmVz c2VzIHRoZSBpc3N1ZXMgcmFpc2VkIGluIHNlY3Rpb24gOSBpbiBkcmFmdC0NCj4gY2xhdXNlbi1s bG4tcnBsLWV4cGVyaWVuY2VzIi4pIA0KPiA+PiANCj4gPj4gVGh1cywgd2UgYmVsaWV2ZSB0aGF0 IGl0IHdvdWxkIGFjdHVhbGx5IGJlIG1pc2xlYWRpbmcgKG5vdCB0byANCj4gbWVudGlvbiwgdW5u ZWNlc3NhcmlseSB2ZXJib3NlKSB0byBwdXQgdGhlICJkZXRhaWxzIG9uIHRoZSBzY2VuYXJpb3MN Cj4gYW5kIHRlc3RpbmcgZW52aXJvbm1lbnRzIiBpbnRvIHRoaXMgSS1ELiANCj4gPj4gDQo+ID4+ IERvaW5nIHNvIHdvdWxkIG1pc2xlYWQgdGhlIHJlYWRlciB0byBiZWxpZXZlIHRoYXQgdGhlIGlz c3VlcyANCj4gcHJlc2VudGVkIG9ubHkgbWFuaWZlc3QgdGhlbXNlbHZlcyBpbiB0aG9zZSBwcmVj aXNlIHNjZW5hcmlvcyAtIA0KPiB3aGljaCBkZWZpbml0ZWx5IGlzbid0IHRoZSBjYXNlLiANCj4g PiANCj4gPiBKUD4gc2VlIHRoZSBwcmV2aW91cyBjb21tZW50IGFuZCB0ZWxsIHVzIHdoYXQgeW91 IHRoaW5rOyB3ZSBjb3VsZCANCj4gcHJvdmlkZSBvdGhlciBleGFtcGxlcy4gDQo+ID4gDQo+ID4g Tm90ZSB0aGF0IHdlIGRvIG5vdCBvcHBvc2UgdG8gYXNraW5nIHRvIHRoZSBXRzsgd2UganVzdCBy ZXF1ZXN0IA0KPiB5b3UgZmlyc3QgdG8gYWRkIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24gdG8gcHJv Y2VlZCBmb3J3YXJkLiANCj4gPiANCj4gPiB0aGFua3MuIA0KPiA+IA0KPiA+IEpQIGFuZCBNaWNo YWVsLiANCj4gPiANCj4gPiBKUC4gDQo+ID4gDQo+ID4+IA0KPiA+PiBCZXN0LCANCj4gPj4gDQo+ ID4+IFRob21hcyANCj4gPj4gDQo+ID4+PiBUaGFua3MuIA0KPiA+Pj4gDQo+ID4+PiBKUCBhbmQg TWljaGFlbC4gDQo+ID4+PiANCj4gPj4+PiANCj4gPj4+PiBCZXN0LCANCj4gPj4+PiANCj4gPj4+ PiBUaG9tYXMsIFVscmljaCwgWXVpY2hpLCBKaWF6aSBhbmQgQXhlbCANCj4gPj4+IA0KPiA+PiAN Cj4gPiANCj4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f XyANCj4gPiBSb2xsIG1haWxpbmcgbGlzdCANCj4gPiBSb2xsQGlldGYub3JnIA0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbCANCj4gPiANCj4gDQo+IA0KPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyANCj4gUm9sbCBt YWlsaW5nIGxpc3QgDQo+IFJvbGxAaWV0Zi5vcmcgDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcm9sbCANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18gDQo+IFJvbGwgbWFpbGluZyBsaXN0IA0KPiBSb2xsQGlldGYub3JnIA0K PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwgDQo+IA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSb2xsIG1haWxp bmcgbGlzdA0KPiBSb2xsQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcm9sbA0KDQoKCgpDZSBtZXNzYWdlIGV0IHRvdXRlcyBsZXMgcGnDqGNlcyBqb2lu dGVzIChjaS1hcHLDqHMgbGUgJ01lc3NhZ2UnKSBzb250IMOpdGFibGlzIMOgIGwnaW50ZW50aW9u IGV4Y2x1c2l2ZSBkZXMgZGVzdGluYXRhaXJlcyBldCBsZXMgaW5mb3JtYXRpb25zIHF1aSB5IGZp Z3VyZW50IHNvbnQgc3RyaWN0ZW1lbnQgY29uZmlkZW50aWVsbGVzLiBUb3V0ZSB1dGlsaXNhdGlv biBkZSBjZSBNZXNzYWdlIG5vbiBjb25mb3JtZSDDoCBzYSBkZXN0aW5hdGlvbiwgdG91dGUgZGlm ZnVzaW9uIG91IHRvdXRlIHB1YmxpY2F0aW9uIHRvdGFsZSBvdSBwYXJ0aWVsbGUsIGVzdCBpbnRl cmRpdGUgc2F1ZiBhdXRvcmlzYXRpb24gZXhwcmVzc2UuCgpTaSB2b3VzIG4nw6p0ZXMgcGFzIGxl IGRlc3RpbmF0YWlyZSBkZSBjZSBNZXNzYWdlLCBpbCB2b3VzIGVzdCBpbnRlcmRpdCBkZSBsZSBj b3BpZXIsIGRlIGxlIGZhaXJlIHN1aXZyZSwgZGUgbGUgZGl2dWxndWVyIG91IGQnZW4gdXRpbGlz ZXIgdG91dCBvdSBwYXJ0aWUuIFNpIHZvdXMgYXZleiByZcOndSBjZSBNZXNzYWdlIHBhciBlcnJl dXIsIG1lcmNpIGRlIGxlIHN1cHByaW1lciBkZSB2b3RyZSBzeXN0w6htZSwgYWluc2kgcXVlIHRv dXRlcyBzZXMgY29waWVzLCBldCBkZSBuJ2VuIGdhcmRlciBhdWN1bmUgdHJhY2Ugc3VyIHF1ZWxx dWUgc3VwcG9ydCBxdWUgY2Ugc29pdC4gTm91cyB2b3VzIHJlbWVyY2lvbnMgw6lnYWxlbWVudCBk J2VuIGF2ZXJ0aXIgaW1tw6lkaWF0ZW1lbnQgbCdleHDDqWRpdGV1ciBwYXIgcmV0b3VyIGR1IG1l c3NhZ2UuCgpJbCBlc3QgaW1wb3NzaWJsZSBkZSBnYXJhbnRpciBxdWUgbGVzIGNvbW11bmljYXRp b25zIHBhciBtZXNzYWdlcmllIMOpbGVjdHJvbmlxdWUgYXJyaXZlbnQgZW4gdGVtcHMgdXRpbGUs IHNvbnQgc8OpY3VyaXPDqWVzIG91IGTDqW51w6llcyBkZSB0b3V0ZSBlcnJldXIgb3UgdmlydXMu Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KClRo aXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzICh0aGUgJ01lc3NhZ2UnKSBhcmUgaW50ZW5k ZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2Vlcy4gVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIE1lc3NhZ2UgaXMgY29uZmlkZW50aWFsLiBBbnkgdXNlIG9mIGluZm9ybWF0aW9uIGNv bnRhaW5lZCBpbiB0aGlzIE1lc3NhZ2Ugbm90IGluIGFjY29yZCB3aXRoIGl0cyBwdXJwb3NlLCBh bnkgZGlzc2VtaW5hdGlvbiBvciBkaXNjbG9zdXJlLCBlaXRoZXIgd2hvbGUgb3IgcGFydGlhbCwg aXMgcHJvaGliaXRlZCBleGNlcHQgZm9ybWFsIGFwcHJvdmFsLgoKSWYgeW91IGFyZSBub3QgdGhl IGFkZHJlc3NlZSwgeW91IG1heSBub3QgY29weSwgZm9yd2FyZCwgZGlzY2xvc2Ugb3IgdXNlIGFu eSBwYXJ0IG9mIGl0LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3Is IHBsZWFzZSBkZWxldGUgaXQgYW5kIGFsbCBjb3BpZXMgZnJvbSB5b3VyIHN5c3RlbSBhbmQgbm90 aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYnkgcmV0dXJuIG1lc3NhZ2UuCgpFLW1haWwgY29t bXVuaWNhdGlvbiBjYW5ub3QgYmUgZ3VhcmFudGVlZCB0byBiZSB0aW1lbHkgc2VjdXJlLCBlcnJv ciBvciB2aXJ1cy1mcmVlLgo= --=_alternative 006C539AC1257A00_= MIME-Version: 1.0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkRlYXIgTXVrdWwsIGFsbCw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhpbmsgdGhhdCB0aGUg bWFpbiBnb2FsIG9mIHRoYXQgZG91bWVudA0KaXMgdG8gcmFpc2UgaXNzdWVzIHRoYXQgYXJlIGlu aGVyZW50IHRvIHRoZSBSUEwgUkZDLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+SW4gbXkgb3BpbmlvbiwgdGhpcyBJLUQgaGFzIGJlZW4gc3VibWl0dGVkDQp0byBy YWlzZSBzb21lIGNvbmNlcm5zIGFib3V0IHRoZSBvcGVyYXRpb24gb2YgUlBMLjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXMgaXQgaGFzIGJlZW4gYnJvdWdodCB1 cCBzZXZlcmFsIHRpbWVzLA0KYXMgYW55IG90aGVyIHByb3RvY29sLCB0aGUgUlBMIHNwZWNpZmlj YXRpb24gd2lsbCBldm9sdmUgaW4gb3JkZXIgdG8gdGFrZQ0KaW50byBhY2NvdW50IG9ic2VydmF0 aW9ucyBsaXN0ZWQgb3ZlciB0aW1lLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0ic2Fucy1zZXJpZiI+QXMgSlAgbWVudGlvbmVkLCBpdCBzZWVtcyB0aGF0IGNvbnN0cnVjdGl2 ZQ0Kd29yayBpcyBuZWVkZWQgd2l0aGluIFJPTEwgdG8gZml4IHRoZSBpZGVudGlmaWVkIGdhcHMg b2YgdGhlIGN1cnJlbnQgc3BlYy4NClRoZSByZXNwb25zZSB0byB0aGF0IG1heSBiZSB0aGUgYWRk aXRpb24gb2YgbmV3IG1lY2hhbmlzbXMgd2l0aGluIGZ1dHVyZQ0KdmVyc2lvbnMgb2YgdGhlIHNw ZWMsIG9yIGEgY2xlYXIgc3RhdGVtZW50IGFib3V0IHRoZSBsaW1pdGF0aW9ucyBvZiB0aGUNCnBy b3RvY29sLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ RnJvbSB3aGF0IGhhcyBiZWVuIHByZXZpb3VzbHkgc2FpZCBvbg0KdGhlIG1haWxpbmcgbGlzdCwg SSBhZ3JlZSB0aGF0IHRpbWUgaGFzIHRvIGJlIGludmVzdGVkIHRvIHR1bmUgdGhlIHByb3RvY29s DQpmb3IgZWFjaCBkaWZmZXJlbnQgYXBwbGljYXRpb24gZXRjLi4uIGJ1dCBmcm9tIHdoYXQgSSB1 bmRlcnN0YW5kLCB0dW5pbmcNCmFuIGFscmVhZHkgZXhpc3Rpbmcgc2V0IG9mIHBhcmFtZXRlcnMg d2lsbCBub3QgZmlsbCB0aGUgdGVjaG5pY2FsIGdhcHMNCm9mIGEgc3BlYy4gQXMgYW4gZW5kLXVz ZXIgSSdtIGV2ZW4gbW9yZSBjb25jZXJuZWQgYWJvdXQgdGhhdCwgc2luY2UgZWFjaA0KdmVuZG9y IG1heSBoYXZlIGl0cyBvd24gd2F5IHRvIGZpbGwgdGhlIGdhcHMgYW5kIHRvIG1ha2UgdGhlIHBy b3RvY29sIHdvcmsNCmluIGEgcGFydGljdWxhciBlbnZpcm9ubWVudC4gSG93ZXZlciwgaW50ZXJv cGVyYWJpbGl0eSBpcyBub3QgZ3VhcmFudGVlZCwNCndoaWNoIGlzIGEgbWFqb3IgY29uY2VybiBm b3IgZW5kLXVzZXJzIHRhcmdldGluZyBtYXNzaXZlIG11bHRpLXZlbmRvciByb2xsLW91dHMuPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIHRoaW5rIGl0 J3MgaW4gdGhlIHNjb3BlIG9mIHRoZSB3b3JraW5nDQpncm91cCB0byBhZGRyZXNzIGVhY2ggc2lu Z2xlIGNvbmNlcm4gaWRlbnRpZmllZCBpbiBvcmRlciB0byBhdm9pZCB0aGVzZQ0KaW50ZXJvcCBp c3N1ZXMgaW4gdGhlIHdpZGVzdCBwb3NzaWJsZSBhcHBsaWNhdGlvbiBhcmVhLjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QmVzdCByZWdhcmRzLDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Q8OpZHJpYzwvZm9udD4NCjxi cj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPnJvbGwtYm91bmNlc0BpZXRmLm9yZyBhIMOpY3JpdCBz dXIgMTYvMDUvMjAxMiAyMDoyNTo0NA0KOjxicj4NCjxicj4NCiZndDsgbXVrdWxAdXdtLmVkdSA8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgRW52b3nDqSBwYXIgOiByb2xs LWJvdW5jZXNAaWV0Zi5vcmc8YnI+DQomZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jmd0OyAxNi8wNS8yMDEyIDIwOjI1PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj4mZ3Q7IDxicj4NCiZndDsgQTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyA8YnI+DQomZ3Q7IHVscmljaEBoZXJiZXJnLm5hbWU8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBjYzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IHJvbGxAaWV0Zi5vcmcsIG1jckBzYW5kZWxtYW4uY2E8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBPYmpldDwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFJlOiBbUm9s bF0gV2F5IGZvcndhcmQgZm9yIGRyYWZ0LWNsYXVzZW4tbGxuLXJwbC1leHBlcmllbmNlczwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7U2Vy aW91c2x5LCBkbyB0aGUgYXV0aG9ycyB0aGluayB0aGF0IHRoaXMgZG9jdW1lbnQgd291bGQgcGFz cw0KdGhlIDxicj4NCiZndDsgbXVzdGVyIGZvciBwdWJsaWNhdGlvbiBpbiBhbnkgZGVjZW50IGFj YWRlbWljIGpvdXJuYWw/IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7SSBkb24ndCBrbm93IHNp bmNlIHdoZW4gdGhhdCBpcyBhbnkgY3JpdGVyaWEgZm9yIElFVEYgd29yay4gV2FzDQppdCA8YnI+ DQomZ3Q7IGEgY3JpdGVyaWEgZm9yIHRoZSBzdGFuZGFyZGl6YXRpb24gb2YgUlBMIGl0c2VsZj8g PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJQTCBpcyBhIHByb3RvY29sIHNwZWNpZmljYXRpb24gd2hl cmVhcyB5b3VyIGRvY3VtZW50IGlzIGFuIGFuYWx5c2lzPGJyPg0KJmd0OyBvZiBpdHMgcGVyZm9y bWFuY2UuIFRoZSBwZXJmb3JtYW5jZSBhbmFseXNpcyBwYXBlcnMgZmFsbCBpbiBhY2FkZW1pYzxi cj4NCiZndDsgZG9tYWluIGFuZCBtdXN0IGZvbGxvdyBhIGNlcnRhaW4gcmlnb3IgYW5kIGhhdmUg YSBjZXJ0YWluIGxldmVsIG9mDQo8YnI+DQomZ3Q7IGRldGFpbHMgd2hlbiByZWZlcnJpbmcgdG8g ZXhwZXJpbWVudGFsIHdvcmsuIFlvdXIgZG9jdW1lbnQgZmFpbHMgdG8NCmRvIHNvLjxicj4NCiZn dDsgPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0O1JpZ2h0IG5vdywgdGhlIGRy YWZ0IHJlYWRzIG1vcmUgbGlrZSBwcm9wYWdhbmRhIHRoYW4gaW5mb3JtYXRpb246DQo8YnI+DQom Z3Q7IHdyaXR0ZW4gdG8gYmFkIG1vdXRoIGEgcHJvdG9jb2wgb24gdGhlIGJhc2lzIG9mIGJpYXNl ZC9mcml2b2xvdXMgYXJndW1lbnRzLg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDtJIGFtIHNv cnJ5IHRoYXQgeW91IHNlZSB0aGUgZHJhZnQgdGhhdCB3YXkuIFdlIGhhdmUgdHJpZWQgdG8gYmUN CmFzIDxicj4NCiZndDsgb2JqZWN0aXZlIGFzIHBvc3NpYmxlLiBDYW4geW91IHBvaW50IG91dCBh bnkgY29uY3JldGUgcGFyYWdyYXBoIG9yDQo8YnI+DQomZ3Q7IHNlY3Rpb24gdGhhdCB5b3Ugc2Vl IGFzICZxdW90O3Byb3BhZ2FuZGEmcXVvdDs/IEFuZCBob25lc3RseSwgSSB3b3VsZA0KaGF2ZSA8 YnI+DQomZ3Q7IGhvcGVkIHRoYXQgd2UgY2FuIGhhdmUgYW4gb2JqZWN0aXZlLCBhcmd1bWVudGF0 aXZlIGRpc2N1c3Npb24gb24gdGhlPGJyPg0KJmd0OyBtYWlsaW5nIGxpc3QsIGFuZCBub3QgYSBk aXNtaXNzYWwgb2Ygb3VyIGFyZ3VtZW50cyB3aXRob3V0IGFueSA8YnI+DQomZ3Q7IGNvbnN0cnVj dGl2ZSBkaXNjdXNzaW9uLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIHByb2JsZW0gaXMgdGhh dCB0aGUgZG9jdW1lbnQgaXMgc28gYmlhc2VkIHRoYXQgaXQgaXMgaGFyZCB0byBzZWU8YnI+DQom Z3Q7IGl0IGFueSBvdGhlciB3YXkuIEEgc2VjdGlvbi1ieS1zZWN0aW9uIHJldmlldyBvZiB0aGUg ZG9jdW1lbnQgY29taW5nPGJyPg0KJmd0OyBpbiBhIGNvdXBsZSBvZiBkYXlzLiA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgJmd0OyZndDtXaHkgd291bGQgdGhlIGF1dGhvcnMgY29tcGxldGVseSBpZ25v cmUgUDJQLVJQTCBldmVuIHRob3VnaA0KaXQgPGJyPg0KJmd0OyByZXNvbHZlcyBtYW55IGlzc3Vl cyB0aGV5IGhhdmUgcG9pbnRlZCBvdXQuIDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7MSkgQmVj YXVzZSBQMlAtUlBMIGlzIG5vdCBldmVuIGFuIFJGQyB5ZXQsIHdoZXJlYXMgUlBMIGlzLCBhbmQN CmlzIDxicj4NCiZndDsgYWxyZWFkeSBkZXBsb3llZC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNv LCB5b3UgYmFzaWNhbGx5IHRocm93IHRvIGR1c3RiaW4gMisgeWVhcnMgb2YgaGFyZCB3b3JrIHBl b3BsZSBoYXZlPGJyPg0KJmd0OyBkb25lIG9uIFAyUC1SUEw/IEV2ZW4gdGhvdWdoIGl0IGlzIGRl c2lnbmVkIHRvIHNvbHZlIHByZWNpc2VseSB0aGUNCjxicj4NCiZndDsgcHJvYmxlbXMgeW91IGhp Z2hsaWdodCBpbiB5b3VyIGRvY3VtZW50PyBTYW1lIGdvZXMgZm9yIHRoZSA8YnI+DQomZ3Q7IGNv bXByZXNzaW9uIHByb2JsZW0uIFRoZSB3b3JraW5nIGdyb3VwIHNwZW50IHNvIG11Y2ggdGltZSA8 YnI+DQomZ3Q7IGRlbGliZXJhdGluZyBvbiB0aGUgcHJvYmxlbSBhbmQgaG93IGJlc3QgdG8gc29s dmUgaXQuIEJ1dCB5b3VyIDxicj4NCiZndDsgZG9jdW1lbnQgY29udmVuaWVudGx5IGNob3NlIHRv IGlnbm9yZSBhbGwgdGhhdCBkaXNjdXNzaW9uLiBBdCB0aGUNCjxicj4NCiZndDsgdmVyeSBsZWFz dCwgeW91ciBkb2N1bWVudCBjb3VsZCBoYXZlIGJlZW4gY29tcGxldGUgYnkgbGlzdGluZyBhbGwN Cjxicj4NCiZndDsgdGhlIGlzc3VlcyBwZW9wbGUgcG9pbnRlZCBvdXQuIDxicj4NCiZndDsgPGJy Pg0KJmd0OyAmZ3Q7MikgVGhlcmUgaXMgbm8gZGVwZW5kZW5jeSBmcm9tIFJQTCB0byBQMlAtUlBQ TCwgaS5lLiwgaXQgc2hvdWxkDQo8YnI+DQomZ3Q7IHdvcmsgc3RhbmQtYWxvbmUuPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IFRoZW4sIG5vIHByb3RvY29sIHNob3VsZCBldmVyIGJlIGV4dGVuZGVkLiBF YWNoIHByb3RvY29sIG11c3Qgd29yaw0KPGJyPg0KJmd0OyB3ZWxsIGluIGFsbCBwb3NzaWJsZSBz Y2VuYXJpb3MuPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7MykgUDJQLVJQ TCBpcyBleHBlcmltZW50YWwsIFJQTCBpcyBzdGQuIHRyYWNrLiA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgU28sIFAyUC1SUEwgd291bGQgbmV2ZXIgYmVjb21lIHN0YW5kYXJkcyB0cmFjaz88YnI+DQom Z3Q7IDxicj4NCiZndDsgJmd0OzQpIEkgdGhvdWdodCB0aGF0IFJPTEwgaXMgY2hhcnRlcmVkIHRv IHByb3ZpZGUgcm91dGluZyBzb2x1dGlvbnMNCjxicj4NCiZndDsgZm9yIGV4dHJlbWVseSBjb25z dHJhaW5lZCBkZXZpY2VzICh3aGljaCB3YXMsIEkgYXNzdW1lLCBvbmUgb2YgdGhlDQo8YnI+DQom Z3Q7IHJlYXNvbnMgdG8gbm90IGNvbnNpZGVyIE1BTkVUIHdvcmspLiBPbmUgb2Ygb3VyIGFyZ3Vt ZW50cyBpbiB0aGUgPGJyPg0KJmd0OyBkcmFmdCBpcyB0aGF0IFJQTCBpcyB2ZXJ5IGNvbXBsZXgg KHRoZSBzcGVjaWZpY2F0aW9uIGFsb25lIHBsdXMgPGJyPg0KJmd0OyBuZWNlc3NhcnkgY29tcGFu aW9uIGRvY3VtZW50cyBoYXMgc2V2ZXJhbCBodW5kcmVkIHBhZ2VzKS4gQWRkaW5nIDxicj4NCiZn dDsgUDJQLVJQTCBhcyBuZWNlc3NpdHkgdG8gbWl0aWdhdGUgc29tZSBvZiB0aGUgaXNzdWVzIHdv dWxkIGluY3JlYXNlDQo8YnI+DQomZ3Q7IHRoZSBjb2RlIHNpemUgZXZlbiBtb3JlLiA8YnI+DQom Z3Q7IDxicj4NCiZndDsgVHdvIHBvaW50czo8YnI+DQomZ3Q7IDxicj4NCiZndDsgMS4gQSBsb25n IFJGQyBkb2VzIG5vdCBuZWNlc3NhcmlseSBtZWFuIGEgY29tcGxleCBwcm90b2NvbC4gRG8geW91 DQo8YnI+DQomZ3Q7IG5lZWQgdG8gaW1wbGVtZW50IGV2ZXJ5IHRoaW5nIGluIFJQTCBSRkMgZm9y IGEgcGFydGljdWxhciA8YnI+DQomZ3Q7IGRlcGxveW1lbnQ/IEl0IHdvdWxkIGhhdmUgYmVlbiBt dWNoIG1vcmUgdXNlZnVsIGlmIHlvdXIgZG9jdW1lbnQgaGFkPGJyPg0KJmd0OyBpZGVudGlmaWVk IHRoZSBtaW5pbWFsIHNldCBvZiBSUEwgZmVhdHVyZXMgdGhhdCBNVVNUIGJlIHByZXNlbnQgaW4N Cjxicj4NCiZndDsgZWFjaCBkZXBsb3ltZW50LiAmbmJzcDsmbmJzcDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDIuIElmIHlvdSBoYWQgYWRkZWQgMzQgcGFnZXMgb2YgUDJQLVJQTCB0byAxNTcgcGFn ZXMgb2YgUlBMIFJGQywgaXQNCjxicj4NCiZndDsgd291bGQgbm90IHdvcnNlbiB0aGUgUlBMJ3Mg JnF1b3Q7Y29tcGxleGl0eSZxdW90OyB0b28gbXVjaC4gV291bGQNCml0PyBCdXQgdGhlbjxicj4N CiZndDsgeW91IHdvdWxkIGhhdmUgbXVjaCBsZXNzIHRvIGNvbXBsYWluIGFib3V0IFJQTCBpbiB5 b3VyIGRvY3VtZW50Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0O1RoZXJlIGFyZSBudW1l cm91cyBzaW1pbGFyIHNpbnMgb2Ygb21pc3Npb24gc3ByZWFkIHRocm91Z2hvdXQNCnRoZSBkb2N1 bWVudC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDtXaGVyZT8gPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IFNvbWUgYWRkaXRpb25hbCBzaW5zIEkgcG9pbnRlZCBvdXQgYWJvdmUuIFBsZWFzZSB3YWl0 IGZvciBteSA8YnI+DQomZ3Q7IGRldGFpbGVkIHJldmlldyBmb3IgYSBtb3JlIGNvbXBsZXRlIGxp c3QuPGJyPg0KJmd0OyAmbmJzcDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7QXMgYSBy ZXN1bHQsIG1vc3QgY29uY2x1c2lvbnMgdGhlIGRvY3VtZW50IHJlYWNoZXMgYXJlIG9wZW4NCnRv IDxicj4NCiZndDsgZG91YnQgaWYgbm90IG91dHJpZ2h0IGluY29ycmVjdC4gPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7ICZndDtJcyB0aGF0IHByb29mIGJ5IGF1dGhvcml0eSBvciBhIHJlYWwgYXJndW1l bnQ/IFBsZWFzZSBiZSBtb3JlDQpjb25zdHJ1Y3RpdmUuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBZ b3UgcmVhY2hlZCB0aGUgY29uY2x1c2lvbnMgeW91IHJlYWNoZWQgYmFzZWQgb24gaW5jb21wbGV0 ZSA8YnI+DQomZ3Q7IGFyZ3VtZW50cyBvciBieSBnZW5lcmFsaXppbmcgdGhpbmdzIHRoYXQgeW91 IHNhdyBpbiBzcGVjaWZpYyA8YnI+DQomZ3Q7IGltcGxlbWVudGF0aW9ucy9kZXBsb3ltZW50cy4g VGhhdCBpcyB3aHkgdGhlc2UgY29uY2x1c2lvbnMgYXJlIGRvdWJ0ZnVsLjxicj4NCiZndDsgJm5i c3A7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0O1N1cmUsIFJQTCBpcyBub3QgYSBwZXJm ZWN0IHByb3RvY29sIC0gbm8gcHJvdG9jb2wgaXMuIEJ1dA0KdGhpcyA8YnI+DQomZ3Q7IGRvY3Vt ZW50IGlzIG5vdCBhbiB1bmJpYXNlZCBzY2llbnRpZmljIGFuYWx5c2lzIG9mIHRoZSBwcm90b2Nv bC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDtIb3cgZG8geW91IGNvbWUgdG8gdGhhdCBjb25j bHVzaW9uPyBXZSBwcm92aWRlIGNvbmNyZXRlLCBvYmplY3RpdmUNCjxicj4NCiZndDsgYXJndW1l bnRzLiBJIGRvIG5vdCBzZWUgdGhhdCBpbiB5b3VyIGVtYWlsLiA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgUGxlYXNlIHNlZSB0aGUgcHJldmlvdXMgY29tbWVudC48YnI+DQomZ3Q7ICZuYnNwOyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgJmd0OyZndDtBcyBQYXNjYWwgc2FpZCwgdGhpcyBkb2N1bWVudCBj b3VsZCBoYXZlIHNlcnZlZCBhIHZhbHVhYmxlDQo8YnI+DQomZ3Q7IGNvbnN0cnVjdGl2ZSBwdXJw b3NlLiBCdXQsIHBlcmhhcHMgdGhpcyB3YXMgbm90IHRoZSBpbnRlbnRpb24gb2YgdGhlPGJyPg0K Jmd0OyBhdXRob3JzLiBUaGlzIGRvY3VtZW50IHNob3VsZCBiZSByZWNvZ25pemVkIGZvciB3aGF0 IGl0IGlzOiBhIDxicj4NCiZndDsgcG9saXRpY2FsIGRvY3VtZW50IHdyaXR0ZW4gdG8gZnVydGhl ciBhIHBhcnRpY3VsYXIgZGVzdHJ1Y3RpdmUgYWdlbmRhLg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgJmd0O0kgcmVhbGx5IGRvbid0IGtub3cgd2hhdCB0byBzYXkgdG8gdGhhdCBu b24tY29uc3RydWN0aXZlIGFyZ3VtZW50Lg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJhdGhlciB0 aGFuIGd1aWRpbmcgYSByZWFkZXIgaG93IHRvIGRlcGxveSBSUEwgYW5kIGF2b2lkIHRoZSA8YnI+ DQomZ3Q7IHBvdGVudGlhbCBwaXRmYWxscywgeW91ciBtZXNzYWdlIGlzIHRoYXQgUlBMIGlzIHNv IGZ1bmRhbWVudGFsbHkgPGJyPg0KJmd0OyBmbGF3ZWQgdGhhdCBpdCBzaG91bGQgYmUgZHVtcGVk IGFsdG9nZXRoZXIuIFRoaXMgaXMgYW55IHRoaW5nIGJ1dA0KPGJyPg0KJmd0OyBjb25zdHJ1Y3Rp dmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rczxicj4NCiZndDsgTXVrdWw8YnI+DQomZ3Q7 ICZuYnNwOyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFua3MgPGJyPg0KJmd0 OyBNdWt1bCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAtLS0tLSBPcmlnaW5hbCBN ZXNzYWdlIC0tLS0tIDxicj4NCiZndDsgRnJvbTogJnF1b3Q7QyBDaGF1dmVuZXQmcXVvdDsgJmx0 OyBjLmNoYXV2ZW5ldEB3YXR0ZWNvLmNvbSAmZ3Q7IDxicj4NCiZndDsgVG86ICZxdW90O0pQIFZh c3NldXImcXVvdDsgJmx0OyBqcHZAY2lzY28uY29tICZndDsgPGJyPg0KJmd0OyBDYzogJnF1b3Q7 cm9sbCBXRyZxdW90OyAmbHQ7IHJvbGxAaWV0Zi5vcmcgJmd0OywgJnF1b3Q7TWljaGFlbCBSaWNo YXJkc29uJnF1b3Q7DQombHQ7IG1jckBzYW5kZWxtYW4uY2EgJmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgU2VudDogV2VkbmVzZGF5LCBNYXkgMTYsIDIwMTIgOToxMzo1NiBBTSA8YnI+DQomZ3Q7 IFN1YmplY3Q6IFJlOiBbUm9sbF0gV2F5IGZvcndhcmQgZm9yIGRyYWZ0LWNsYXVzZW4tbGxuLXJw bC1leHBlcmllbmNlcw0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0 OyBIaSwgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgZGVmaW5pdGVseSBhZ3JlZSB0aGF0IGltcGxl bWVudGF0aW9uIGZlZWRiYWNrIGlzIGFsd2F5cyBnb29kIHRvDQo8YnI+DQomZ3Q7IGtub3csIHNv IHlvdXIgZXhwZXJpZW5jZXMgYXJlIHdlbGNvbWVkLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBh bHNvIHRoaW5rIHRoYXQgcHJvYmxlbXMgaW52ZXN0aWdhdGlvbnMgbmVlZCBhIGNvbXBsZXRlIGFu ZCBleGFjdA0KPGJyPg0KJmd0OyB2aWV3LCBzbyBJIHdvdWxkIGVuY291cmFnZSB5b3UgdG8gcHV0 IG11Y2ggbW9yZSBkZXRhaWxzIGFib3V0IHRoZQ0KPGJyPg0KJmd0OyBzY2VuYXJpbyBhbmQgdGhl IGVudmlyb25tZW50IHdoZXJlIHlvdSBleHBlcmltZW50YXRpb25zIHRvb2sgcGxhY2UuDQo8YnI+ DQomZ3Q7IEZvciBpbnN0YW5jZSwgSSB3b3VsZCBlbmpveSBhICZxdW90O1JQTCBJbXBsZW1lbnRh dGlvbiBEZXNjcmlwdGlvbiZxdW90Ow0KPGJyPg0KJmd0OyBzZWN0aW9uIGluIHlvdSBkcmFmdCBs aXN0aW5nIHRoZSBoYXJkd2FyZSB5b3VyIHVzZWQsIHlvdXIgUlBMIDxicj4NCiZndDsgcGFyYW1l dGVycywgdGhlIFJQTCBkcmFmdHMgYW5kIG1lY2hhbmlzbXMgaW1wbGVtZW50ZWQsIHlvdXIgT1Mg ZXRjLi4uDQo8YnI+DQomZ3Q7IElmIEkgcmVhZCBhIHBhcGVyIHdpdGggb3J0aG9nb25hbCBvYnNl cnZhdGlvbnMgd2l0aCB0aGUgc2FtZSBsZXZlbA0KPGJyPg0KJmd0OyBvZiBkZXRhaWxzIGFzIGlu IHlvdXIgZHJhZnQsIHRoZW4gaG93IGNvdWxkIEkgZm9yZ2UgbXkgb3BpbmlvbiA/IDxicj4NCiZn dDsgPGJyPg0KJmd0OyBMb29raW5nIGF0IHRoaXMgZHJhZnQsIGl0IHNlZW1zIHRoYXQgaXQgZ2F0 aGVycyBsb3RzIG9mIHByZXZpb3VzIDxicj4NCiZndDsgZGlzY3Vzc2lvbnMgdGhhdCBvY2N1cnJl ZCBkdXJpbmcgdGhlIHBhc3QgeWVhciBvbiB2YXJpb3VzIG1haWxpbmcNCjxicj4NCiZndDsgbGlz dHMsIGFuZCBJRVRGIG1lZXRpbmdzLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgRG9lcyB5b3VyIGV4 cGVyaW1lbnRhdGlvbnMgdGFrZXMgY2FyZSBhYm91dCB0aGVzZSByZWNvbW1lbmRhdGlvbnMNCj8g PGJyPg0KJmd0OyBJZiBub3QsIGRvZXMgeW91ciBkcmFmdCBtZW50aW9uIHRoZSBwcm9wb3NpdGlv bnMgdGhhdCBoYXZlIGJlZW4gbWFkZTxicj4NCiZndDsgdG8gYWRkcmVzcyB0aGUgcHJvYmxlbXMg eW91IHBvaW50IG91dCBpbiB5b3VyIGRyYWZ0ID8gPGJyPg0KJmd0OyBJIHRoaW5rIGl0IGNvdWxk IGJlIHdvcnRoIHRvIGxldmVyYWdlIG9uIHRoZXNlIHByZXZpb3VzIGRpc2N1c3Npb25zLg0KPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IFlvdXIgZHJhZnQgaXMgYSBsaXN0IG9mIERlc2NyaXB0aW9uIGFu ZCBPYnNlcnZhdGlvbnMuIDxicj4NCiZndDsgTWF5YmUgeW91IGNvdWxkIGFkZCBhICZxdW90O1Jl c29sdXRpb24gUHJvcG9zYWwmcXVvdDsgc2VjdGlvbiBmb3INCmVhY2ggPGJyPg0KJmd0OyBwcm9i bGVtLCBnYXRoZXJpbmcgcHJldmlvdXMgZGlzY3Vzc2lvbiBhbmQgeW91ciBvd24gcHJvcG9zYWxz ID8gPGJyPg0KJmd0OyBJZGVudGlmeWluZyB3aGF0IGlzIHdyb25nIGluIHlvdXIgaW1wbGVtZW50 YXRpb24gaXMgYSBnb29kIGZpcnN0IDxicj4NCiZndDsgc3RlcCwgYnV0IHRoZSBoYXJkZXN0IHBh cnQgaXMgdG8gcHJvcG9zZSBzb21lIGNvcnJlY3Rpb25zLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsg QmVzdCBSZWdhcmRzLCA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQ8OpZHJpYyBDaGF1dmVuZXQuIDxi cj4NCiZndDsgPGJyPg0KJmd0OyBMZSAxNiBtYWkgMjAxMiDDoCAxNTowNCwgSlAgVmFzc2V1ciBh IMOpY3JpdCA6IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IERlYXIgVGhvbWFzLCA8YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IE9uIE1heSAxNiwgMjAxMiwgYXQgMjowOCBQTSwgVGhv bWFzIEhlaWRlIENsYXVzZW4gd3JvdGU6IDxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsm Z3Q7IERlYXIgSlAgYW5kIE1pY2hhZWwsIDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAm Z3Q7Jmd0OyBUaGFuayB5b3UgZm9yIHlvdXIgbWFpbC4gPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+ DQomZ3Q7ICZndDsmZ3Q7IE9uIE1heSAxNiwgMjAxMiwgYXQgMDk6MTggLCBKUCBWYXNzZXVyIHdy b3RlOiA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IERlYXIgVGhv bWFzLCA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyBPbiBN YXkgMTEsIDIwMTIsIGF0IDg6MjUgQU0sIFRob21hcyBIZWlkZSBDbGF1c2VuIHdyb3RlOg0KPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IERlYXIgSlAs IE1pY2hhZWwsIGFsbCA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyZndDsmZ3Q7IFVwb24gSlBzIGludml0YXRpb24sIGRyYWZ0LWNsYXVzZW4tbGxuLXJwbC1l eHBlcmllbmNlcw0Kd2FzIDxicj4NCiZndDsgcHJlc2VudGVkIGFuZCBkaXNjdXNzZWQgYXQgdGhl IFBhcmlzIG1lZXRpbmcuIDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZn dDsmZ3Q7Jmd0OyZndDsgVGhlIGF1dGhvcnMgY29uc2lkZXIgdGhlIGRvY3VtZW50IGNvbXBsZXRl IGFuZCAmcXVvdDtkb25lJnF1b3Q7LA0KYW5kIGFyZSA8YnI+DQomZ3Q7IGxvb2tpbmcgdG8gdGFr ZSBpdCBmb3J3YXJkIGluIHRoZSBJRVRGIDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBwcm9j ZXNzIGZvciBwdWJsaWNhdGlvbiBhcyAmcXVvdDtJbmZvcm1hdGlvbmFsIFJGQyZxdW90Ow0KaW4g dGhlIHZlcnkgbmVhciBmdXR1cmUuIDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyA8YnI+DQom Z3Q7ICZndDsmZ3Q7Jmd0OyZndDsgV2Ugd291bGQgdGhlcmVmb3JlIGxpa2UgdG8gYXNrIHRoZSBX RyBjaGFpcnMsIGlmDQp0aGUgUk9MTCBXRyBpczxicj4NCiZndDsgd2lsbGluZyB0byBhY2NlcHQg YW5kIHByb2dyZXNzIHRoaXMgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IGRvY3VtZW50IHRv d2FyZHMgcHVibGljYXRpb24/IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0 OyZndDsmZ3Q7IFRoYW5rcyBmb3IgeW91ciBzdWdnZXN0aW9uLiBTbyBmYXIgd2UgaGF2ZW4ndCBz ZWUgYSBsb3QNCm9mIDxicj4NCiZndDsgZGlzY3Vzc2lvbi9pbnRlcmVzdCBmcm9tIHRoZSBXRyBi dXQgeW91ciByZXF1ZXN0IGlzIDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7IHBlcmZlY3RseSBmYWly LiA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgVGhhbmsgeW91IC0gSSBh aW0gdG8gYmUgZmFpci4gPGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0 OyBTbyBmYXIgdGhlcmUgYXJlIG5vIGRldGFpbHMgb24gdGhlIHNjZW5hcmlvcyBhbmQgdGVzdGlu Zw0KPGJyPg0KJmd0OyBlbnZpcm9ubWVudHMgdGhhdCBsZWQgdG8gdGhlIGlzc3VlcyB0aGF0IDxi cj4NCiZndDsgJmd0OyZndDsmZ3Q7IHlvdSByZXBvcnRlZCwgdGh1cyBJIHdvdWxkIHN1Z2dlc3Qg eW91IHRvIGZpcnN0IGluY2x1ZGUNCnRoZW0gc28gPGJyPg0KJmd0OyB0aGF0IHBlb3BsZSBpbnRl cmVzdGVkIGNvdWxkIGJlIGFibGUgdG8gcmVwcm9kdWNlIDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7 IGl0LiBPbmNlIHRoZSBkcmF0IGlzIHVwZGF0ZWQsIHdlJ2xsIGJlIGhhcHB5IHRvIHBvb2wNCnRo ZSBXRy4gPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgRG9l cyB0aGF0IG1ha2Ugc2Vuc2UgPyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZn dDsgTm90IHJlYWxseS4gTGV0IG1lIGV4cGxhaW4gbXkgZGlzYWdyZWVtZW50LiA8YnI+DQomZ3Q7 ICZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgV2UgdHJpZWQgUlBMIChhbmQsIEkgbm90ZSwg c2V2ZXJhbCBkaWZmZXJlbnQgaW5kZXBlbmRlbnQNCjxicj4NCiZndDsgaW1wbGVtZW50YXRpb25z IG9mIFJQTCkgaW4gYSBudW1iZXIgb2YgZGlmZmVyZW50IHNjZW5hcmlvcyBhbmQgPGJyPg0KJmd0 OyBkZXBsb3ltZW50cywgYW5kIG9ic2VydmVkIHRoZSBiZWhhdmlvcnMgZXhoaWJpdGVkIC0gbm90 aW5nIHRoYXQgd2hhdDxicj4NCiZndDsgd2Ugb2JzZXJ2ZWQgYWNyb3NzIHRoZSBkaWZmZXJlbnQg aW1wbGVtZW50YXRpb25zLCBzY2VuYXJpb3MgYW5kIDxicj4NCiZndDsgZGVwbG95bWVudHMgd2Fz IGZhaXJseSB1bml2ZXJzYWwuIDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyBXZSB0aGVuIHdlbnQgYmFjayB0byB0aGUgc3BlY2lmaWNhdGlvbiwgdG8gdW5kZXJzdGFuZCB0 aGVzZQ0KPGJyPg0KJmd0OyBiZWhhdmlvcnMgaW4gZGV0YWlsLCBhbmQgdW5kZXJzdGFuZCB0aGVp ciB1bml2ZXJzYWxpdHkgYXMgPGJyPg0KJmd0OyBpbmRlcGVuZGVudCBmcm9tIGEgc3BlY2lmaWMg c2NlbmFyaW8gb3IgZGVwbG95bWVudCBvciBpbXBsZW1lbnRhdGlvbjxicj4NCiZndDsgLSBidXQg cmF0aGVyLCBhcyBhcnRpZmFjdHMgb2YgdGhlIFJQTCBwcm90b2NvbCBkZXNpZ24uIDxicj4NCiZn dDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBXZSB0aGVyZWZvcmUgYmVsaWV2ZSB0aGF0 IF9hbnlfIGRlcGxveW1lbnQsIHNjZW5hcmlvIG9yIHRlc3RpbmcNCjxicj4NCiZndDsgZW52aXJv bm1lbnQgb2YgUlBMIG5lZWRzIHRvIHBheSBhdHRlbnRpb24gdG8gdGhlIGlzc3VlcyBwcmVzZW50 ZWQsDQo8YnI+DQomZ3Q7IGFuZCBmaW5kIGEgd2F5IG9mIGFkZHJlc3NpbmcgdGhlbS4gVGhlIHdh eSBvZiBhZGRyZXNzaW5nIHRoZXNlIDxicj4NCiZndDsgaXNzdWVzIGluIGEgZ2l2ZW4gZGVwbG95 bWVudCBvciBzY2VuYXJpbyB3b3VsZCBiZSBhcHByb3ByaWF0ZSBmb3INCmFuPGJyPg0KJmd0OyAm cXVvdDthcHBsaWNhYmlsaXR5IHN0YXRlbWVudCZxdW90OyBmb3IgdGhhdCBkZXBsb3ltZW50IG9y IHNjZW5hcmlvLg0KPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBKUCZndDsgVGhhbmtz IGZvciB0aGUgY2xhcmlmaWNhdGlvbjsgdGhhdCBiZWluZyBzYWlkLCBmb3IgdGhlDQpXRyB0byA8 YnI+DQomZ3Q7IG1ha2Ugc3VyZSB0aGF0IG5vdGhpbmcgaXMgJnF1b3Q7c2NlbmFyaW8mcXVvdDsg ZGVwZW5kZW50IGFuZCB0aGUgb3V0Y29tZQ0KY291bGQ8YnI+DQomZ3Q7IGluZGVlZCBhcHBseSB0 byBhbGwgc2NlbmFyaW9zLCA8YnI+DQomZ3Q7ICZndDsgaXQgbWlnaHQgYmUgd29ydGggYmVpbmcg bW9yZSBleHBsaWNpdC4gRm9yIGV4YW1wbGUsIHlvdSBwb2ludGVkDQo8YnI+DQomZ3Q7IG91dCB0 byB0aGUgTVRVIGlzc3VlLCB0byB3aGljaCBJIG1lbnRpb25lZCB0aGF0IDE1LjRnIHdvdWxkIGJy aW5nDQphIDxicj4NCiZndDsgc29sdXRpb24sIHNvIHlvdSBtYXkgd2FudCB0byA8YnI+DQomZ3Q7 ICZndDsgZXhwbGFpbiB0aGF0IHlvdSBkaWQgbm90IHVzZSAxNS40ZyBhbmQgdGhlcmUgYXJlIGEg bnVtYmVyIG9mDQpzdWNoIDxicj4NCiZndDsgZXhhbXBsZXMg4oCmLiA8YnI+DQomZ3Q7ICZndDsg PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IChGb3IgZXhhbXBsZSwgYSBk ZXBsb3ltZW50IHVzaW5nIG9ubHkgTDJzIHdoaWNoIHByb3ZpZGVzDQo8YnI+DQomZ3Q7IGd1YXJh bnRlZWQgYmktZGlyZWN0aW9uYWwgbGlua3MgJm5ic3A7Zm9yIEwzIHdvdWxkIGFkZHJlc3MgdGhp cyBieQ0KaW4gdGhlPGJyPg0KJmd0OyBhcHBsaWNhYmlsaXR5IHN0YXRlbWVudCBzdGF0aW5nICZx dW90O0FzIGFsbCBMMi1saW5rcyBhcmUgZ3VhcmFudGVlZA0KYmktPGJyPg0KJmd0OyBkaXJlY3Rp b25hbCwgdGhpcyBhZGRyZXNzZXMgdGhlIGlzc3VlcyByYWlzZWQgaW4gc2VjdGlvbiA5IGluIGRy YWZ0LTxicj4NCiZndDsgY2xhdXNlbi1sbG4tcnBsLWV4cGVyaWVuY2VzJnF1b3Q7LikgPGJyPg0K Jmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7IFRodXMsIHdlIGJlbGlldmUgdGhhdCBp dCB3b3VsZCBhY3R1YWxseSBiZSBtaXNsZWFkaW5nIChub3QNCnRvIDxicj4NCiZndDsgbWVudGlv biwgdW5uZWNlc3NhcmlseSB2ZXJib3NlKSB0byBwdXQgdGhlICZxdW90O2RldGFpbHMgb24gdGhl IHNjZW5hcmlvczxicj4NCiZndDsgYW5kIHRlc3RpbmcgZW52aXJvbm1lbnRzJnF1b3Q7IGludG8g dGhpcyBJLUQuIDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBEb2luZyBz byB3b3VsZCBtaXNsZWFkIHRoZSByZWFkZXIgdG8gYmVsaWV2ZSB0aGF0IHRoZSBpc3N1ZXMNCjxi cj4NCiZndDsgcHJlc2VudGVkIG9ubHkgbWFuaWZlc3QgdGhlbXNlbHZlcyBpbiB0aG9zZSBwcmVj aXNlIHNjZW5hcmlvcyAtIDxicj4NCiZndDsgd2hpY2ggZGVmaW5pdGVseSBpc24ndCB0aGUgY2Fz ZS4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBKUCZndDsgc2VlIHRoZSBwcmV2aW91 cyBjb21tZW50IGFuZCB0ZWxsIHVzIHdoYXQgeW91IHRoaW5rOyB3ZQ0KY291bGQgPGJyPg0KJmd0 OyBwcm92aWRlIG90aGVyIGV4YW1wbGVzLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 IE5vdGUgdGhhdCB3ZSBkbyBub3Qgb3Bwb3NlIHRvIGFza2luZyB0byB0aGUgV0c7IHdlIGp1c3Qg cmVxdWVzdA0KPGJyPg0KJmd0OyB5b3UgZmlyc3QgdG8gYWRkIGFkZGl0aW9uYWwgaW5mb3JtYXRp b24gdG8gcHJvY2VlZCBmb3J3YXJkLiA8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IHRo YW5rcy4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBKUCBhbmQgTWljaGFlbC4gPGJy Pg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBKUC4gPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBCZXN0LCA8YnI+DQomZ3Q7ICZndDsmZ3Q7 IDxicj4NCiZndDsgJmd0OyZndDsgVGhvbWFzIDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyZndDsgVGhhbmtzLiA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7 ICZndDsmZ3Q7Jmd0OyBKUCBhbmQgTWljaGFlbC4gPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsgPGJy Pg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsmZ3Q7Jmd0OyBCZXN0 LCA8YnI+DQomZ3Q7ICZndDsmZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7Jmd0OyZndDsmZ3Q7 IFRob21hcywgVWxyaWNoLCBZdWljaGksIEppYXppIGFuZCBBeGVsIDxicj4NCiZndDsgJmd0OyZn dDsmZ3Q7IDxicj4NCiZndDsgJmd0OyZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyA8YnI+DQom Z3Q7ICZndDsgUm9sbCBtYWlsaW5nIGxpc3QgPGJyPg0KJmd0OyAmZ3Q7IFJvbGxAaWV0Zi5vcmcg PGJyPg0KJmd0OyAmZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9yb2xsPjx0dD48Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9yb2xsPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+ DQo8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18gPGJyPg0KJmd0OyBSb2xs IG1haWxpbmcgbGlzdCA8YnI+DQomZ3Q7IFJvbGxAaWV0Zi5vcmcgPGJyPg0KJmd0OyA8L2ZvbnQ+ PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbD48 dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9s bDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPg0KPGJyPg0KJmd0OyBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXyA8YnI+DQomZ3Q7IFJvbGwgbWFp bGluZyBsaXN0IDxicj4NCiZndDsgUm9sbEBpZXRmLm9yZyA8YnI+DQomZ3Q7IDwvZm9udD48L3R0 PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsPjx0dD48 Zm9udCBzaXplPTI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsPC9m b250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+DQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IFJv bGwgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBSb2xsQGlldGYub3JnPGJyPg0KJmd0OyA8L2ZvbnQ+ PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbD48 dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9s bDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD48L3R0Pg08cD48 L3A+Cgo8cD48YnI+CkNlIG1lc3NhZ2UgZXQgdG91dGVzIGxlcyBwacOoY2VzIGpvaW50ZXMgKGNp LWFwcsOocyBsZSAnTWVzc2FnZScpIHNvbnQgw6l0YWJsaXMgw6AgbCdpbnRlbnRpb24gZXhjbHVz aXZlIGRlcyBkZXN0aW5hdGFpcmVzIGV0IGxlcyBpbmZvcm1hdGlvbnMgcXVpIHkgZmlndXJlbnQg c29udCBzdHJpY3RlbWVudCBjb25maWRlbnRpZWxsZXMuIFRvdXRlIHV0aWxpc2F0aW9uIGRlIGNl IE1lc3NhZ2Ugbm9uIGNvbmZvcm1lIMOgIHNhIGRlc3RpbmF0aW9uLCB0b3V0ZSBkaWZmdXNpb24g b3UgdG91dGUgcHVibGljYXRpb24gdG90YWxlIG91IHBhcnRpZWxsZSwgZXN0IGludGVyZGl0ZSBz YXVmIGF1dG9yaXNhdGlvbiBleHByZXNzZS48L3A+Cgo8cD5TaSB2b3VzIG4nw6p0ZXMgcGFzIGxl IGRlc3RpbmF0YWlyZSBkZSBjZSBNZXNzYWdlLCBpbCB2b3VzIGVzdCBpbnRlcmRpdCBkZSBsZSBj b3BpZXIsIGRlIGxlIGZhaXJlIHN1aXZyZSwgZGUgbGUgZGl2dWxndWVyIG91IGQnZW4gdXRpbGlz ZXIgdG91dCBvdSBwYXJ0aWUuIFNpIHZvdXMgYXZleiByZcOndSBjZSBNZXNzYWdlIHBhciBlcnJl dXIsIG1lcmNpIGRlIGxlIHN1cHByaW1lciBkZSB2b3RyZSBzeXN0w6htZSwgYWluc2kgcXVlIHRv dXRlcyBzZXMgY29waWVzLCBldCBkZSBuJ2VuIGdhcmRlciBhdWN1bmUgdHJhY2Ugc3VyIHF1ZWxx dWUgc3VwcG9ydCBxdWUgY2Ugc29pdC4gTm91cyB2b3VzIHJlbWVyY2lvbnMgw6lnYWxlbWVudCBk J2VuIGF2ZXJ0aXIgaW1tw6lkaWF0ZW1lbnQgbCdleHDDqWRpdGV1ciBwYXIgcmV0b3VyIGR1IG1l c3NhZ2UuPC9wPgoKPHA+SWwgZXN0IGltcG9zc2libGUgZGUgZ2FyYW50aXIgcXVlIGxlcyBjb21t dW5pY2F0aW9ucyBwYXIgbWVzc2FnZXJpZSDDqWxlY3Ryb25pcXVlIGFycml2ZW50IGVuIHRlbXBz IHV0aWxlLCBzb250IHPDqWN1cmlzw6llcyBvdSBkw6ludcOpZXMgZGUgdG91dGUgZXJyZXVyIG91 IHZpcnVzLjxicj4KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXzwvcD4KCjxwPlRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzICh0aGUgJ01l c3NhZ2UnKSBhcmUgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2Vlcy4gVGhlIGluZm9y bWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIE1lc3NhZ2UgaXMgY29uZmlkZW50aWFsLiBBbnkgdXNl IG9mIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIE1lc3NhZ2Ugbm90IGluIGFjY29yZCB3 aXRoIGl0cyBwdXJwb3NlLCBhbnkgZGlzc2VtaW5hdGlvbiBvciBkaXNjbG9zdXJlLCBlaXRoZXIg d2hvbGUgb3IgcGFydGlhbCwgaXMgcHJvaGliaXRlZCBleGNlcHQgZm9ybWFsIGFwcHJvdmFsLjwv cD4KCjxwPklmIHlvdSBhcmUgbm90IHRoZSBhZGRyZXNzZWUsIHlvdSBtYXkgbm90IGNvcHksIGZv cndhcmQsIGRpc2Nsb3NlIG9yIHVzZSBhbnkgcGFydCBvZiBpdC4gSWYgeW91IGhhdmUgcmVjZWl2 ZWQgdGhpcyBtZXNzYWdlIGluIGVycm9yLCBwbGVhc2UgZGVsZXRlIGl0IGFuZCBhbGwgY29waWVz IGZyb20geW91ciBzeXN0ZW0gYW5kIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IHJl dHVybiBtZXNzYWdlLjwvcD4KCjxwPkUtbWFpbCBjb21tdW5pY2F0aW9uIGNhbm5vdCBiZSBndWFy YW50ZWVkIHRvIGJlIHRpbWVseSBzZWN1cmUsIGVycm9yIG9yIHZpcnVzLWZyZWUuPC9wPg== --=_alternative 006C539AC1257A00_=-- From c.chauvenet@watteco.com Wed May 16 15:28:50 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D17D511E8073 for ; Wed, 16 May 2012 15:28:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.04 X-Spam-Level: X-Spam-Status: No, score=-6.04 tagged_above=-999 required=5 tests=[AWL=1.559, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnUy69bn98QR for ; Wed, 16 May 2012 15:28:49 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe001.messaging.microsoft.com [216.32.180.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0C6C111E8072 for ; Wed, 16 May 2012 15:28:48 -0700 (PDT) Received: from mail157-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE002.bigfish.com (10.7.40.22) with Microsoft SMTP Server id 14.1.225.23; Wed, 16 May 2012 22:28:41 +0000 Received: from mail157-va3 (localhost [127.0.0.1]) by mail157-va3-R.bigfish.com (Postfix) with ESMTP id 48C811601D4; Wed, 16 May 2012 22:28:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VPS-33(zz9371Ic89bh1dbaI1432N1418I98dK1447Izz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h946hd25he5bh) Received: from mail157-va3 (localhost.localdomain [127.0.0.1]) by mail157-va3 (MessageSwitch) id 133720731838440_23772; Wed, 16 May 2012 22:28:38 +0000 (UTC) Received: from VA3EHSMHS005.bigfish.com (unknown [10.7.14.236]) by mail157-va3.bigfish.com (Postfix) with ESMTP id E34ED2A004A; Wed, 16 May 2012 22:28:37 +0000 (UTC) Received: from DBXPRD0510HT001.eurprd05.prod.outlook.com (157.56.252.165) by VA3EHSMHS005.bigfish.com (10.7.99.15) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 16 May 2012 22:28:37 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.244]) by DBXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.67.164]) with mapi id 14.16.0152.000; Wed, 16 May 2012 22:28:42 +0000 From: C Chauvenet To: Thomas Heide Clausen Thread-Topic: [Roll] Way forward for draft-clausen-lln-rpl-experiences Thread-Index: AQHNLz7f4nHZNQpKzkGVpF0j12dI45bMCZgAgABRMICAAA+CgIAAE3eAgAAPKgCAABvrgIAADc4AgABRXQA= Date: Wed, 16 May 2012 22:28:42 +0000 Message-ID: <04348A3C-F9EC-4427-AC44-17600405331C@watteco.com> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <22B18A3C-B327-4AD6-9D94-901CF225BE98@watteco.com> <0AA713FC-2C91-41E4-80BF-3DA3FF450324@thomasclausen.org> <4818180C-19D8-4C01-A65C-04DD47B9FCB2@watteco.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.4.7] Content-Type: text/plain; charset="Windows-1252" Content-ID: <546B2C7564D7CA4FBEA2E79270138C7D@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 22:28:50 -0000 Thomas,=20 Le 16 mai 2012 =E0 19:37, Thomas Heide Clausen a =E9crit : > Dear Cedric, >=20 > On May 16, 2012, at 18:48 , C Chauvenet wrote: >=20 >> Thomas, >> See inline, =20 >>=20 >> Le 16 mai 2012 =E0 17:08, Thomas Heide Clausen a =E9crit : >>=20 >>> Dear Cedric, >>>=20 >>> Thank you for your email. Comments below. >>>=20 >>> On 16 May 2012, at 16:13, C Chauvenet wrote: >>>=20 >>>> Hi,=20 >>>>=20 >>>> I definitely agree that implementation feedback is always good to know= , so your experiences are welcomed. >>>>=20 >>>> I also think that problems investigations need a complete and exact vi= ew, so I would encourage you to put much more details about the scenario an= d the environment where you experimentations took place. >>>> For instance, I would enjoy a "RPL Implementation Description" section= in you draft listing the hardware your used, your RPL parameters, the RPL = drafts and mechanisms implemented, your OS etc... >>>=20 >>> As I indicated to JP already: >>>=20 >>> 1) this draft is not "just" based on a single scenario, environment or= implementation=20 >>> (and, therefore, not "just" based on a single test).=20 >>=20 >> Does it means that your run multiple scenarios ?=20 >> That would be great. >>=20 >=20 > As indicated elsewhere, yes. Although its details are immaterial to this = discussion, >=20 >>>=20 >>> 2) the observations that we made during the test_S_ served to make us = look at the RPL >>> RFC again, to explain our observations and to generalize them from the= written word >>> of that RFC. >>>=20 >>> Therefore, I do not think that any such description would bring anythin= g (other than entropy and delay) to the process. The RPL RFC and this I-D i= s more than sufficient. >>>=20 >>> As to what features were implemented, that is easy to answer: the RPL R= FC (except for security) to the letter and with the parameters suggested th= ere, and OF0. However, even the parameters are immaterial for the observati= ons listed in this I-D. >>=20 >> I think we are progressing on the definition of your RPL implementation = : could you also precise what part of the RPL spec you have implemented ? e= g. What mode of Operation and why, what options did you choose to include i= n DIO messages, your metrics .... >>=20 >=20 > 1) All the relevant details are included in the I-D > 2) Again, the observations in that I-D can be made from looking (now that= we know what to look for) > in the RPL RFC > 3) The experiments only served to help us see "what to look for" in the R= PL RFC. > 4) See also email that I recently sent to JP. >=20 >>>=20 >>>> If I read a paper with orthogonal observations with the same level of = details as in your draft, then how could I forge my opinion ? >>>=20 >>> I'd suggest reading the indicated parts of the RPL RFC conjointly with = this I-D. Again, the observations that we present in this I-D make exclusiv= e reference to RPL, and not to a specific implementation or deployment. >>>=20 >>>> Looking at this draft, it seems that it gathers lots of previous discu= ssions that occurred during the past year on various mailing lists, and IET= F meetings. >>>>=20 >>>> Does your experimentations takes care about these recommendations ? >>>=20 >>> Again, the issues raised in this I-D are based on what can be observed = from the RPL RFC.=20 >>>=20 >>> If there are additional considerations required (which you seem to indi= cate to be the case) which are not reflected in the RPL RFC, in order to ov= ercome the issues raised, then that indeed should be a big problem for the = IETF and for ROLL.... >>=20 >> These recommendations were for the problems you pointed out in *Your* im= plementation. >> Of course if other implementers are facing to the same problems, they co= uld rely on it, but I have not heard about similar problems outside your la= b from now. >=20 > These are not implementation problems, these are artifacts from the RPL R= FC design choices. >=20 >>>=20 >>>> If not, does your draft mention the propositions that have been made t= o address the problems you point out in your draft ? >>>> I think it could be worth to leverage on these previous discussions. >>>=20 >>> I firmly disagree. The IETF and ROLL has published an RFC - that's what= this I-D discusses.=20 >>>=20 >>> Discussing what may have been proposed in other media would be entirely= out of scope. >>=20 >> Again, this is not related to the RPL RFC but *your* implementation that= received some guidance regarding its problems. >> The RPL RFC should not include tips for your implementation, but your im= plementation and your draft should pay attention to the tips given to you. >>=20 >=20 > This has nothing to do with "tips for [my] implementation whatsoever. See= examples I gave in reply to JP. >=20 >=20 >>>=20 >>>> Your draft is a list of Description and Observations. >>>> Maybe you could add a "Resolution Proposal" section for each problem, = gathering previous discussion and your own proposals ? >>>=20 >>> Nope. That's not the objective of this I-D. >>=20 >> That's too bad, this is what all readers of this draft are looking for ! >=20 > It would be great to have that, so please write such a draft, addressing = the issues that this I-D has presented. Mukul seems to work on it. I guess a good mail browser could do a big part of the job. >=20 > I am personally a great fan also of interoperability reports (something w= hich ROLL doesn't have either and which is not the point of this I-D either= ) Me too. The only "public" interop event I remember took place during IETF 77 in Mar= ch 2010. 5 differents companies were able to form a single DODAG using an early vers= ion of the RPL specification. Of course the intend of this event was not to do an exhaustive test of the = RPL mechanisms but prove that the core design is correctly working. This is not surprising, given that some mechanisms used in RPL are used in = numerous commercial solution for a while. You should also have knowledge about the great effort of the Zigbee Allianc= e who is running interop events very regularly. RPL is the default routing protocol of the future Zigbee IP stack, and some= details have been given by robert craigie at the LWIG session of last IETF= . Do you seriously think that these interop events occuring every 2 or 3 mont= hs and involving most of the major companies in WSN would not have detect i= f something were wrong with the RPL design ? If you think that you are not able to figure out yourself the problems you = see in RPL, go buy some commercial solutions ;-) >=20 >> Without offense, saying "this is bad" without a better proposition seems= like half-work !=20 >> And this is true for most of the discussion topics in life, far away fro= m RPL ! >=20 >>=20 >>> I would venture that if the WG is serious about applicability statement= s, then those applicability statements would be the place for discussion of= "how this issue, raised in this I-D, is addressed or moot for a given depl= oyment". >>>=20 >>>> Identifying what is wrong in your implementation >>>=20 >>> Considering that these observations are not implementation-specific, bu= t are directly on the RPL RFC, I venture the observations that there's noth= ing "wrong in my implementation" here. >>>=20 >>=20 >> As a general comment : RPL is a routing protocol targeted for a very wid= e application area.=20 >> Some may think this is good because it covers a lot of needs. >> Some may think it is bad because it is wide and not specific enough for = their application. >> Wathever your position, these two arguments are valid, this is all a mat= ter of viewpoint and tradeoff. >=20 > I disagree here, Cedric, but this thread is not the place for that partic= ular discussion. I cannot see how you could not be inline with these statement, but anyway l= et's get back in the arena. >> So, because RPL is wide enough for multiple application, you have to tak= e some time to tune it correctly, according to your application. >=20 > I disagree here, Cedric, but this thread is not the place for that partic= ular discussion. This I-D does *not* discuss a specific application or depl= oyment, but merely reflects on RPL, as published by the ROLL working group. >=20 >> One simple choice that every RPL implementers will ave to answer is : Us= e Storing or Non Storing Mode ? This is a fondamental design choice that ca= nnot be made outside a scenario consideration. >=20 > I agree here. >=20 > And, this I-D provides some observations - for example about storage requ= irements, and about requirements for all RPL routers in (for example, for s= toring node) the case that the DODAG root can fail and floating DODAGs crea= ted. >=20 > This has nothing to do with a specific implementation, deployment, experi= ment, scenario or application, but is an artifact of a fundamental design c= hoice made in RPL. This argument relies for more than a year on a research paper that is not i= nline with your statement, as discussed with the authors during IETF events= . The memory available to store routes simply relates to the memory available= in your mote, and this is directly given by the hardware you use. So the routing table size is more linked to the hardware than linked to the= RPL mechanisms. If you need more routing entries, buy a hardware with more memory, or optim= ize the way you store routing entries. Is this problem really an "artifact of a fundamental choice made in RPL" or= a generic routing protocol problem ? I guess Mukul will give some thoughts on this point, as It has been already= discussed. C=E9dric. >=20 >> Be sure that there is no magic RPL tuning that works for all, but multip= le fine RPL tuning for multiple applications. >> I honestly cannot believe in generic results given the incredibly variet= y of tuning that RPL can have. >=20 > This is, again, not a matter of "tuning of parameters" at all. That's not= what the I-D describes, or aims at describing. >=20 >> So my final position is that we disagree on the need of more details in = your experiments. >=20 > I'm afraid that I disagree for this I-D. That's not the point of it, and = I think that it is fairly clear in the I-D that it's not (as well as it is = clear what the point is, and what the goals are for it) >=20 > I think that it would be interesting to have another I-D describe paramet= er tunings etc for a given application. I would expect that to be part of w= hat the applicability statements were supposed to do. It's, however, still = not in this I-D that it should be done. >=20 > Thomas >=20 >> C=E9dric. >>=20 >>> Thomas >>>=20 >>>=20 >>>> is a good first step, but the hardest part is to propose some correcti= ons. >>>> Best Regards, >>>>=20 >>>> C=E9dric Chauvenet. >>>>=20 >>>> Le 16 mai 2012 =E0 15:04, JP Vasseur a =E9crit : >>>>=20 >>>>> Dear Thomas, >>>>>=20 >>>>> On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: >>>>>=20 >>>>>> Dear JP and Michael, >>>>>>=20 >>>>>> Thank you for your mail. >>>>>>=20 >>>>>> On May 16, 2012, at 09:18 , JP Vasseur wrote: >>>>>>=20 >>>>>>> Dear Thomas, >>>>>>>=20 >>>>>>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>>>>>>=20 >>>>>>>> Dear JP, Michael, all >>>>>>>>=20 >>>>>>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was present= ed and discussed at the Paris meeting. >>>>>>>>=20 >>>>>>>> The authors consider the document complete and "done", and are loo= king to take it forward in the IETF=20 >>>>>>>> process for publication as "Informational RFC" in the very near fu= ture.=20 >>>>>>>>=20 >>>>>>>> We would therefore like to ask the WG chairs, if the ROLL WG is wi= lling to accept and progress this=20 >>>>>>>> document towards publication? >>>>>>>=20 >>>>>>> Thanks for your suggestion. So far we haven't see a lot of discussi= on/interest from the WG but your request is >>>>>>> perfectly fair. >>>>>>=20 >>>>>> Thank you - I aim to be fair. >>>>>>=20 >>>>>>> So far there are no details on the scenarios and testing environmen= ts that led to the issues that=20 >>>>>>> you reported, thus I would suggest you to first include them so tha= t people interested could be able to reproduce >>>>>>> it. Once the drat is updated, we'll be happy to pool the WG. >>>>>>>=20 >>>>>>> Does that make sense ? >>>>>>=20 >>>>>> Not really. Let me explain my disagreement. >>>>>>=20 >>>>>> We tried RPL (and, I note, several different independent implementat= ions of RPL) in a number of different scenarios and deployments, and observ= ed the behaviors exhibited - noting that what we observed across the differ= ent implementations, scenarios and deployments was fairly universal. >>>>>>=20 >>>>>> We then went back to the specification, to understand these behavior= s in detail, and understand their universality as independent from a specif= ic scenario or deployment or implementation - but rather, as artifacts of t= he RPL protocol design. >>>>>>=20 >>>>>> We therefore believe that _any_ deployment, scenario or testing envi= ronment of RPL needs to pay attention to the issues presented, and find a w= ay of addressing them. The way of addressing these issues in a given deploy= ment or scenario would be appropriate for an "applicability statement" for = that deployment or scenario. >>>>>=20 >>>>> JP> Thanks for the clarification; that being said, for the WG to make= sure that nothing is "scenario" dependent and the outcome could indeed app= ly to all scenarios, >>>>> it might be worth being more explicit. For example, you pointed out t= o the MTU issue, to which I mentioned that 15.4g would bring a solution, so= you may want to=20 >>>>> explain that you did not use 15.4g and there are a number of such exa= mples =85. >>>>>=20 >>>>>>=20 >>>>>> (For example, a deployment using only L2s which provides guaranteed = bi-directional links for L3 would address this by in the applicability sta= tement stating "As all L2-links are guaranteed bi-directional, this address= es the issues raised in section 9 in draft-clausen-lln-rpl-experiences".) >>>>>>=20 >>>>>> Thus, we believe that it would actually be misleading (not to mentio= n, unnecessarily verbose) to put the "details on the scenarios and testing = environments" into this I-D. >>>>>>=20 >>>>>> Doing so would mislead the reader to believe that the issues present= ed only manifest themselves in those precise scenarios - which definitely i= sn't the case. >>>>>=20 >>>>> JP> see the previous comment and tell us what you think; we could pro= vide other examples. >>>>>=20 >>>>> Note that we do not oppose to asking to the WG; we just request you f= irst to add additional information to proceed forward. >>>>>=20 >>>>> thanks. >>>>>=20 >>>>> JP and Michael. >>>>>=20 >>>>> JP. >>>>>=20 >>>>>>=20 >>>>>> Best, >>>>>>=20 >>>>>> Thomas >>>>>>=20 >>>>>>> Thanks. >>>>>>>=20 >>>>>>> JP and Michael. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Best, >>>>>>>>=20 >>>>>>>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >=20 >=20 From axel-ietf@axelcdv.com Wed May 16 16:46:01 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5E089E8027 for ; Wed, 16 May 2012 16:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.265 X-Spam-Level: X-Spam-Status: No, score=-6.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFQO79eluuHL for ; Wed, 16 May 2012 16:46:00 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 47A7A9E8020 for ; Wed, 16 May 2012 16:46:00 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id D1C4E557FED for ; Wed, 16 May 2012 16:45:59 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 4500C1C08C5; Wed, 16 May 2012 16:45:59 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [192.168.1.107] (Cs-136-215.CS.UCLA.EDU [131.179.136.215]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id CFD3C1C0105; Wed, 16 May 2012 16:45:58 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=windows-1252 From: Axel Colin de Verdiere In-Reply-To: <04348A3C-F9EC-4427-AC44-17600405331C@watteco.com> Date: Wed, 16 May 2012 16:44:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4944ECBE-792F-4B88-815B-0867E8532F35@axelcdv.com> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <22B18A3C-B327-4AD6-9D94-901CF225BE98@watteco.com> <0AA713FC-2C91-41E4-80BF-3DA3FF450324@thomasclausen.org> <4818180C-19D8-4C01-A65C-04DD47B9FCB2@watteco.com> <04348A3C-F9EC-4427-AC44-17600405331C@watteco.com> To: C Chauvenet X-Mailer: Apple Mail (2.1084) Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 May 2012 23:46:01 -0000 Dear Cedric, On May 16, 2012, at 3:28 PM, C Chauvenet wrote: > Thomas,=20 >=20 > Le 16 mai 2012 =E0 19:37, Thomas Heide Clausen a =E9crit : >=20 >> Dear Cedric, >>=20 >> On May 16, 2012, at 18:48 , C Chauvenet wrote: >>=20 >>> Thomas, >>> See inline, =20 >>>=20 >>> Le 16 mai 2012 =E0 17:08, Thomas Heide Clausen a =E9crit : >>>=20 >>>> Dear Cedric, >>>>=20 >>>> Thank you for your email. Comments below. >>>>=20 >>>> On 16 May 2012, at 16:13, C Chauvenet = wrote: >>>>=20 >>>>> Hi,=20 >>>>>=20 >>>>> I definitely agree that implementation feedback is always good to = know, so your experiences are welcomed. >>>>>=20 >>>>> I also think that problems investigations need a complete and = exact view, so I would encourage you to put much more details about the = scenario and the environment where you experimentations took place. >>>>> For instance, I would enjoy a "RPL Implementation Description" = section in you draft listing the hardware your used, your RPL = parameters, the RPL drafts and mechanisms implemented, your OS etc... >>>>=20 >>>> As I indicated to JP already: >>>>=20 >>>> 1) this draft is not "just" based on a single scenario, = environment or implementation=20 >>>> (and, therefore, not "just" based on a single test).=20 >>>=20 >>> Does it means that your run multiple scenarios ?=20 >>> That would be great. >>>=20 >>=20 >> As indicated elsewhere, yes. Although its details are immaterial to = this discussion, >>=20 >>>>=20 >>>> 2) the observations that we made during the test_S_ served = to make us look at the RPL >>>> RFC again, to explain our observations and to generalize them = from the written word >>>> of that RFC. >>>>=20 >>>> Therefore, I do not think that any such description would bring = anything (other than entropy and delay) to the process. The RPL RFC and = this I-D is more than sufficient. >>>>=20 >>>> As to what features were implemented, that is easy to answer: the = RPL RFC (except for security) to the letter and with the parameters = suggested there, and OF0. However, even the parameters are immaterial = for the observations listed in this I-D. >>>=20 >>> I think we are progressing on the definition of your RPL = implementation : could you also precise what part of the RPL spec you = have implemented ? eg. What mode of Operation and why, what options did = you choose to include in DIO messages, your metrics .... >>>=20 >>=20 >> 1) All the relevant details are included in the I-D >> 2) Again, the observations in that I-D can be made from looking = (now that we know what to look for) >> in the RPL RFC >> 3) The experiments only served to help us see "what to look for" in = the RPL RFC. >> 4) See also email that I recently sent to JP. >>=20 >>>>=20 >>>>> If I read a paper with orthogonal observations with the same level = of details as in your draft, then how could I forge my opinion ? >>>>=20 >>>> I'd suggest reading the indicated parts of the RPL RFC conjointly = with this I-D. Again, the observations that we present in this I-D make = exclusive reference to RPL, and not to a specific implementation or = deployment. >>>>=20 >>>>> Looking at this draft, it seems that it gathers lots of previous = discussions that occurred during the past year on various mailing lists, = and IETF meetings. >>>>>=20 >>>>> Does your experimentations takes care about these recommendations = ? >>>>=20 >>>> Again, the issues raised in this I-D are based on what can be = observed from the RPL RFC.=20 >>>>=20 >>>> If there are additional considerations required (which you seem to = indicate to be the case) which are not reflected in the RPL RFC, in = order to overcome the issues raised, then that indeed should be a big = problem for the IETF and for ROLL.... >>>=20 >>> These recommendations were for the problems you pointed out in = *Your* implementation. >>> Of course if other implementers are facing to the same problems, = they could rely on it, but I have not heard about similar problems = outside your lab from now. >>=20 >> These are not implementation problems, these are artifacts from the = RPL RFC design choices. >>=20 >>>>=20 >>>>> If not, does your draft mention the propositions that have been = made to address the problems you point out in your draft ? >>>>> I think it could be worth to leverage on these previous = discussions. >>>>=20 >>>> I firmly disagree. The IETF and ROLL has published an RFC - that's = what this I-D discusses.=20 >>>>=20 >>>> Discussing what may have been proposed in other media would be = entirely out of scope. >>>=20 >>> Again, this is not related to the RPL RFC but *your* implementation = that received some guidance regarding its problems. >>> The RPL RFC should not include tips for your implementation, but = your implementation and your draft should pay attention to the tips = given to you. >>>=20 >>=20 >> This has nothing to do with "tips for [my] implementation whatsoever. = See examples I gave in reply to JP. >>=20 >>=20 >>>>=20 >>>>> Your draft is a list of Description and Observations. >>>>> Maybe you could add a "Resolution Proposal" section for each = problem, gathering previous discussion and your own proposals ? >>>>=20 >>>> Nope. That's not the objective of this I-D. >>>=20 >>> That's too bad, this is what all readers of this draft are looking = for ! >>=20 >> It would be great to have that, so please write such a draft, = addressing the issues that this I-D has presented. >=20 > Mukul seems to work on it. > I guess a good mail browser could do a big part of the job. >=20 >>=20 >> I am personally a great fan also of interoperability reports = (something which ROLL doesn't have either and which is not the point of = this I-D either) >=20 > Me too. > The only "public" interop event I remember took place during IETF 77 = in March 2010. > 5 differents companies were able to form a single DODAG using an early = version of the RPL specification. > Of course the intend of this event was not to do an exhaustive test of = the RPL mechanisms but prove that the core design is correctly working. > This is not surprising, given that some mechanisms used in RPL are = used in numerous commercial solution for a while. > You should also have knowledge about the great effort of the Zigbee = Alliance who is running interop events very regularly. > RPL is the default routing protocol of the future Zigbee IP stack, and = some details have been given by robert craigie at the LWIG session of = last IETF. > Do you seriously think that these interop events occuring every 2 or 3 = months and involving most of the major companies in WSN would not have = detect if something were wrong with the RPL design ? I would still hope that RPL works for Zigbee since they list it in their = protocol stack, but their interop events do not help much here since = they don't give any public feedback. Furthermore, the only details given = at the LWIG session were that Zigbee uses RPL in non-storing mode, and = that some features had to be turned off (at least from what I can infer = from the presentation and the minutes). As an implementer, I would need = a little bit more detail to know whether (and how) RPL would work for my = application. And even if I were to trust them blindly, what if I wanted = to use RPL in non-storing mode? > If you think that you are not able to figure out yourself the problems = you see in RPL, go buy some commercial solutions ;-) I might be relatively new here, but I wasn't aware the IETF relied on = commercial solutions to fix its standard track protocols... Axel >=20 >=20 >>=20 >>> Without offense, saying "this is bad" without a better proposition = seems like half-work !=20 >>> And this is true for most of the discussion topics in life, far away = from RPL ! >>=20 >>>=20 >>>> I would venture that if the WG is serious about applicability = statements, then those applicability statements would be the place for = discussion of "how this issue, raised in this I-D, is addressed or moot = for a given deployment". >>>>=20 >>>>> Identifying what is wrong in your implementation >>>>=20 >>>> Considering that these observations are not = implementation-specific, but are directly on the RPL RFC, I venture the = observations that there's nothing "wrong in my implementation" here. >>>>=20 >>>=20 >>> As a general comment : RPL is a routing protocol targeted for a very = wide application area.=20 >>> Some may think this is good because it covers a lot of needs. >>> Some may think it is bad because it is wide and not specific enough = for their application. >>> Wathever your position, these two arguments are valid, this is all a = matter of viewpoint and tradeoff. >>=20 >> I disagree here, Cedric, but this thread is not the place for that = particular discussion. >=20 > I cannot see how you could not be inline with these statement, but = anyway let's get back in the arena. >=20 >>> So, because RPL is wide enough for multiple application, you have to = take some time to tune it correctly, according to your application. >>=20 >> I disagree here, Cedric, but this thread is not the place for that = particular discussion. This I-D does *not* discuss a specific = application or deployment, but merely reflects on RPL, as published by = the ROLL working group. >>=20 >>> One simple choice that every RPL implementers will ave to answer is = : Use Storing or Non Storing Mode ? This is a fondamental design choice = that cannot be made outside a scenario consideration. >>=20 >> I agree here. >>=20 >> And, this I-D provides some observations - for example about storage = requirements, and about requirements for all RPL routers in (for = example, for storing node) the case that the DODAG root can fail and = floating DODAGs created. >>=20 >> This has nothing to do with a specific implementation, deployment, = experiment, scenario or application, but is an artifact of a fundamental = design choice made in RPL. >=20 > This argument relies for more than a year on a research paper that is = not inline with your statement, as discussed with the authors during = IETF events. > The memory available to store routes simply relates to the memory = available in your mote, and this is directly given by the hardware you = use. > So the routing table size is more linked to the hardware than linked = to the RPL mechanisms. > If you need more routing entries, buy a hardware with more memory, or = optimize the way you store routing entries. > Is this problem really an "artifact of a fundamental choice made in = RPL" or a generic routing protocol problem ? > I guess Mukul will give some thoughts on this point, as It has been = already discussed. >=20 > C=E9dric. >=20 >>=20 >>> Be sure that there is no magic RPL tuning that works for all, but = multiple fine RPL tuning for multiple applications. >>> I honestly cannot believe in generic results given the incredibly = variety of tuning that RPL can have. >>=20 >> This is, again, not a matter of "tuning of parameters" at all. That's = not what the I-D describes, or aims at describing. >>=20 >>> So my final position is that we disagree on the need of more details = in your experiments. >>=20 >> I'm afraid that I disagree for this I-D. That's not the point of it, = and I think that it is fairly clear in the I-D that it's not (as well as = it is clear what the point is, and what the goals are for it) >>=20 >> I think that it would be interesting to have another I-D describe = parameter tunings etc for a given application. I would expect that to be = part of what the applicability statements were supposed to do. It's, = however, still not in this I-D that it should be done. >>=20 >> Thomas >>=20 >>> C=E9dric. >>>=20 >>>> Thomas >>>>=20 >>>>=20 >>>>> is a good first step, but the hardest part is to propose some = corrections. >>>>> Best Regards, >>>>>=20 >>>>> C=E9dric Chauvenet. >>>>>=20 >>>>> Le 16 mai 2012 =E0 15:04, JP Vasseur a =E9crit : >>>>>=20 >>>>>> Dear Thomas, >>>>>>=20 >>>>>> On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: >>>>>>=20 >>>>>>> Dear JP and Michael, >>>>>>>=20 >>>>>>> Thank you for your mail. >>>>>>>=20 >>>>>>> On May 16, 2012, at 09:18 , JP Vasseur wrote: >>>>>>>=20 >>>>>>>> Dear Thomas, >>>>>>>>=20 >>>>>>>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>>>>>>>=20 >>>>>>>>> Dear JP, Michael, all >>>>>>>>>=20 >>>>>>>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was = presented and discussed at the Paris meeting. >>>>>>>>>=20 >>>>>>>>> The authors consider the document complete and "done", and are = looking to take it forward in the IETF=20 >>>>>>>>> process for publication as "Informational RFC" in the very = near future.=20 >>>>>>>>>=20 >>>>>>>>> We would therefore like to ask the WG chairs, if the ROLL WG = is willing to accept and progress this=20 >>>>>>>>> document towards publication? >>>>>>>>=20 >>>>>>>> Thanks for your suggestion. So far we haven't see a lot of = discussion/interest from the WG but your request is >>>>>>>> perfectly fair. >>>>>>>=20 >>>>>>> Thank you - I aim to be fair. >>>>>>>=20 >>>>>>>> So far there are no details on the scenarios and testing = environments that led to the issues that=20 >>>>>>>> you reported, thus I would suggest you to first include them so = that people interested could be able to reproduce >>>>>>>> it. Once the drat is updated, we'll be happy to pool the WG. >>>>>>>>=20 >>>>>>>> Does that make sense ? >>>>>>>=20 >>>>>>> Not really. Let me explain my disagreement. >>>>>>>=20 >>>>>>> We tried RPL (and, I note, several different independent = implementations of RPL) in a number of different scenarios and = deployments, and observed the behaviors exhibited - noting that what we = observed across the different implementations, scenarios and deployments = was fairly universal. >>>>>>>=20 >>>>>>> We then went back to the specification, to understand these = behaviors in detail, and understand their universality as independent = from a specific scenario or deployment or implementation - but rather, = as artifacts of the RPL protocol design. >>>>>>>=20 >>>>>>> We therefore believe that _any_ deployment, scenario or testing = environment of RPL needs to pay attention to the issues presented, and = find a way of addressing them. The way of addressing these issues in a = given deployment or scenario would be appropriate for an "applicability = statement" for that deployment or scenario. >>>>>>=20 >>>>>> JP> Thanks for the clarification; that being said, for the WG to = make sure that nothing is "scenario" dependent and the outcome could = indeed apply to all scenarios, >>>>>> it might be worth being more explicit. For example, you pointed = out to the MTU issue, to which I mentioned that 15.4g would bring a = solution, so you may want to=20 >>>>>> explain that you did not use 15.4g and there are a number of such = examples =85. >>>>>>=20 >>>>>>>=20 >>>>>>> (For example, a deployment using only L2s which provides = guaranteed bi-directional links for L3 would address this by in the = applicability statement stating "As all L2-links are guaranteed = bi-directional, this addresses the issues raised in section 9 in = draft-clausen-lln-rpl-experiences".) >>>>>>>=20 >>>>>>> Thus, we believe that it would actually be misleading (not to = mention, unnecessarily verbose) to put the "details on the scenarios and = testing environments" into this I-D. >>>>>>>=20 >>>>>>> Doing so would mislead the reader to believe that the issues = presented only manifest themselves in those precise scenarios - which = definitely isn't the case. >>>>>>=20 >>>>>> JP> see the previous comment and tell us what you think; we could = provide other examples. >>>>>>=20 >>>>>> Note that we do not oppose to asking to the WG; we just request = you first to add additional information to proceed forward. >>>>>>=20 >>>>>> thanks. >>>>>>=20 >>>>>> JP and Michael. >>>>>>=20 >>>>>> JP. >>>>>>=20 >>>>>>>=20 >>>>>>> Best, >>>>>>>=20 >>>>>>> Thomas >>>>>>>=20 >>>>>>>> Thanks. >>>>>>>>=20 >>>>>>>> JP and Michael. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Best, >>>>>>>>>=20 >>>>>>>>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From c.chauvenet@watteco.com Wed May 16 17:11:44 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB3F21F87EE for ; Wed, 16 May 2012 17:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.127 X-Spam-Level: X-Spam-Status: No, score=-6.127 tagged_above=-999 required=5 tests=[AWL=1.472, BAYES_00=-2.599, GB_I_INVITATION=-2, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tZmnH8pUokDa for ; Wed, 16 May 2012 17:11:43 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe005.messaging.microsoft.com [213.199.154.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5179821F87ED for ; Wed, 16 May 2012 17:11:42 -0700 (PDT) Received: from mail37-db3-R.bigfish.com (10.3.81.252) by DB3EHSOBE002.bigfish.com (10.3.84.22) with Microsoft SMTP Server id 14.1.225.23; Thu, 17 May 2012 00:11:31 +0000 Received: from mail37-db3 (localhost [127.0.0.1]) by mail37-db3-R.bigfish.com (Postfix) with ESMTP id 12F7618020B; Thu, 17 May 2012 00:11:31 +0000 (UTC) X-SpamScore: -33 X-BigFish: VPS-33(zz9371Ic89bh1dbaI1432N1418I98dK1447Izz1202hzz1033IL8275bh8275dhz2dh2a8h668h839h946hd25he5bh) X-Forefront-Antispam-Report: CIP:157.56.252.165; KIP:(null); UIP:(null); IPV:NLI; H:DBXPRD0510HT001.eurprd05.prod.outlook.com; RD:none; EFVD:NLI Received: from mail37-db3 (localhost.localdomain [127.0.0.1]) by mail37-db3 (MessageSwitch) id 1337213488994373_12790; Thu, 17 May 2012 00:11:28 +0000 (UTC) Received: from DB3EHSMHS016.bigfish.com (unknown [10.3.81.233]) by mail37-db3.bigfish.com (Postfix) with ESMTP id E97E44A0060; Thu, 17 May 2012 00:11:28 +0000 (UTC) Received: from DBXPRD0510HT001.eurprd05.prod.outlook.com (157.56.252.165) by DB3EHSMHS016.bigfish.com (10.3.87.116) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 17 May 2012 00:11:28 +0000 Received: from DBXPRD0510MB395.eurprd05.prod.outlook.com ([169.254.7.244]) by DBXPRD0510HT001.eurprd05.prod.outlook.com ([10.255.67.164]) with mapi id 14.16.0152.000; Thu, 17 May 2012 00:11:35 +0000 From: C Chauvenet To: Axel Colin de Verdiere Thread-Topic: [Roll] Way forward for draft-clausen-lln-rpl-experiences Thread-Index: AQHNLz7f4nHZNQpKzkGVpF0j12dI45bMCZgAgABRMICAAA+CgIAAE3eAgAAPKgCAABvrgIAADc4AgABRXQCAABU4gIAAB4SA Date: Thu, 17 May 2012 00:11:34 +0000 Message-ID: <0E358659-C852-4F3F-A53C-A96CF244A5E5@watteco.com> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <22B18A3C-B327-4AD6-9D94-901CF225BE98@watteco.com> <0AA713FC-2C91-41E4-80BF-3DA3FF450324@thomasclausen.org> <4818180C-19D8-4C01-A65C-04DD47B9FCB2@watteco.com> <04348A3C-F9EC-4427-AC44-17600405331C@watteco.com> <4944ECBE-792F-4B88-815B-0867E8532F35@axelcdv.com> In-Reply-To: <4944ECBE-792F-4B88-815B-0867E8532F35@axelcdv.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.3.4.11] Content-Type: text/plain; charset="Windows-1252" Content-ID: <08771081767F0B48A782B26D338D1D73@eurprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: watteco.com Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 00:11:44 -0000 Axel,=20 Le 17 mai 2012 =E0 01:44, Axel Colin de Verdiere a =E9crit : > Dear Cedric, >=20 > On May 16, 2012, at 3:28 PM, C Chauvenet wrote: >=20 >> Thomas,=20 >>=20 >> Le 16 mai 2012 =E0 19:37, Thomas Heide Clausen a =E9crit : >>=20 >>> Dear Cedric, >>>=20 >>> On May 16, 2012, at 18:48 , C Chauvenet wrote: >>>=20 >>>> Thomas, >>>> See inline, =20 >>>>=20 >>>> Le 16 mai 2012 =E0 17:08, Thomas Heide Clausen a =E9crit : >>>>=20 >>>>> Dear Cedric, >>>>>=20 >>>>> Thank you for your email. Comments below. >>>>>=20 >>>>> On 16 May 2012, at 16:13, C Chauvenet wrote= : >>>>>=20 >>>>>> Hi,=20 >>>>>>=20 >>>>>> I definitely agree that implementation feedback is always good to kn= ow, so your experiences are welcomed. >>>>>>=20 >>>>>> I also think that problems investigations need a complete and exact = view, so I would encourage you to put much more details about the scenario = and the environment where you experimentations took place. >>>>>> For instance, I would enjoy a "RPL Implementation Description" secti= on in you draft listing the hardware your used, your RPL parameters, the RP= L drafts and mechanisms implemented, your OS etc... >>>>>=20 >>>>> As I indicated to JP already: >>>>>=20 >>>>> 1) this draft is not "just" based on a single scenario, environment = or implementation=20 >>>>> (and, therefore, not "just" based on a single test).=20 >>>>=20 >>>> Does it means that your run multiple scenarios ?=20 >>>> That would be great. >>>>=20 >>>=20 >>> As indicated elsewhere, yes. Although its details are immaterial to thi= s discussion, >>>=20 >>>>>=20 >>>>> 2) the observations that we made during the test_S_ served to make u= s look at the RPL >>>>> RFC again, to explain our observations and to generalize them from t= he written word >>>>> of that RFC. >>>>>=20 >>>>> Therefore, I do not think that any such description would bring anyth= ing (other than entropy and delay) to the process. The RPL RFC and this I-D= is more than sufficient. >>>>>=20 >>>>> As to what features were implemented, that is easy to answer: the RPL= RFC (except for security) to the letter and with the parameters suggested = there, and OF0. However, even the parameters are immaterial for the observa= tions listed in this I-D. >>>>=20 >>>> I think we are progressing on the definition of your RPL implementatio= n : could you also precise what part of the RPL spec you have implemented ?= eg. What mode of Operation and why, what options did you choose to include= in DIO messages, your metrics .... >>>>=20 >>>=20 >>> 1) All the relevant details are included in the I-D >>> 2) Again, the observations in that I-D can be made from looking (now th= at we know what to look for) >>> in the RPL RFC >>> 3) The experiments only served to help us see "what to look for" in the= RPL RFC. >>> 4) See also email that I recently sent to JP. >>>=20 >>>>>=20 >>>>>> If I read a paper with orthogonal observations with the same level o= f details as in your draft, then how could I forge my opinion ? >>>>>=20 >>>>> I'd suggest reading the indicated parts of the RPL RFC conjointly wit= h this I-D. Again, the observations that we present in this I-D make exclus= ive reference to RPL, and not to a specific implementation or deployment. >>>>>=20 >>>>>> Looking at this draft, it seems that it gathers lots of previous dis= cussions that occurred during the past year on various mailing lists, and I= ETF meetings. >>>>>>=20 >>>>>> Does your experimentations takes care about these recommendations ? >>>>>=20 >>>>> Again, the issues raised in this I-D are based on what can be observe= d from the RPL RFC.=20 >>>>>=20 >>>>> If there are additional considerations required (which you seem to in= dicate to be the case) which are not reflected in the RPL RFC, in order to = overcome the issues raised, then that indeed should be a big problem for th= e IETF and for ROLL.... >>>>=20 >>>> These recommendations were for the problems you pointed out in *Your* = implementation. >>>> Of course if other implementers are facing to the same problems, they = could rely on it, but I have not heard about similar problems outside your = lab from now. >>>=20 >>> These are not implementation problems, these are artifacts from the RPL= RFC design choices. >>>=20 >>>>>=20 >>>>>> If not, does your draft mention the propositions that have been made= to address the problems you point out in your draft ? >>>>>> I think it could be worth to leverage on these previous discussions. >>>>>=20 >>>>> I firmly disagree. The IETF and ROLL has published an RFC - that's wh= at this I-D discusses.=20 >>>>>=20 >>>>> Discussing what may have been proposed in other media would be entire= ly out of scope. >>>>=20 >>>> Again, this is not related to the RPL RFC but *your* implementation th= at received some guidance regarding its problems. >>>> The RPL RFC should not include tips for your implementation, but your = implementation and your draft should pay attention to the tips given to you= . >>>>=20 >>>=20 >>> This has nothing to do with "tips for [my] implementation whatsoever. S= ee examples I gave in reply to JP. >>>=20 >>>=20 >>>>>=20 >>>>>> Your draft is a list of Description and Observations. >>>>>> Maybe you could add a "Resolution Proposal" section for each problem= , gathering previous discussion and your own proposals ? >>>>>=20 >>>>> Nope. That's not the objective of this I-D. >>>>=20 >>>> That's too bad, this is what all readers of this draft are looking for= ! >>>=20 >>> It would be great to have that, so please write such a draft, addressin= g the issues that this I-D has presented. >>=20 >> Mukul seems to work on it. >> I guess a good mail browser could do a big part of the job. >>=20 >>>=20 >>> I am personally a great fan also of interoperability reports (something= which ROLL doesn't have either and which is not the point of this I-D eith= er) >>=20 >> Me too. >> The only "public" interop event I remember took place during IETF 77 in = March 2010. >> 5 differents companies were able to form a single DODAG using an early v= ersion of the RPL specification. >> Of course the intend of this event was not to do an exhaustive test of t= he RPL mechanisms but prove that the core design is correctly working. >> This is not surprising, given that some mechanisms used in RPL are used = in numerous commercial solution for a while. >> You should also have knowledge about the great effort of the Zigbee Alli= ance who is running interop events very regularly. >> RPL is the default routing protocol of the future Zigbee IP stack, and s= ome details have been given by robert craigie at the LWIG session of last I= ETF. >> Do you seriously think that these interop events occuring every 2 or 3 m= onths and involving most of the major companies in WSN would not have detec= t if something were wrong with the RPL design ? >=20 > I would still hope that RPL works for Zigbee since they list it in their = protocol stack, but their interop events do not help much here since they d= on't give any public feedback. Furthermore, the only details given at the L= WIG session were that Zigbee uses RPL in non-storing mode, and that some fe= atures had to be turned off (at least from what I can infer from the presen= tation and the minutes). As an implementer, I would need a little bit more = detail to know whether (and how) RPL would work for my application. And eve= n if I were to trust them blindly, what if I wanted to use RPL in non-stori= ng mode? I guess you wanted to say "storing mode" in your last sentence. Of course, they cannot disclose their results on the public place. If so, h= ow could they justify the fee to enter the alliance ... Same for their implementation parameters, Zigbee members are not working fo= r the public community ! I wanted to let people know about other RPL implementations efforts, to hel= p them to draw a global picture of how many people are using RPL. But as you said, it is hard to know when data are not public. >=20 >> If you think that you are not able to figure out yourself the problems y= ou see in RPL, go buy some commercial solutions ;-) >=20 > I might be relatively new here, but I wasn't aware the IETF relied on com= mercial solutions to fix its standard track protocols... Was just a humor tentative, and stating that RPL is already employed in com= mercial products and solutions. In general, commercial products are stable. C=E9dric. >=20 >=20 > Axel >=20 >=20 >>=20 >>=20 >>>=20 >>>> Without offense, saying "this is bad" without a better proposition see= ms like half-work !=20 >>>> And this is true for most of the discussion topics in life, far away f= rom RPL ! >>>=20 >>>>=20 >>>>> I would venture that if the WG is serious about applicability stateme= nts, then those applicability statements would be the place for discussion = of "how this issue, raised in this I-D, is addressed or moot for a given de= ployment". >>>>>=20 >>>>>> Identifying what is wrong in your implementation >>>>>=20 >>>>> Considering that these observations are not implementation-specific, = but are directly on the RPL RFC, I venture the observations that there's no= thing "wrong in my implementation" here. >>>>>=20 >>>>=20 >>>> As a general comment : RPL is a routing protocol targeted for a very w= ide application area.=20 >>>> Some may think this is good because it covers a lot of needs. >>>> Some may think it is bad because it is wide and not specific enough fo= r their application. >>>> Wathever your position, these two arguments are valid, this is all a m= atter of viewpoint and tradeoff. >>>=20 >>> I disagree here, Cedric, but this thread is not the place for that part= icular discussion. >>=20 >> I cannot see how you could not be inline with these statement, but anywa= y let's get back in the arena. >>=20 >>>> So, because RPL is wide enough for multiple application, you have to t= ake some time to tune it correctly, according to your application. >>>=20 >>> I disagree here, Cedric, but this thread is not the place for that part= icular discussion. This I-D does *not* discuss a specific application or de= ployment, but merely reflects on RPL, as published by the ROLL working grou= p. >>>=20 >>>> One simple choice that every RPL implementers will ave to answer is : = Use Storing or Non Storing Mode ? This is a fondamental design choice that = cannot be made outside a scenario consideration. >>>=20 >>> I agree here. >>>=20 >>> And, this I-D provides some observations - for example about storage re= quirements, and about requirements for all RPL routers in (for example, for= storing node) the case that the DODAG root can fail and floating DODAGs cr= eated. >>>=20 >>> This has nothing to do with a specific implementation, deployment, expe= riment, scenario or application, but is an artifact of a fundamental design= choice made in RPL. >>=20 >> This argument relies for more than a year on a research paper that is no= t inline with your statement, as discussed with the authors during IETF eve= nts. >> The memory available to store routes simply relates to the memory availa= ble in your mote, and this is directly given by the hardware you use. >> So the routing table size is more linked to the hardware than linked to = the RPL mechanisms. >> If you need more routing entries, buy a hardware with more memory, or op= timize the way you store routing entries. >> Is this problem really an "artifact of a fundamental choice made in RPL"= or a generic routing protocol problem ? >> I guess Mukul will give some thoughts on this point, as It has been alre= ady discussed. >>=20 >> C=E9dric. >>=20 >>>=20 >>>> Be sure that there is no magic RPL tuning that works for all, but mult= iple fine RPL tuning for multiple applications. >>>> I honestly cannot believe in generic results given the incredibly vari= ety of tuning that RPL can have. >>>=20 >>> This is, again, not a matter of "tuning of parameters" at all. That's n= ot what the I-D describes, or aims at describing. >>>=20 >>>> So my final position is that we disagree on the need of more details i= n your experiments. >>>=20 >>> I'm afraid that I disagree for this I-D. That's not the point of it, an= d I think that it is fairly clear in the I-D that it's not (as well as it i= s clear what the point is, and what the goals are for it) >>>=20 >>> I think that it would be interesting to have another I-D describe param= eter tunings etc for a given application. I would expect that to be part of= what the applicability statements were supposed to do. It's, however, stil= l not in this I-D that it should be done. >>>=20 >>> Thomas >>>=20 >>>> C=E9dric. >>>>=20 >>>>> Thomas >>>>>=20 >>>>>=20 >>>>>> is a good first step, but the hardest part is to propose some correc= tions. >>>>>> Best Regards, >>>>>>=20 >>>>>> C=E9dric Chauvenet. >>>>>>=20 >>>>>> Le 16 mai 2012 =E0 15:04, JP Vasseur a =E9crit : >>>>>>=20 >>>>>>> Dear Thomas, >>>>>>>=20 >>>>>>> On May 16, 2012, at 2:08 PM, Thomas Heide Clausen wrote: >>>>>>>=20 >>>>>>>> Dear JP and Michael, >>>>>>>>=20 >>>>>>>> Thank you for your mail. >>>>>>>>=20 >>>>>>>> On May 16, 2012, at 09:18 , JP Vasseur wrote: >>>>>>>>=20 >>>>>>>>> Dear Thomas, >>>>>>>>>=20 >>>>>>>>> On May 11, 2012, at 8:25 AM, Thomas Heide Clausen wrote: >>>>>>>>>=20 >>>>>>>>>> Dear JP, Michael, all >>>>>>>>>>=20 >>>>>>>>>> Upon JPs invitation, draft-clausen-lln-rpl-experiences was prese= nted and discussed at the Paris meeting. >>>>>>>>>>=20 >>>>>>>>>> The authors consider the document complete and "done", and are l= ooking to take it forward in the IETF=20 >>>>>>>>>> process for publication as "Informational RFC" in the very near = future.=20 >>>>>>>>>>=20 >>>>>>>>>> We would therefore like to ask the WG chairs, if the ROLL WG is = willing to accept and progress this=20 >>>>>>>>>> document towards publication? >>>>>>>>>=20 >>>>>>>>> Thanks for your suggestion. So far we haven't see a lot of discus= sion/interest from the WG but your request is >>>>>>>>> perfectly fair. >>>>>>>>=20 >>>>>>>> Thank you - I aim to be fair. >>>>>>>>=20 >>>>>>>>> So far there are no details on the scenarios and testing environm= ents that led to the issues that=20 >>>>>>>>> you reported, thus I would suggest you to first include them so t= hat people interested could be able to reproduce >>>>>>>>> it. Once the drat is updated, we'll be happy to pool the WG. >>>>>>>>>=20 >>>>>>>>> Does that make sense ? >>>>>>>>=20 >>>>>>>> Not really. Let me explain my disagreement. >>>>>>>>=20 >>>>>>>> We tried RPL (and, I note, several different independent implement= ations of RPL) in a number of different scenarios and deployments, and obse= rved the behaviors exhibited - noting that what we observed across the diff= erent implementations, scenarios and deployments was fairly universal. >>>>>>>>=20 >>>>>>>> We then went back to the specification, to understand these behavi= ors in detail, and understand their universality as independent from a spec= ific scenario or deployment or implementation - but rather, as artifacts of= the RPL protocol design. >>>>>>>>=20 >>>>>>>> We therefore believe that _any_ deployment, scenario or testing en= vironment of RPL needs to pay attention to the issues presented, and find a= way of addressing them. The way of addressing these issues in a given depl= oyment or scenario would be appropriate for an "applicability statement" fo= r that deployment or scenario. >>>>>>>=20 >>>>>>> JP> Thanks for the clarification; that being said, for the WG to ma= ke sure that nothing is "scenario" dependent and the outcome could indeed a= pply to all scenarios, >>>>>>> it might be worth being more explicit. For example, you pointed out= to the MTU issue, to which I mentioned that 15.4g would bring a solution, = so you may want to=20 >>>>>>> explain that you did not use 15.4g and there are a number of such e= xamples =85. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> (For example, a deployment using only L2s which provides guarantee= d bi-directional links for L3 would address this by in the applicability s= tatement stating "As all L2-links are guaranteed bi-directional, this addre= sses the issues raised in section 9 in draft-clausen-lln-rpl-experiences".) >>>>>>>>=20 >>>>>>>> Thus, we believe that it would actually be misleading (not to ment= ion, unnecessarily verbose) to put the "details on the scenarios and testin= g environments" into this I-D. >>>>>>>>=20 >>>>>>>> Doing so would mislead the reader to believe that the issues prese= nted only manifest themselves in those precise scenarios - which definitely= isn't the case. >>>>>>>=20 >>>>>>> JP> see the previous comment and tell us what you think; we could p= rovide other examples. >>>>>>>=20 >>>>>>> Note that we do not oppose to asking to the WG; we just request you= first to add additional information to proceed forward. >>>>>>>=20 >>>>>>> thanks. >>>>>>>=20 >>>>>>> JP and Michael. >>>>>>>=20 >>>>>>> JP. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> Best, >>>>>>>>=20 >>>>>>>> Thomas >>>>>>>>=20 >>>>>>>>> Thanks. >>>>>>>>>=20 >>>>>>>>> JP and Michael. >>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> Best, >>>>>>>>>>=20 >>>>>>>>>> Thomas, Ulrich, Yuichi, Jiazi and Axel >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> Roll mailing list >>>>>>> Roll@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 >=20 From cabo@tzi.org Wed May 16 17:31:36 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D6C511E8072 for ; Wed, 16 May 2012 17:31:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-zAxAlKGr6L for ; Wed, 16 May 2012 17:31:35 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DB6C021F85FB for ; Wed, 16 May 2012 17:31:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id q4H0VLRU005340; Thu, 17 May 2012 02:31:21 +0200 (CEST) Received: from [192.168.217.105] (p5B3E6AFE.dip.t-dialin.net [91.62.106.254]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id D36C620; Thu, 17 May 2012 02:31:20 +0200 (CEST) Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: Date: Thu, 17 May 2012 02:31:19 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <67FF4AF4-2C4A-4BE3-ADF1-7A05FAA76E60@tzi.org> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> To: Ulrich Herberg X-Mailer: Apple Mail (2.1278) Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 00:31:36 -0000 On May 16, 2012, at 19:09, Ulrich Herberg wrote: > Many of the observations in the draft are directly concluded from the = RPL RFC I'm a bit reluctant to pitch in here as I definitely don't want to take = sides in what appears to be an argument (the sides of which I'm just = starting to understand). For me, the draft reads less as a list of observations, but as a list of = hypotheses. An extremely useful list, as I think most people commenting in this = thread have agreed. Where these hypotheses are generated by drawing conclusions from the = specs, I think it is prudent to try to corroborate them based on actual = experience. Previously, people have concluded from the available = physics that airplanes cannot fly. Other people have proven them wrong. = I think there are a number of "heavier than air" arguments in the = document, and there may be Bernoullis in this WG shaking their heads. = We need the scientific dispute to nail down these hypotheses. Where these hypotheses are already corroborated by experiments, we need = to know enough about these so it doesn't appear to be a "I tried to = build an airplane and it didn't fly" argument. Some discussion of = minimum standards for documentation could be found, say, in = http://dx.doi.org/10.1145/1096166.1096174 -- I wouldn't want a WG = document that also qualifies as one of "the incredibles". The draft may lay the basis for/become an RFC 4815 style "here is some = more information that allows you to do it right" document. This may, in = part, be an applicability statement, or it may contain additional = specifications/constraints that are crucial to actually making things = work and may later become part of a revised spec. So what I'm saying here is that more work is needed on this document. = But I'm not saying the onus for this is *only* on its authors*): If it becomes a custom that members of the WG say "smart people know how = to make this work but we won't tell you how", this would demonstrate = that RPL is a "trapdoor" spec -- it is useful only to those readers who = already know how to interoperate, but it is not useful to create = interoperability. Of course, nobody is obliged to do the work to = provide this kind of information, and it's certainly not our job to = provide a basic engineering education. But if too much of the = information needed beyond that, is not becoming readily available, RPL = is not a viable IETF standards-track specification and MUST be = withdrawn. Gr=FC=DFe, Carsten *) (One of my pet peeves, after 30 years of standardization. Actually = the point that is drawing me into this discussion against my better = instinct.)=20 From gnawali@cs.uh.edu Wed May 16 19:11:36 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F358B11E80A0 for ; Wed, 16 May 2012 19:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.31 X-Spam-Level: X-Spam-Status: No, score=-6.31 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EQiKYy6jEWht for ; Wed, 16 May 2012 19:11:34 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id AF5C611E8073 for ; Wed, 16 May 2012 19:11:34 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id D001323CA89 for ; Wed, 16 May 2012 21:11:34 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pm48DIsEc6a3 for ; Wed, 16 May 2012 21:11:31 -0500 (CDT) Received: from it.cs.uh.edu (it.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 197A423CA86 for ; Wed, 16 May 2012 21:11:31 -0500 (CDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by it.cs.uh.edu (Postfix) with ESMTP id 787752A280C3 for ; Wed, 16 May 2012 21:43:20 -0500 (CDT) Received: by yenq13 with SMTP id q13so1600390yen.31 for ; Wed, 16 May 2012 19:11:30 -0700 (PDT) Received: by 10.236.79.195 with SMTP id i43mr5961285yhe.53.1337220690059; Wed, 16 May 2012 19:11:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.116.9 with HTTP; Wed, 16 May 2012 19:11:05 -0700 (PDT) In-Reply-To: <67FF4AF4-2C4A-4BE3-ADF1-7A05FAA76E60@tzi.org> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> <67FF4AF4-2C4A-4BE3-ADF1-7A05FAA76E60@tzi.org> From: Omprakash Gnawali Date: Wed, 16 May 2012 21:11:05 -0500 Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 02:11:36 -0000 Here is a link to a constructive document on related topics we started a while ago: Recommendations for Efficient Implementation of RPL http://tools.ietf.org/html/draft-gnawali-roll-rpl-recommendations-03 (just wanted to refresh WG's memory) As always, happy to edit the document with experiences from the trenches. - om_p On Wed, May 16, 2012 at 7:31 PM, Carsten Bormann wrote: > On May 16, 2012, at 19:09, Ulrich Herberg wrote: > >> Many of the observations in the draft are directly concluded from the RP= L RFC > > I'm a bit reluctant to pitch in here as I definitely don't want to take s= ides in what appears to be an argument (the sides of which I'm just startin= g to understand). > > For me, the draft reads less as a list of observations, but as a list of = hypotheses. > An extremely useful list, as I think most people commenting in this threa= d have agreed. > > Where these hypotheses are generated by drawing conclusions from the spec= s, I think it is prudent to try to corroborate them based on actual experie= nce. =A0Previously, people have concluded from the available physics that a= irplanes cannot fly. =A0Other people have proven them wrong. =A0I think the= re are a number of "heavier than air" arguments in the document, and there = may be Bernoullis in this WG shaking their heads. =A0We need the scientific= dispute to nail down these hypotheses. > > Where these hypotheses are already corroborated by experiments, we need t= o know enough about these so it doesn't appear to be a "I tried to build an= =A0airplane and it didn't fly" argument. =A0Some discussion of minimum sta= ndards for documentation could be found, say, in http://dx.doi.org/10.1145/= 1096166.1096174 -- I wouldn't want a WG document that also qualifies as one= of "the incredibles". > > The draft may lay the basis for/become an RFC 4815 style "here is some mo= re information that allows you to do it right" document. =A0This may, in pa= rt, be an applicability statement, or it may contain additional specificati= ons/constraints that are crucial to actually making things work and may lat= er become part of a revised spec. > > So what I'm saying here is that more work is needed on this document. =A0= But I'm not saying the onus for this is *only* on its authors*): > > If it becomes a custom that members of the WG say "smart people know how = to make this work but we won't tell you how", this would demonstrate that R= PL is a "trapdoor" spec -- it is useful only to those readers who already k= now how to interoperate, but it is not useful to create interoperability. = =A0Of course, nobody is obliged to do the work to provide this kind of info= rmation, and it's certainly not our job to provide a basic engineering educ= ation. =A0But if too much of the information needed beyond that, is not bec= oming readily available, RPL is not a viable IETF standards-track specifica= tion and MUST be withdrawn. > > Gr=FC=DFe, Carsten > > *) (One of my pet peeves, after 30 years of standardization. Actually the= point that is drawing me into this discussion against my better instinct.) > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Anders_Brandt@sigmadesigns.com Wed May 16 01:41:20 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B3E521F870F for ; Wed, 16 May 2012 01:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOvRPvKpwXjs for ; Wed, 16 May 2012 01:41:16 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 98B7721F8711 for ; Wed, 16 May 2012 01:41:15 -0700 (PDT) From: Anders Brandt To: Michael Richardson , "roll@ietf.org" Thread-Topic: [Roll] proposal for common table of contents for applicability statements Thread-Index: AQHNMsJyaj9Nyv35dEeh8V08XPl0uJbMGDVA Date: Wed, 16 May 2012 08:41:13 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0ABE8F25@cph-ex1> References: <20120430114209.21250.82110.idtracker@ietfa.amsl.com> <18151.1335822136@marajade.sandelman.ca> <10134.1337103877@marajade.sandelman.ca> In-Reply-To: <10134.1337103877@marajade.sandelman.ca> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.79] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com X-Mailman-Approved-At: Wed, 16 May 2012 19:37:12 -0700 Subject: Re: [Roll] proposal for common table of contents for applicability statements X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 May 2012 08:41:20 -0000 Hi Michael > I thought we had a third applicability statement as an independant draft, > but I couldn't find one. We should have a building/home applicability > statement. It is here http://tools.ietf.org/html/draft-brandt-roll-rpl-applicability-home-buildin= g-01 In its current state it is more like a problem statement... RPL P2P is in its final stages and solves most of the issues that were addressed in this draft. Thus, it is about time to get it revived. I will try to get this done before the cutoff date but cannot promise. Thanks, Anders > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Michael Richardson > Sent: Tuesday, May 15, 2012 19:45 > To: roll@ietf.org > Subject: [Roll] proposal for common table of contents for applicability > statements >=20 > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 > Here is the table of contents from each of the applicability statements. > I thought we had a third applicability statement as an independant draft, > but I couldn't find one. We should have a building/home applicability > statement. >=20 > I feel that these two applicability statements are over broad, and that > each should be split into two or three statements. In particular, I > think that Energy-Constrained and Energy-Rich networks should be split in= to > different documents as they have vastly different requirements. > It may be that there is a further split for networks that are dense > (urban) vs those that are less dense (suburban or rural). >=20 > A major purpose of these documents is to permit a utility (etc.) to be ab= le to > write an RFP to procure equipment from multiple vendors that can > interoperate. (there are NAFTA, GATT, etc. that governments needs to > comply to, which an RFC easily satisfies) >=20 >=20 > As such, there needs to be enough information as to the profile of RPL to= be > deployed (to each area), such that a vendor can actually implement > something definite. >=20 > I also feel that these document spend too much time on explaining what > RPL is (and frankly they they do a really good, succint job at it, so I h= ate to > lose that text, but I don't think it needs to be repeated) >=20 > What I'd like to do (and I invite you to reply inline, keeping just this = text, > and +1 each part seperately) >=20 > 1) is to synchronize these two documents' table of contents. >=20 > 2) discuss adopting draft-phinney as a WG document! >=20 > 3) make sure that we are also detailing security and routing issues > properly, and yes, we need to have statments like: > "Metering networks using ZigBee FOOBAR MUST in layer-2 have > security BAZ enabled in order that RPL messages will be secured." > or: > "This statement applies to using RPL as the MESH over network on > 802.15.4 technology with the 6LowPAN defined nd-18 including RFC6282 > HC" >=20 > The applicability statement is not the place to be general. > Let's be specific, and in doing so, let's be succinct. >=20 >=20 > draft-ietf-roll-applicability-ami-05.txt: > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 1.1. Electric Metering . . . . . . . . . . . . . . . . . . . . 3 > 1.2. Gas and Water Metering . . . . . . . . . . . . . . . . . . 3 > 1.3. Routing Protocol for LLNs (RPL) . . . . . . . . . . . . . 4 > 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5 > 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5 > 2.1. Network Topology . . . . . . . . . . . . . . . . . . . . . 5 > 2.1.1. Electric Meter Network . . . . . . . . . . . . . . . . 5 > 2.1.2. Energy-Constrained Network Infrastructure . . . . . . 6 > 2.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 6 > 2.2.1. Smart Metering Data . . . . . . . . . . . . . . . . . 7 > 2.2.2. Distribution Automation Communication . . . . . . . . 8 > 2.2.3. Emerging Applications . . . . . . . . . . . . . . . . 8 > 3. Using RPL to Meet Functional Requirements . . . . . . . . . . 8 > 4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 9 > 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 9 > 4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 9 > 4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 9 > 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 10 > 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 10 > 4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 10 > 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 11 > 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 11 > 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 12 > 4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 12 > 4.2. Recommended Configuration Defaults and Ranges . . . . . . 12 > 4.2.1. Trickle Parameters . . . . . . . . . . . . . . . . . . 12 > 4.2.2. Other Parameters . . . . . . . . . . . . . . . . . . . 13 > 5. Manageability Considerations . . . . . . . . . . . . . . . . . 14 > 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 > 7. Other Related Protocols . . . . . . . . . . . . . . . . . . . 15 > 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 > 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 > 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 > 10.1. Informative References . . . . . . . . . . . . . . . . . . 15 > 10.2. Normative References . . . . . . . . . . . . . . . . . . . 16 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 >=20 >=20 > draft-phinney-rpl-industrial-applicability-00: > 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 > 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 > 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 > 3.1. Deployment scenarii . . . . . . . . . . . . . . . . . . . 7 > 3.2. Applications and Traffic classes . . . . . . . . . . . . . 9 > 3.3. RPL applicability matrix . . . . . . . . . . . . . . . . . 10 > 4. Characterization of communication flows in IACS wireless > networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 > 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 > 4.2. Source-sink (SS) communication paradigm . . . . . . . . . 13 > 4.3. Publish-subscribe (PS, or pub/sub) communication > paradigm . . . . . . . . . . . . . . . . . . . . . . . . . 13 > 4.4. Peer-to-peer (P2P) communication paradigm . . . . . . . . 15 > 4.5. Peer-to-multipeer (P2MP) communication paradigm . . . . . 16 > 4.6. Additional considerations: Duocast and N-cast . . . . . . 17 > 4.7. RPL applicability per communication paradigm . . . . . . . 18 > 5. RPL profile . . . . . . . . . . . . . . . . . . . . . . . . . 21 > 5.1. Use for process control . . . . . . . . . . . . . . . . . 21 > 5.2. RPL features . . . . . . . . . . . . . . . . . . . . . . . 21 > 5.2.1. Storing vs. non-storing mode . . . . . . . . . . . . . 21 > 5.2.2. DAO policy . . . . . . . . . . . . . . . . . . . . . . 21 > 5.2.3. Path metrics . . . . . . . . . . . . . . . . . . . . . 22 > 5.2.4. Objective functions . . . . . . . . . . . . . . . . . 22 > 5.2.5. DODAG repair . . . . . . . . . . . . . . . . . . . . . 22 > 5.2.6. Security . . . . . . . . . . . . . . . . . . . . . . . 22 > 5.3. RPL options . . . . . . . . . . . . . . . . . . . . . . . 22 > 5.4. Recommended configuration defaults and ranges . . . . . . 22 > 5.4.1. Trickle parameters . . . . . . . . . . . . . . . . . . 22 > 5.4.2. Other parameters . . . . . . . . . . . . . . . . . . . 23 > 5.4.3. Additional configuration recommendations . . . . . . . 23 > 6. Other related protocols . . . . . . . . . . . . . . . . . . . 24 > 7. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 25 > 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26 > 9. Security considerations . . . . . . . . . . . . . . . . . . . 27 > 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 > 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 > 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29 > 11.2. Informative References . . . . . . . . . . . . . . . . . . 29 > 11.3. External Informative References . . . . . . . . . . . . . 30 > Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 >=20 > - -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >=20 > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.10 (GNU/Linux) >=20 > iQCVAwUBT7KWBIqHRg3pndX9AQKEDgP/ddKMasN7jRNVl6ZGAtCchSYeV/0o > USQ0 > Gn8FSRCbacZosnchjVDuDz5MMV4MToC8BPgBh2n0qW4jTpYK8KTPiwhGcJUg > kwtv > n1xmEJj6d9kftudUCFfmh2WlrXaPWlYdndM/avulkGK8mOVYphHYrtxf4nbyj1 > HV > Y3ChARZ5nUM=3D > =3D8qRA > -----END PGP SIGNATURE----- > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Wed May 16 22:02:31 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBDE121F85A5 for ; Wed, 16 May 2012 22:02:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.582 X-Spam-Level: X-Spam-Status: No, score=-6.582 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89QMpIhHNGC3 for ; Wed, 16 May 2012 22:02:30 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by ietfa.amsl.com (Postfix) with ESMTP id AC7B521F85A4 for ; Wed, 16 May 2012 22:02:29 -0700 (PDT) Received: from [76.14.66.110] (helo=[192.168.0.103]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1SUsr5-0008AH-LD; Wed, 16 May 2012 22:02:27 -0700 Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: Date: Wed, 16 May 2012 22:02:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> To: Thomas Heide Clausen X-Mailer: Apple Mail (2.1257) X-Scan-Signature: 0858a923cc4ba3562bb802375c61c59b Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 May 2012 05:02:31 -0000 On May 16, 2012, at 10:11 AM, Thomas Heide Clausen wrote: >=20 >=20 > For example:=20 >=20 > o the state required for storing/non-storing mode does = *not* depend on a=20 > specific implementation and deployment, but is an = artifact from the RPL design. >=20 > o the message-size of RPL is not dependent on a specific = implementation and deployment, > but is an artifact from the RPL design. >=20 > o the use of links "upwards" based on receipt of traffic = "downwards" (i.e. the unidirectional > link issue) is not dependent on a specific = implementation and deployment, > but is an artifact from the RPL design. >=20 > o the unknown-by-source MTU issues for data-traffic when = using non-storing mode=20 > is not dependent on a specific implementation and = deployment, > but is an artifact from the RPL design. >=20 > I could go on, but then it'd be easier to just paste the whole I-D = into this email. Thomas, I agree that some points in the ID are valid statements about the = protocol itself, such as message sizes and the issues caused by floating = DODAGs. Those, to me, seem like reasonable points to make. However, some of the points are hypotheses about performance (14), a bit = naive about how wireless networks behave (13) or somewhat snippy gripes = (11, 12). In my opinion, a document which focused on factual statements = of the protocol design not really open to interpretation and cut = hypothetical or subjective statements might be ready for the working = group to consider. As just a start, I object to 10, 11, 12, 13, and 14 being considered = inherent to the protocol. 10 assumes that a node only uses DIO reception to allow a parent; the = specification is pretty clear that you should check the parent is usable = (section 1.1). You're taking a bad implementation decision and assuming = there isn't another way to do things.=20 For 11, there are implementations of RPL smaller than 50kB; they do not = implement every feature, but that was kind of the point of the protocol, = that it could be implemented on a sliding scale of implementation = complexity. The TinyOS implementation, for example, is, I believe, = ~20kB, less than half the size. You don't report what architecture the = 50kB is for, clearly it would be more for a 32-bit than a 16-bit = architecture.=20 For 12, "implementations may exhibit a bad performance if not carefully = implemented." I think it is safe to say this is true for almost ANY = protocol. A specification is not intended to be a complete statement of = efficient implementation, otherwise you give little latitude to future = improvements and good engineering. For 13, this assumes that a wireless network has a stable topology which = the protocol can converge to. Wireless networks are often NOT stable: = one cannot expect a protocol to converge on a dynamic graph. 14 is similarly confused about what a wireless network looks like. How = can the state of a distributed system based on a dynamic topology be = "consistent?" I think this is a fundamental misunderstanding of how the = network works. That being said, I think point 6 is well taken and should be considered, = maybe others. Maybe the constructive way to take this document, if you = don't want to take the step of specifying solutions, is at least casting = it as a roadmap for ways in which you think the WG should improve RPL? Phil From Martin.Heusse@imag.fr Fri May 18 13:45:21 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B577121F85F4 for ; Fri, 18 May 2012 13:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.505 X-Spam-Level: ** X-Spam-Status: No, score=2.505 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FRT_BELOW2=2.154, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gbdBbpliUmBS for ; Fri, 18 May 2012 13:45:21 -0700 (PDT) Received: from rominette.imag.fr (mx2.imag.fr [IPv6:2001:660:5301:59::17]) by ietfa.amsl.com (Postfix) with ESMTP id E3A6121F85EE for ; Fri, 18 May 2012 13:45:20 -0700 (PDT) Received: from globule.imag.fr (globule.imag.fr [129.88.34.238]) by rominette.imag.fr (8.13.8/8.13.8) with ESMTP id q4IKbVnB013718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 May 2012 22:37:31 +0200 Received: from [192.168.1.1] (lns-bzn-51f-81-56-135-57.adsl.proxad.net [81.56.135.57]) (authenticated bits=0) by globule.imag.fr (8.13.8/8.13.8) with ESMTP id q4IKodHr025504 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 18 May 2012 22:50:40 +0200 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: Martin Heusse In-Reply-To: <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu> Date: Fri, 18 May 2012 22:46:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2AF45E51-6C3B-48D9-908F-117ECF0CABAA@imag.fr> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu> To: roll WG X-Mailer: Apple Mail (2.1278) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (rominette.imag.fr [129.88.30.17]); Fri, 18 May 2012 22:37:32 +0200 (CEST) X-IMAG-MailScanner-Information: Please contact MI2S MIM for more information X-MailScanner-ID: q4IKbVnB013718 X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-SpamCheck: X-IMAG-MailScanner-From: martin.heusse@imag.fr MailScanner-NULL-Check: 1337978255.17568@u6Mi47PKqDoJG4mFjBG89Q Cc: Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 20:45:21 -0000 Phil,=20 what you are writing bellow may be true (although...) but it does not = address comment 12, that we have no idea when DAOs should be sent and = how DAOs should be handled (how long should the route be kept?).=20 Along those lines, 2 comments: 1) I notice that draft-ietf-roll-applicability-ami, for instance, = ignores DAOs except for specifying that DAOs SHOULD be sent -- so they = might not be sent--, even though "Two-way communication is a = requirement"(?). At the same time, this draft goes as far as suggesting = what parameters to use for trickle (big deal) or for MaxRankIncrease = (big deal: will things break if someone uses 512 instead of 1024?).=20 (same comment applies to draft-gnawali-roll-rpl-recommendations-03.) 2) What is the point of making DAOs compact in storing mode = (learning the route recursively) while the packets that actually contain = data have to carry the whole path anyway? =20 Best regards, Martin Philip Levis wrote: > For 12, "implementations may exhibit a bad performance if not = carefully implemented." I think it is safe to say this is true for = almost ANY protocol. A specification is not intended to be a complete = statement of efficient implementation, otherwise you give little = latitude to future improvements and good engineering. From gnawali@cs.uh.edu Fri May 18 16:38:00 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8067B21F85DF for ; Fri, 18 May 2012 16:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.155 X-Spam-Level: X-Spam-Status: No, score=-4.155 tagged_above=-999 required=5 tests=[AWL=-0.332, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_BELOW2=2.154, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzOLDSuWofgb for ; Fri, 18 May 2012 16:38:00 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id AAD2521F85D6 for ; Fri, 18 May 2012 16:37:59 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id AE74F23CA8E for ; Fri, 18 May 2012 18:37:59 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-gsgh2UZiQ2 for ; Fri, 18 May 2012 18:37:56 -0500 (CDT) Received: from it.cs.uh.edu (it.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id ABD3823CA84 for ; Fri, 18 May 2012 18:37:56 -0500 (CDT) Received: from mail-gg0-f172.google.com (mail-gg0-f172.google.com [209.85.161.172]) by it.cs.uh.edu (Postfix) with ESMTP id B34FA2A280C3 for ; Fri, 18 May 2012 19:09:54 -0500 (CDT) Received: by ggnc4 with SMTP id c4so3970614ggn.31 for ; Fri, 18 May 2012 16:37:55 -0700 (PDT) Received: by 10.236.114.197 with SMTP id c45mr5469063yhh.114.1337384275771; Fri, 18 May 2012 16:37:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.147.116.9 with HTTP; Fri, 18 May 2012 16:37:35 -0700 (PDT) In-Reply-To: <2AF45E51-6C3B-48D9-908F-117ECF0CABAA@imag.fr> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu> <2AF45E51-6C3B-48D9-908F-117ECF0CABAA@imag.fr> From: Omprakash Gnawali Date: Fri, 18 May 2012 18:37:35 -0500 Message-ID: To: Martin Heusse Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 May 2012 23:38:00 -0000 Martin, Is your concern that 6550 and draft-gnawali-roll-rpl-recommendations-03 do not say the Trickle interval should be a-b ms and hence it is easy to use a bad value and bring the whole network down or make it run inefficiently? - om_p On Fri, May 18, 2012 at 3:46 PM, Martin Heusse wrot= e: > Phil, > what you are writing bellow may be true (although...) but it does not add= ress comment 12, that we have no idea when DAOs should be sent and how DAOs= should be handled (how long should the route be kept?). > > Along those lines, 2 comments: > 1) I notice that draft-ietf-roll-applicability-ami, for instance, ignores= DAOs except for specifying that DAOs SHOULD be sent -- so they might not b= e sent--, even though "Two-way communication is a requirement"(?). At the s= ame time, this draft goes as far as suggesting what parameters to use for t= rickle (big deal) or for MaxRankIncrease (big deal: will things break if so= meone uses 512 instead of 1024?). > (same comment applies to draft-gnawali-roll-rpl-recommendations-03.) > 2) What is the point of making DAOs compact in storing mode (le= arning the route recursively) while the packets that actually contain data = have to carry the whole path anyway? > > Best regards, > Martin > > > Philip Levis wrote: > >> For 12, "implementations may exhibit a bad performance if not carefully = implemented." =A0I think it is safe to say this is true for almost ANY prot= ocol. A specification is not intended to be a complete statement of efficie= nt implementation, otherwise you give little latitude to future improvement= s and good engineering. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Sat May 19 12:40:00 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9065E21F855A for ; Sat, 19 May 2012 12:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.445 X-Spam-Level: X-Spam-Status: No, score=-108.445 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_BELOW2=2.154, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vWudhmn7K32P for ; Sat, 19 May 2012 12:40:00 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9549D21F853F for ; Sat, 19 May 2012 12:39:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=2057; q=dns/txt; s=iport; t=1337456399; x=1338665999; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=LepSpv5yvoObnGGJByIi8bhjaFgCXweJ6bAvZYGymXw=; b=WneHKtIcQoGtbsYvCIY6CSN0I1A9atjkBx1oht2PDrszbqdm0cr2hMIj nbplYQXg6I8KEz13OMg5JipmhyfdyUStL7dHbYQ1BulxZHWfV//s9pHHi WXOkZTyUo/D1cDdyfv/z6fyvkbQNpqSF6aQW+sf5+ABgsnD1GTCLgZfX+ 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8EAHv2t09Io8UY/2dsb2JhbABFgx2IEqljghUBAQEDAQEBAQ8BWgELBQsLGC4nMAYTIodnBQucSJ8YBIsFhGtiA5UbhU+IPYFkgms X-IronPort-AV: E=Sophos;i="4.75,621,1330905600"; d="scan'208";a="12501144" Received: from vla196-nat.cisco.com (HELO bgl-core-3.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 19 May 2012 19:39:57 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q4JJdvD5018084; Sat, 19 May 2012 19:39:57 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); Sun, 20 May 2012 03:39:56 +0800 Received: from [10.60.114.227] ([10.60.114.227]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 May 2012 03:39:54 +0800 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=windows-1252 From: JP Vasseur In-Reply-To: <2AF45E51-6C3B-48D9-908F-117ECF0CABAA@imag.fr> Date: Sat, 19 May 2012 21:39:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu> <2AF45E51-6C3B-48D9-908F-117ECF0CABAA@imag.fr> To: Martin Heusse X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 19 May 2012 19:39:55.0021 (UTC) FILETIME=[2A85ABD0:01CD35F7] Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 May 2012 19:40:00 -0000 Hi Martin, co-chair hat off =85 How often do you think that ISIS LSA should be refreshed ? Or OSPF opaque LSA for TE extensions be flooded ? Or BFD packets ?=20 Or PCEP Keepalive when turned on ? Very seriously =85 these questions apply to all protocols =85 and you = cannot expect the specifications to give you hard coded values (but default whenever possible); these are topology = and application specific, don't you think ? Thanks. Cheers. JP. On May 18, 2012, at 10:46 PM, Martin Heusse wrote: > Phil,=20 > what you are writing bellow may be true (although...) but it does not = address comment 12, that we have no idea when DAOs should be sent and = how DAOs should be handled (how long should the route be kept?).=20 >=20 > Along those lines, 2 comments: > 1) I notice that draft-ietf-roll-applicability-ami, for instance, = ignores DAOs except for specifying that DAOs SHOULD be sent -- so they = might not be sent--, even though "Two-way communication is a = requirement"(?). At the same time, this draft goes as far as suggesting = what parameters to use for trickle (big deal) or for MaxRankIncrease = (big deal: will things break if someone uses 512 instead of 1024?).=20 > (same comment applies to draft-gnawali-roll-rpl-recommendations-03.) > 2) What is the point of making DAOs compact in storing mode = (learning the route recursively) while the packets that actually contain = data have to carry the whole path anyway? =20 >=20 > Best regards, > Martin >=20 >=20 > Philip Levis wrote: >=20 >> For 12, "implementations may exhibit a bad performance if not = carefully implemented." I think it is safe to say this is true for = almost ANY protocol. A specification is not intended to be a complete = statement of efficient implementation, otherwise you give little = latitude to future improvements and good engineering. >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From Martin.Heusse@imag.fr Mon May 21 03:16:52 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B7421F85F0 for ; Mon, 21 May 2012 03:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aAgC3yiHQdYm for ; Mon, 21 May 2012 03:16:52 -0700 (PDT) Received: from shiva.imag.fr (mx1.imag.fr [IPv6:2001:660:5301:6::5]) by ietfa.amsl.com (Postfix) with ESMTP id 04E0121F85C3 for ; Mon, 21 May 2012 03:16:51 -0700 (PDT) Received: from globule.imag.fr (globule.imag.fr [129.88.34.238]) by shiva.imag.fr (8.13.8/8.13.8) with ESMTP id q4LA8vlL026299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 May 2012 12:08:57 +0200 Received: from scilly.imag.fr (scilly.imag.fr [129.88.48.164]) (authenticated bits=0) by globule.imag.fr (8.13.8/8.13.8) with ESMTP id q4LAMKBq007053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 21 May 2012 12:22:20 +0200 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=iso-8859-1 From: Martin Heusse In-Reply-To: Date: Mon, 21 May 2012 12:18:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <68731800-504B-4A57-8A58-053B4C7A7861@imag.fr> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu> <2AF45E51-6C3B-48D9-908F-117ECF0CABAA@imag.fr> To: Omprakash Gnawali X-Mailer: Apple Mail (2.1278) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (shiva.imag.fr [129.88.30.5]); Mon, 21 May 2012 12:08:57 +0200 (CEST) X-IMAG-MailScanner-Information: Please contact MI2S MIM for more information X-MailScanner-ID: q4LA8vlL026299 X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-SpamCheck: X-IMAG-MailScanner-From: martin.heusse@imag.fr MailScanner-NULL-Check: 1338199738.1931@zj5cuAVxjQIgOBmtRPhDhQ Cc: roll WG Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 10:16:53 -0000 Not at all. I wrote that email firstly to react on Phil Levis' partial reaction. The = subject was when to send and how to handle DAOs (comment 12 of = draft-clausen). As far as I know, this is orthogonal to the trickle = algorithm, isn't it?=20 But then I wondered if maybe an applicability / recommendation draft = would give more precise information on this topic (which could make = sense, considering the fact that downward traffic is viewed as a = requirement in the context of the applicability draft). It seems to me = this is not the case, although I may have missed something.=20 Best regards, Martin Le 19 mai 2012 =E0 01:37, Omprakash Gnawali a =E9crit : > Martin, >=20 > Is your concern that 6550 and > draft-gnawali-roll-rpl-recommendations-03 do not say the Trickle > interval should be a-b ms and hence it is easy to use a bad value and > bring the whole network down or make it run inefficiently? From prvs=481667b10=mukul@uwm.edu Mon May 21 08:45:54 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1270621F8593 for ; Mon, 21 May 2012 08:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.185 X-Spam-Level: X-Spam-Status: No, score=-4.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1LGeLhUmLona for ; Mon, 21 May 2012 08:45:52 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 386ED21F855D for ; Mon, 21 May 2012 08:45:52 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EAPlhuk9/AAAB/2dsb2JhbABEDoUfsXgBAQEDAQEBAQsVQgIFAgIJDA8OAwEDAQEDAg0ZAikiBggGExuHbgULrDiJSokEBIEmiV8ahB+BFAOIQoxZj3CCMFeBOAkR Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id C72E8E6A72; Mon, 21 May 2012 10:45:50 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lsTLzeQ+iu2r; Mon, 21 May 2012 10:45:49 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id C7629E6A8D; Mon, 21 May 2012 10:45:49 -0500 (CDT) Date: Mon, 21 May 2012 10:45:49 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <2071633195.463484.1337615149395.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll WG , Michael Richardson Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 May 2012 15:45:54 -0000 Here is my review for first 9 sections of draft-clausen-lln-rpl-experiences= -03. For later sections, I have nothing substaintial to add to what Philip = has already said in the message below.=20 One answer to many questions raised in draft-clausen is: use P2P-RPL. It is= not the case that P2P-RPL must always be used simply because the problems = it solves are not significant in all scenarios or application domains. But,= where it makes sense, P2P-RPL can certainly be used. P2P-RPL is currently = aiming for Experimental status. As more experience is gained with its opera= tion, it will go for Standards Track status. Thanks Mukul Section 4: Requirement Of DODAG Root -------------------------------------- "RPL Routers provisioned with resources to act as DODAG Roots, and administratively configured to act as such, represent a single point of failure in the network. As the memory requirements for the DODAG Root and for other RPL Routers are substantially different, unless all RPL Routers are provisioned with resources (memory, energy, ...) to act as DODAG Roots, effectively if the designated DODAG Root fails, the network fails and RPL is unable to operate. Even if electing another RPL Router as temporary DODAG root (e.g., for forming a "Floating" DODAG) for providing internal connectivity between RPL Routers, this router may not have the necessary resources to satisfy this role as (temporary) DODAG Root. " If a deployment uses "RPL + P2P-RPL", the criticism listed above is not val= id. There is no single point of failure. If the global DAG(s) cannot work b= ecause of the root's failure, the nodes can still discover routes to each o= ther using P2P-RPL. Nodes do not need extra memory/CPU to run P2P-RPL. "Another possible LLN scenario is that only internal point-to-point connectivity is sought, and no RPL Router has a more "central" role than any other - a self-organizing LLN. Requiring special provisioning of a specific "super-node" as DODAG Root is both unnecessary and undesirable." Such an LLN can just use P2P-RPL. No need for special provisioning for any = node. =20 Section 5: RPL Data Traffic Flows -------------------------------------- " RPL makes a-priori assumptions of data traffic types, and explicitly defines three such [I-D.ietf-roll-terminology] traffic types: sensor- to-root data traffic (multipoint-to-point) is predominant, root-to- sensor data traffic (point-to-multipoint) is rare and sensor-to- sensor (point-to-point) data traffic is extremely rare. While not specifically called out thus in [RFC6550], the resulting protocol design, however, reflects these assumptions in that the mechanism constructing multipoint-to-point routes is efficient in terms of control traffic generated and state required, point-to-multipoint route construction much less so - and point-to-point routes subject to potentially significant route stretch (routes going through the DODAG Root in non-storing mode) and over-the-wire overhead from using source routing (from the DODAG Root to the destination) (see Section 7) - or, in case of storing mode, considerable memory requirements in all LLN routers inside the network (see Section 7). " P2P-RPL resolves any route stretch issues. Note that if the source and dest= ination are far apart, the route stretch with core RPL is not much (i.e. th= e along-DAG routes wont be much worse than direct routes) although the cons= traint to traverse through the root may still cause congestion near the roo= t. If source and destination are nearby, the route stretch with "along glob= al DAG" route could be significant and that is where using P2P-RPL makes mo= st sense. Also, P2P-RPL supports discovery of both hop-by-hop routes and source route= s. A source could choose which one to use for a particular destination.=20 "The data traffic characteristics, assumed by RPL, do not represent a universal distribution of traffic types in LLNs: o There are scenarios where sensor-to-sensor traffic is a more common occurrence, documented, e.g., in [RFC5867] ("Building Automation Routing Requirements in Low Power and Lossy Networks"). " And in such cases, it makes sense to use P2P-RPL with or without core RPL. "For the former, all sensor-to-sensor routes include the DODAG Root, possibly causing congestions on the communication medium near the DODAG Root, and draining energy from the intermediate RPL Routers on an unnecessarily long route. If sensor-to-sensor traffic is common, RPL Routers near the DODAG Root will be particularly solicited as relays, especially in non-storing mode. " Use P2P-RPL. Section 6: Fragmentation Of RPL Control Messages And Data Packet ---------------------------------------------------------------- " While 79 octets may seem to be sufficient to carry RPL control messages, consider the following: RPL control messages are carried in ICMPv6, and the mandatory ICMPv6 header consumes 4 octets. The DIO base another 24 octets. If link metrics are used, that consumes at least another 8 octets - and this is using a hop count metric; other metrics may require more. The DODAG Configuration Object consumes up to a further 16 octets, for a total of 52 octets. Adding a Prefix Information Object for address configuration consumes another 32 octets, for a total of 84 octets - thus exceeding the 79 octets available for L3 data payload and causing link-layer fragmentation of such a DIO. " It is certainly possible for a DIO to exceed 79 bytes. But, it is not the c= ase that a DIO would always fragment. DODAG Configuration Option is an "opt= ion" and so is the Prefix Information Option. Every DIO need not carry thes= e options (or others defined in Section 6.7 of RPL RFC). That being said, possible fragmentation of DIOs is a real issue. When desig= ning a packet format, one always has to struggle to achieve a balance betwe= en the need to save space and the need to be modular - two conflicting goal= s. Pascal called the P2P Route Discovery Option (P2P-RDO, defined in P2P-RP= L) a "garbage can option" because it includes all the information P2P-RPL r= oute discovery needs (besides what is carried in the configuration option, = the metric containers and the DIO base object). We designed P2P-RDO thinkin= g that the need to save space is more critical. Various options defined in = RPL RFC were designed giving more importance to the need for modularity. I = dont think this is necessarily a bad thing as draft-clausen alleges. While = many RPL deployments will use IEEE 802.15.4 as the link layer in near futur= e, this may not always be the case. The correct solution to the problem of = fragmentation in 802.15.4 LLNs is to devise a compression mechanism at 6low= pan level. Some thing similar to draft-bormann-6lowpan-ghc-04 or the RPL-sp= ecific compression scheme we proposed (draft-goyal-roll-rpl-compression but= now working at 6lowpan layer). "As a point of reference, the ContikiRPL [rpl-contiki] implementation includes both the DODAG Configuration option and the Prefix Information option in all DIO messages. Any other options, e.g., Route Information options indicating prefixes reachable through the DODAG Root, increase the overhead and thus the probability of fragmentation. " OK, so a particular implementation always includes config and PI options in= all DIOs. That sounds like a problem this particular implementation has cr= eated for itself. "Given the minimal packet size of LLNs, the routing protocol must impose low (or no) overhead on data packets, hopefully independently of the number of hops [RFC4919]. However, source-routing not only causes increased overhead in the IP header, but also leads to a variable available payload for data (depending on how long the source route is)." Again, this is not a simple one-sided issue. Yes, source routes eat preciou= s bytes in the data packets. But, in many constrained environments (e.g. in= some home automation deployments), only source routing is possible because= devices are hard pressed for memory and cannot maintain any routing state. "In point-to-point communication and when non-storing mode is used for downward traffic, the source of a data packet will be unaware of how many octets will be available for payload (without incurring L2.5 fragmentation) when the DODAG Root relays the data packet and add the source routing header. Thus, the source may choose an inefficient size for the data payload: if the data payload is large, it may exceed the link-layer MTU at the DODAG Root after adding the source-routing header; on the other hand, if the data payload is low, the network resources are not used efficiently, which introduces more overhead and more frame transmissions. " This is a good point to make. Note that this problem is not present when th= e source (rather than the DAG root) itself includes the source route in the= packet. So, this problem goes away when using P2P-RPL.=20 Section 7: The DAO Mechanism: Downward and Point-to-Point Routes --------------------------------------------------------------- "RPL specifies two distinct and incompatible "modes of operation" for downward traffic: storing mode, where each RPL Router is assumed to maintain routes to all destinations in its sub-DODAG, i.e., RPL Routers that are "deeper down" in the DODAG, and non-storing mode, where only the DODAG Root stores routes to destinations inside the LLN, and where the DODAG Root employs strict source routing in order to route data traffic to the destination RPL Router. " The above description of storing mode is incorrect. It is not the case that= , in storing mode, each RPL Router maintains routes to all destinations in = its sub-DODAG. The child decides which of its parents would receive a DAO. = Further, for each advertized destination, the origin (of the advertisement)= decides (via path control bits) how many separate routes could exist for t= his destination. Section 7.1: "In case a destination is unreachable, all the DODAG Root may do is require all destinations to re-issue their DAOs, by way of issuing a DIO with an increased DODAG version number, possibly provoking a broadcast-storm-like situation. " This problem is easily fixable by a simple DAO solicitation mechanism: root= includes a solicitation in its DIO, routers in the DAG propagate the solic= itation further in their DIOs and when the desired destination receives the= solicitation, it sends the DAO to the root. Pascal has often talked about = writing up this fix. "A final point on the DAO mechanism: RPL supports point-to-point traffic only by way of relaying through the DODAG. In networks where point-to-point traffic is no rare occurrence, this causes unduly long routes (with possibly increased energy consumption, increased probability of packet losses) as well as possibly congestion around the DODAG Root. " Use P2P-RPL in such scenarios. Section 8: Address aggregation and summarization ------------------------------------------------------ I dont agree with the assertion that address aggregation will break down co= mpletely if a node's DAO parent is not same as the one whose advertized pre= fix was used by the node to configure its address. I think DAO parent selec= tion at lower levels wont have too much impact on address aggregation at no= des at upper level. Sure address aggregation may not be possible at the nod= e's parent or grandparent. But, nodes still higher up will be less and less= affected. Also, there might be factual inaccuracy in the text below. " Any aggregated routes require the use of a prefix shorter than /64, and subsequent hierarchical assignment of prefixes down to a /64 (as any RPL Router itself provides a /64 subnet to any hosts connected to the router). Moreover, if the 6lowpan adaption layer [RFC4944] is used in the LLN, route aggregation is not possible since the same /64 is applied across the entire network." I dont think an RPL router has to always advertize a 64 bit prefix to its h= osts. Further, with RFC 6282, I am not sure if only /64 prefix could be use= d for autoconfiguration of 802.15.4 interfaces. So, the assertion "Any aggr= egated routes require the use of a prefix shorter than /64" may not be true= . Section 9: Link assumed bidirectional ------------------------------------------------- "Unidirectional links are no rare occurrence, such as is known from wireless multi-hop networks. Preliminary results from a test-bed of AMI (Automated Metering Infrastructure) devices using 950MHz radio interfaces, and with a total of 22 links, show that 36% of these links are unidirectional." =20 Could the authors provide reference to published literature showing that a = significant fraction of links are unidirectional? The reference to an unpub= lished/unavailable study is not OK. Also, it seems that "950MHz" is a typo. ----- Original Message ----- From: "Philip Levis" To: "Thomas Heide Clausen" Cc: "roll WG" , "Michael Richardson" Sent: Thursday, May 17, 2012 12:02:32 AM Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences On May 16, 2012, at 10:11 AM, Thomas Heide Clausen wrote: >=20 >=20 > For example:=20 >=20 > =09o=09the state required for storing/non-storing mode does *not* depend = on a=20 > =09=09specific implementation and deployment, but is an artifact from the= RPL design. >=20 > =09o=09the message-size of RPL is not dependent on a specific implementat= ion and deployment, > =09=09but is an artifact from the RPL design. >=20 > =09o=09the use of links "upwards" based on receipt of traffic "downwards"= (i.e. the unidirectional > =09=09link issue) is not dependent on a specific implementation and deplo= yment, > =09=09but is an artifact from the RPL design. >=20 > =09o=09the unknown-by-source MTU issues for data-traffic when using non-s= toring mode=20 > =09=09is not dependent on a specific implementation and deployment, > =09=09but is an artifact from the RPL design. >=20 > I could go on, but then it'd be easier to just paste the whole I-D into t= his email. Thomas, I agree that some points in the ID are valid statements about the protocol = itself, such as message sizes and the issues caused by floating DODAGs. Tho= se, to me, seem like reasonable points to make. However, some of the points are hypotheses about performance (14), a bit na= ive about how wireless networks behave (13) or somewhat snippy gripes (11, = 12). In my opinion, a document which focused on factual statements of the p= rotocol design not really open to interpretation and cut hypothetical or su= bjective statements might be ready for the working group to consider. As just a start, I object to 10, 11, 12, 13, and 14 being considered inhere= nt to the protocol. 10 assumes that a node only uses DIO reception to allow a parent; the speci= fication is pretty clear that you should check the parent is usable (sectio= n 1.1). You're taking a bad implementation decision and assuming there isn'= t another way to do things.=20 For 11, there are implementations of RPL smaller than 50kB; they do not imp= lement every feature, but that was kind of the point of the protocol, that = it could be implemented on a sliding scale of implementation complexity. Th= e TinyOS implementation, for example, is, I believe, ~20kB, less than half = the size. You don't report what architecture the 50kB is for, clearly it wo= uld be more for a 32-bit than a 16-bit architecture.=20 For 12, "implementations may exhibit a bad performance if not carefully imp= lemented." I think it is safe to say this is true for almost ANY protocol.= A specification is not intended to be a complete statement of efficient im= plementation, otherwise you give little latitude to future improvements and= good engineering. For 13, this assumes that a wireless network has a stable topology which th= e protocol can converge to. Wireless networks are often NOT stable: one can= not expect a protocol to converge on a dynamic graph. 14 is similarly confused about what a wireless network looks like. How can = the state of a distributed system based on a dynamic topology be "consisten= t?" I think this is a fundamental misunderstanding of how the network works= . That being said, I think point 6 is well taken and should be considered, ma= ybe others. Maybe the constructive way to take this document, if you don't = want to take the step of specifying solutions, is at least casting it as a = roadmap for ways in which you think the WG should improve RPL? Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From robert.assimiti@nivis.com Mon May 21 15:15:13 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 863E021F847B for ; Mon, 21 May 2012 15:15:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, LONGWORDS=1.803] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 80j7vgLIdsQ1 for ; Mon, 21 May 2012 15:15:12 -0700 (PDT) Received: from smtp.nivis.com (smtp.nivis.com [65.205.163.2]) by ietfa.amsl.com (Postfix) with ESMTP id 594B921F847A for ; Mon, 21 May 2012 15:15:12 -0700 (PDT) Received: from ATLEXCH02.nivis.com ([10.0.0.18]) by ATLEXCH02.nivis.com ([10.0.0.18]) with mapi; Mon, 21 May 2012 18:15:11 -0400 From: Robert Assimiti To: "mcr+ietf@sandelman.ca" Date: Mon, 21 May 2012 18:15:09 -0400 Thread-Topic: Proposal for common table of contents for applicability statements Thread-Index: Ac0yzRExqhNFG/2BSO28SQJJDQVLoAE0Ou4g Message-ID: <67442429D9C35E4C975B89BE73BD33D02C756EA722@ATLEXCH02.nivis.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] Proposal for common table of contents for applicability statements X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 May 2012 22:15:13 -0000 Message: 1 Date: Tue, 15 May 2012 13:44:37 -0400 From: Michael Richardson To: roll@ietf.org Subject: [Roll] proposal for common table of contents for applicability statements Message-ID: <10134.1337103877@marajade.sandelman.ca> Content-Type: text/plain; charset=3Dus-ascii -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Here is the table of contents from each of the applicability statements. =20 I thought we had a third applicability statement as an independant draft, b= ut I couldn't find one. We should have a building/home applicability state= ment. I feel that these two applicability statements are over broad, and that each should be split into two or three statements. In particular, I think that Energy-Constrained and Energy-Rich networks should be split into= different documents as they have vastly different requirements. It may be that there is a further split for networks that are dense (urban) vs those that are less dense (suburban or rural). Robert: Michael, the industrial applicability statement mainly addresses en= ergy constrained battery operated instruments. Routers present on the backb= one are typically line powered. We intend to introduce a new section in our= second draft that addressed these energy-rich scenario as well, but having= two separate drafts based solely on this criteria is overkill in my opinio= n. Could we just provide two concise profiles for the two scenarios within = the same draft? A major purpose of these documents is to permit a utility (etc.) to be able= to write an RFP to procure equipment from multiple vendors that can intero= perate. (there are NAFTA, GATT, etc. that governments needs to comply to, = which an RFC easily satisfies) As such, there needs to be enough information as to the profile of RPL to b= e deployed (to each area), such that a vendor can actually implement someth= ing definite. I also feel that these document spend too much time on explaining what RPL = is (and frankly they they do a really good, succint job at it, so I hate to= lose that text, but I don't think it needs to be repeated) Robert: Fully agree that the drafts should be less verbose on explaining wh= at RPL is and focus on concise recommendations for implementation ready pro= files. What I'd like to do (and I invite you to reply inline, keeping just this te= xt, and +1 each part seperately) 1) is to synchronize these two documents' table of contents. =20 2) discuss adopting draft-phinney as a WG document! 3) make sure that we are also detailing security and routing issues properly, and yes, we need to have statments like: "Metering networks using ZigBee FOOBAR MUST in layer-2 have security BAZ enabled in order that RPL messages will be secured." or: "This statement applies to using RPL as the MESH over network on 802.15.4 technology with the 6LowPAN defined nd-18 including RFC6282 HC" The applicability statement is not the place to be general. Let's be specific, and in doing so, let's be succinct. draft-ietf-roll-applicability-ami-05.txt: 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Electric Metering . . . . . . . . . . . . . . . . . . . . 3 1.2. Gas and Water Metering . . . . . . . . . . . . . . . . . . 3 1.3. Routing Protocol for LLNs (RPL) . . . . . . . . . . . . . 4 1.4. Requirements Language . . . . . . . . . . . . . . . . . . 5 2. Deployment Scenarios . . . . . . . . . . . . . . . . . . . . . 5 2.1. Network Topology . . . . . . . . . . . . . . . . . . . . . 5 2.1.1. Electric Meter Network . . . . . . . . . . . . . . . . 5 2.1.2. Energy-Constrained Network Infrastructure . . . . . . 6 2.2. Traffic Characteristics . . . . . . . . . . . . . . . . . 6 2.2.1. Smart Metering Data . . . . . . . . . . . . . . . . . 7 2.2.2. Distribution Automation Communication . . . . . . . . 8 2.2.3. Emerging Applications . . . . . . . . . . . . . . . . 8 3. Using RPL to Meet Functional Requirements . . . . . . . . . . 8 4. RPL Profile . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. RPL Features . . . . . . . . . . . . . . . . . . . . . . . 9 4.1.1. RPL Instances . . . . . . . . . . . . . . . . . . . . 9 4.1.2. Storing vs. Non-Storing Mode . . . . . . . . . . . . . 9 4.1.3. DAO Policy . . . . . . . . . . . . . . . . . . . . . . 10 4.1.4. Path Metrics . . . . . . . . . . . . . . . . . . . . . 10 4.1.5. Objective Function . . . . . . . . . . . . . . . . . . 10 4.1.6. DODAG Repair . . . . . . . . . . . . . . . . . . . . . 11 4.1.7. Multicast . . . . . . . . . . . . . . . . . . . . . . 11 4.1.8. Security . . . . . . . . . . . . . . . . . . . . . . . 12 4.1.9. P2P communications . . . . . . . . . . . . . . . . . . 12 4.2. Recommended Configuration Defaults and Ranges . . . . . . 12 4.2.1. Trickle Parameters . . . . . . . . . . . . . . . . . . 12 4.2.2. Other Parameters . . . . . . . . . . . . . . . . . . . 13 5. Manageability Considerations . . . . . . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. Other Related Protocols . . . . . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Informative References . . . . . . . . . . . . . . . . . . 15 10.2. Normative References . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 draft-phinney-rpl-industrial-applicability-00: 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Deployment scenarii . . . . . . . . . . . . . . . . . . . 7 3.2. Applications and Traffic classes . . . . . . . . . . . . . 9 3.3. RPL applicability matrix . . . . . . . . . . . . . . . . . 10 4. Characterization of communication flows in IACS wireless networks . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Source-sink (SS) communication paradigm . . . . . . . . . 13 4.3. Publish-subscribe (PS, or pub/sub) communication paradigm . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Peer-to-peer (P2P) communication paradigm . . . . . . . . 15 4.5. Peer-to-multipeer (P2MP) communication paradigm . . . . . 16 4.6. Additional considerations: Duocast and N-cast . . . . . . 17 4.7. RPL applicability per communication paradigm . . . . . . . 18 5. RPL profile . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Use for process control . . . . . . . . . . . . . . . . . 21 5.2. RPL features . . . . . . . . . . . . . . . . . . . . . . . 21 5.2.1. Storing vs. non-storing mode . . . . . . . . . . . . . 21 5.2.2. DAO policy . . . . . . . . . . . . . . . . . . . . . . 21 5.2.3. Path metrics . . . . . . . . . . . . . . . . . . . . . 22 5.2.4. Objective functions . . . . . . . . . . . . . . . . . 22 5.2.5. DODAG repair . . . . . . . . . . . . . . . . . . . . . 22 5.2.6. Security . . . . . . . . . . . . . . . . . . . . . . . 22 5.3. RPL options . . . . . . . . . . . . . . . . . . . . . . . 22 5.4. Recommended configuration defaults and ranges . . . . . . 22 5.4.1. Trickle parameters . . . . . . . . . . . . . . . . . . 22 5.4.2. Other parameters . . . . . . . . . . . . . . . . . . . 23 5.4.3. Additional configuration recommendations . . . . . . . 23 6. Other related protocols . . . . . . . . . . . . . . . . . . . 24 7. Manageability . . . . . . . . . . . . . . . . . . . . . . . . 25 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 26 9. Security considerations . . . . . . . . . . . . . . . . . . . 27 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 11.1. Normative References . . . . . . . . . . . . . . . . . . . 29 11.2. Informative References . . . . . . . . . . . . . . . . . . 29 11.3. External Informative References . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 - -- Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUBT7KWBIqHRg3pndX9AQKEDgP/ddKMasN7jRNVl6ZGAtCchSYeV/0oUSQ0 Gn8FSRCbacZosnchjVDuDz5MMV4MToC8BPgBh2n0qW4jTpYK8KTPiwhGcJUgkwtv n1xmEJj6d9kftudUCFfmh2WlrXaPWlYdndM/avulkGK8mOVYphHYrtxf4nbyj1HV Y3ChARZ5nUM=3D =3D8qRA -----END PGP SIGNATURE----- ------------------------------ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll End of Roll Digest, Vol 52, Issue 15 ************************************ From Martin.Heusse@imag.fr Tue May 22 07:38:59 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62E4B21F85C4 for ; Tue, 22 May 2012 07:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4AtnTC9tInXy for ; Tue, 22 May 2012 07:38:59 -0700 (PDT) Received: from shiva.imag.fr (mx1.imag.fr [IPv6:2001:660:5301:6::5]) by ietfa.amsl.com (Postfix) with ESMTP id AD26121F8539 for ; Tue, 22 May 2012 07:38:58 -0700 (PDT) Received: from globule.imag.fr (globule.imag.fr [129.88.34.238]) by shiva.imag.fr (8.13.8/8.13.8) with ESMTP id q4MEV0IJ004848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 22 May 2012 16:31:00 +0200 Received: from scilly.imag.fr (scilly.imag.fr [129.88.48.164]) (authenticated bits=0) by globule.imag.fr (8.13.8/8.13.8) with ESMTP id q4MEiUs7021319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 22 May 2012 16:44:30 +0200 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1278) From: Martin Heusse In-Reply-To: Date: Tue, 22 May 2012 16:40:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3C7FEA98-FEED-48B0-9FBA-1E9F7E8EDD11@imag.fr> References: <258D7E2F-F0C7-49EA-B831-81070C86EDB3@thomasclausen.org> <2257A578-B2DF-4145-8393-9BB5D7E1CFBD@cisco.com> <2225986E-992E-43C7-B0CA-9CDA91CE1F3A@thomasclausen.org> <0958556A-7D9A-4E8B-8091-1D6EC0B813B4@thomasclausen.org> <91E71E23-8797-4C70-A1F8-1CE64BD4ED39@thomasclausen.org> <1D6FEB49-CB62-4FFA-9E34-3FEF82DB644C@cisco.com> <78FB3B50-3150-4729-A089-D9EAF0B02BB6@cs.stanford.edu> <2AF45E51-6C3B-48D9-908F-117ECF0CABAA@imag.fr> To: roll WG X-Mailer: Apple Mail (2.1278) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.0.1 (shiva.imag.fr [129.88.30.5]); Tue, 22 May 2012 16:31:00 +0200 (CEST) X-IMAG-MailScanner-Information: Please contact MI2S MIM for more information X-MailScanner-ID: q4MEV0IJ004848 X-IMAG-MailScanner: Found to be clean X-IMAG-MailScanner-SpamCheck: X-IMAG-MailScanner-From: martin.heusse@imag.fr MailScanner-NULL-Check: 1338301863.50381@DaTMXIR0RJBCtm6F6LgqLA Subject: Re: [Roll] Way forward for draft-clausen-lln-rpl-experiences X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 May 2012 14:38:59 -0000 Jean-Philippe, you wrote: > How often do you think that ISIS LSA should be refreshed ? > Or OSPF opaque LSA for TE extensions be flooded ? --> "It depends"? I am not saying that we would need to mention in the (general) RFC when, = or at which rate, - global repairs should take place or; - DAO should be sent out on a regular basis=85 (Although this could perfectly appear in applicability, isn't it?) My point was that the DAO mechanisms are not so clearly defined... Which = may be fine: then Mukul is right and if you really need to reach = everyone, then P2P RPL is there... Right now, there can be a problem with DAOs - if they are lost along the way (not unlikely if not using DAO-ACKs = **even with L2 ACKs**, still possible otherwise)=20 - if a sub-dodag moves... all routes are broken, and we don't really = know how to re-establish them (although DTSN could help here, although = it's a little vague) - if an inconsistency is detected on a downward route, you'd have to ask = everyone to re-send DAOs (Pascal's DAO requests would have helped of = course -- this shows up on the list every now and then). --> for opaque LSA, the information in the packet does not matter, but = the flooding mechanism is robust and well defined. For DAOs, we know how = the packet must look like... > Or BFD packets ?=20 > Or PCEP Keepalive when turned on ? >=20 > Very seriously =85 these questions apply to all protocols =85 and you = cannot expect the specifications to give you > hard coded values (but default whenever possible); these are topology = and application specific, don't you think ? Yes, I agree!=20 Martin= From mcr@sandelman.ca Wed May 23 07:13:54 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C42AC21F8702 for ; Wed, 23 May 2012 07:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.787 X-Spam-Level: X-Spam-Status: No, score=-1.787 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vy5hCtcjPTBg for ; Wed, 23 May 2012 07:13:54 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6121B21F86D4 for ; Wed, 23 May 2012 07:13:53 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id B5DC68694; Wed, 23 May 2012 10:12:16 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 4EDC6CD4D5; Wed, 23 May 2012 10:13:50 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4930ADC015; Wed, 23 May 2012 10:13:50 -0400 (EDT) From: Michael Richardson To: "roll@ietf.org" In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD0ABE8F25@cph-ex1> References: <20120430114209.21250.82110.idtracker@ietfa.amsl.com> <18151.1335822136@marajade.sandelman.ca> <10134.1337103877@marajade.sandelman.ca> <03F31C213F2C6941BFDDBB4336E9E6CD0ABE8F25@cph-ex1> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 23 May 2012 10:13:50 -0400 Message-ID: <22501.1337782430@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Anders Brandt Subject: Re: [Roll] proposal for common table of contents for applicability statements X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 May 2012 14:13:54 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Anders" =3D=3D Anders Brandt writes: Anders> It is here Anders> http://tools.ietf.org/html/draft-brandt-roll-rpl-applicability-= home-building-01 Anders> In its current state it is more like a problem statement... It expired. Can you at least repost the -01 document (as -02)? I would like to propose that this become a WG document. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT7zwnoqHRg3pndX9AQKDKwP/SLFqO7KT6kGI+hU9FB24MresB+EBwwZb rmAoPdVpufj0EnoJ68sWOidz1O5Q5BZJqwbyiqHY1ThKc3LVuYkMPFFBfd8E5LSb O12n494EyIBuPq1SxfHItwxGupMV7bGMcea6oXyHPtCYelSC8U1bcEGCadAM+Z0r a+e6FA46Z60= =zb7R -----END PGP SIGNATURE----- --=-=-=-- From jpv@cisco.com Wed May 23 14:50:36 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEBC21F8624 for ; Wed, 23 May 2012 14:50:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.522 X-Spam-Level: X-Spam-Status: No, score=-109.522 tagged_above=-999 required=5 tests=[AWL=1.077, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bw7xe0eEsn6i for ; Wed, 23 May 2012 14:50:36 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id E027B21F8623 for ; Wed, 23 May 2012 14:50:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=11056; q=dns/txt; s=iport; t=1337809834; x=1339019434; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=Z/cijLCbtYOzByBaH+lbSbIRfsHid5rCbv2S4l9IO8Q=; b=GjRwDQT622kx0/cSUYn+z/ImLpDnzh79+ln0mZbefJZ7xjN4A498zCfD mu4mFFixQlkVXZP1E9rfVw0duckTAA9M70H5yYT9aYTMOMlQBHSIt/sAD FBO6BpyNY6c8U0p90kmVUpcBP7O2HzK7zkz3ic7DPDlCTibZdg41wznlL Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAHxbvU9Io8UY/2dsb2JhbABDgx2yF4IVAQEBAwEBAQEPAVsLBQscAwECAS4nKAgGEwkZh2YFC5sgn3OKfSSEHGADlRiFT4g9gWSCbA X-IronPort-AV: E=Sophos;i="4.75,646,1330905600"; d="scan'208,217";a="12861523" Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 23 May 2012 21:50:15 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by bgl-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q4NLoFBd021065; Wed, 23 May 2012 21:50:15 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); Thu, 24 May 2012 05:50:14 +0800 Received: from [10.60.114.229] ([10.60.114.229]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 May 2012 05:50:12 +0800 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_CC70080F-2D2B-463A-B3E1-B78F192CA0B4" From: JP Vasseur In-Reply-To: <66E2061B-4866-4276-B69A-6FD150D6EB93@cisco.com> Date: Wed, 23 May 2012 23:44:16 +0200 Message-Id: <258174AC-25D5-447B-B9A1-11DE371CACD3@cisco.com> References: <9850315F-B3E6-4A29-AAD5-B53E6C978F69@thomasclausen.org> <66E2061B-4866-4276-B69A-6FD150D6EB93@cisco.com> To: roll WG X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 23 May 2012 21:50:13.0217 (UTC) FILETIME=[082EB510:01CD392E] Cc: Michael Richardson Subject: [Roll] reminder - end of second WG LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 May 2012 21:50:37 -0000 --Apple-Mail=_CC70080F-2D2B-463A-B3E1-B78F192CA0B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Second last call on > * draft-ietf-roll-p2p-measurement-05 and=20 > * draft-ietf-roll-p2p-rpl-12 will end May 25th at noon ET, just a reminder. Thanks. JP. On May 11, 2012, at 2:20 PM, JP Vasseur wrote: > Dear all, >=20 > A first WG Last Call took place on March 16th on: > * draft-ietf-roll-p2p-measurement-04 and=20 > * draft-ietf-roll-p2p-rpl-09 >=20 > Thanks to all of you for the fruitful and constructive comments = received during WG Last call, that led=20 > to several tickets that have been successfully closed, leading to new = revisions of these documents. >=20 > This starts a new 2-week WG last call on: > * draft-ietf-roll-p2p-measurement-05 and=20 > * draft-ietf-roll-p2p-rpl-12 >=20 > The WG Last call will end on May 25th at noon ET. Please send your = comments on the mailing list and copy the authors. >=20 > Thanks. >=20 > JP and Michael. =20 >=20 >=20 > Begin forwarded message: >=20 >> From: Thomas Heide Clausen >> Subject: Re: [Roll] RPL-P2P - status & update >> Date: April 13, 2012 11:21:00 PM GMT+02:00 >> To: JP Vasseur >> Cc: "roll@ietf.org WG" >>=20 >> Dear JP, >>=20 >> Sounds quite reasonable. >>=20 >> Have a pleasant weekend you too - I will be spending mine recovering = from week-long meetings in the bay area... >>=20 >> Best, >>=20 >> Thomas >>=20 >> On Apr 13, 2012, at 14:16 , JP Vasseur wrote: >>=20 >>> Hi Thomas, >>>=20 >>> Clarifying a bit more =85 what I meant =85 >>>=20 >>> Plan is: >>> * Close on the last open ticket >>> * Authors will post a new revision of the document, possibly = highlighting the changes >>> * Issue another WG LC to make sure that the WG is comfortable with = the new revision >>>=20 >>> Thanks, have a good week-end. >>>=20 >>> JP. >>>=20 >>> On Apr 13, 2012, at 9:03 PM, JP Vasseur wrote: >>>=20 >>>> Hi Thomas, >>>>=20 >>>> Absolutely, the plan was to run another incremental Last Call, on = the new revision. >>>>=20 >>>> Cheers. >>>>=20 >>>> JP. >>>>=20 >>>> On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen wrote: >>>>=20 >>>>> Hello folks, >>>>>=20 >>>>> I've been trying to follow the many mails exchanged as a = consequence of the WGLC of RPL-P2P. >>>>>=20 >>>>> Given the volume of changes to the document, I would like to ask = that - once the authors estimate that a version of the I-D folding in = all proposed changes is ready - the WG be given another 1-2 weeks WGLC = before bouncing it off to the ADs? >>>>>=20 >>>>> This just to ensure that the WG gets to give the final version a = good review before seeing it off. >>>>>=20 >>>>> Thoughts? >>>>>=20 >>>>> Thomas >>>>>=20 >>>>> --=20 >>>>> Thomas Heide Clausen >>>>> http://www.thomasclausen.org/ >>>>>=20 >>>>> "Any simple problem can be made insoluble if enough meetings are = held to >>>>> discuss it." >>>>> -- Mitchell's Law of Committees >>>>>=20 >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>=20 >>=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_CC70080F-2D2B-463A-B3E1-B78F192CA0B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
* = draft-ietf-roll-p2p-measurement-05 and 
* = draft-ietf-roll-p2p-rpl-12
Dear = all,

A first WG Last Call took place on March 16th = on:
* draft-ietf-roll-p2p-measurement-04 and 
* = draft-ietf-roll-p2p-rpl-09

Thanks to all of you = for the fruitful and constructive comments received during WG Last call, = that led 
to several tickets that have been successfully = closed, leading to new revisions of these = documents.

This starts a new 2-week WG last = call on:
* draft-ietf-roll-p2p-measurement-05 = and 
* = draft-ietf-roll-p2p-rpl-12

The WG Last = call will end on May 25th at noon ET. Please send your = comments on the mailing list and copy the = authors.

Thanks.

JP = and Michael. =  


Begin = forwarded message:

From: Thomas Heide = Clausen <ietf@thomasclausen.org>
<= /span>
Subject: Re: [Roll] RPL-P2P - status & = update
Date: April 13, 2012 11:21:00 PM = GMT+02:00
To: JP Vasseur <jpv@cisco.com>

Dear = JP,

Sounds quite = reasonable.

Have a pleasant weekend you too - I = will be spending mine recovering from week-long meetings in the bay = area...

Best,

Thomas

On Apr 13, 2012, at 14:16 , JP Vasseur = wrote:

Hi = Thomas,

Clarifying a bit more =85 what I meant = =85

Plan is:
* Close on the last open = ticket
* Authors will post a new revision of the document, = possibly highlighting the changes
* Issue another WG LC to = make sure that the WG is comfortable with the new = revision

Thanks, have a good = week-end.

JP.

On Apr = 13, 2012, at 9:03 PM, JP Vasseur wrote:

Hi = Thomas,

Absolutely, the plan was to run another = incremental Last Call, on the new = revision.

Cheers.

JP.

On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen = wrote:

Hello folks,

I've been trying to follow the = many mails exchanged as a consequence of the WGLC of = RPL-P2P.

Given the volume of changes to the document, I would = like to ask that - once the authors estimate that a version of the I-D = folding in all proposed changes is ready - the WG be given another 1-2 = weeks WGLC before bouncing it off to the ADs?

This just to ensure = that the WG gets to give the final version a good review before seeing = it off.

Thoughts?

Thomas

--
Thomas Heide = Clausen
http://www.thomasclausen.org/
"Any simple problem can be made insoluble if enough meetings are = held to
discuss it."
  -- Mitchell's Law of = Committees

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

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



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

= --Apple-Mail=_CC70080F-2D2B-463A-B3E1-B78F192CA0B4-- From trakadasp@yahoo.gr Thu May 24 02:31:56 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 126C421F857D for ; Thu, 24 May 2012 02:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XnXnNIuFTpKC for ; Thu, 24 May 2012 02:31:55 -0700 (PDT) Received: from nm19.bullet.mail.ird.yahoo.com (nm19.bullet.mail.ird.yahoo.com [77.238.189.76]) by ietfa.amsl.com (Postfix) with SMTP id D646721F8577 for ; Thu, 24 May 2012 02:31:54 -0700 (PDT) Received: from [77.238.189.51] by nm19.bullet.mail.ird.yahoo.com with NNFMP; 24 May 2012 09:31:50 -0000 Received: from [212.82.108.238] by tm4.bullet.mail.ird.yahoo.com with NNFMP; 24 May 2012 09:31:50 -0000 Received: from [127.0.0.1] by omp1003.mail.ird.yahoo.com with NNFMP; 24 May 2012 09:31:50 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 660175.445.bm@omp1003.mail.ird.yahoo.com Received: (qmail 5094 invoked by uid 60001); 24 May 2012 09:31:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.gr; s=s1024; t=1337851910; bh=xjDMa0RRtgJNfvGsTFqyUfqX0vkJF0j9tp3sHzm0bac=; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=cXO9PQvhzgVh38FU/kYZ+f/Q2tVYvIiRLVQ37lveyT+yhK6ZhLY/SMMYIUhs3PZCr/i9HnPTU7IBaYzhUU+Kqf07xaFNrRXTrVbcFb7bGzAclRHXddzfVtmpxEnCqIkIvHVlGcjhtdh2BKjaqQ2wiLun06lVq2MgyACSEXBVabo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.gr; h=X-YMail-OSG:Received:X-Mailer:Message-ID:Date:From:Reply-To:Subject:To:MIME-Version:Content-Type; b=IQ94n9VgA9uFNFlgO5eCDtRPR3wgqomIZ9W9aSmVMo/ElEmd0NqP7kgq2JH2eQoqg0BICSlGmWvYKEvFYFQyD3szghraxAmDB6d/4TEThJPDIfwwlofFFTSKp1nn1aYWljv8suDXUtVV7ln6FPGAvWROv7zC0lXR+7nfLSlok+I=; X-YMail-OSG: STFoHHEVM1nSviG5wzrHYPMe1m.74_25upXJsuy26ndQjFY PTVTd60YqchxmctLLaP0wom5WPbzdqDI_0Fe5IZ5En1gqj4E1A7axS7wnCAF 2QgWfyaB3dJKNVx.tS3BrYUQD2Vz7WG8nG.i6ennHaK94A98YL8liVKKWmk5 .v16c9tW3OLiv_0D2d7WT9.KpEZOvERM71gUurrgDayQ1AHclPOrOdb0p8Sf RcPpUQd72_M4O1xB9DTETW5hslpct7uEZKoH7XARjH6SLLTDyZpvE0Im.NMP K3pSTpJwMy3yzxmDSohLFK_P6jPR8WYylx1.03vLjnsL0qT53UkG_ROwFXlg _ZDbCkjPX5AkMNp7Z3oH1jATojUnf0mxSKa.3CNd4h2nWfv6wG3eg9Ob.r.F 6okMnGmE7XJLQSngi1fKKh4Cds9Pcl2PQscs- Received: from [83.235.46.66] by web29606.mail.ird.yahoo.com via HTTP; Thu, 24 May 2012 10:31:50 BST X-Mailer: YahooMailWebService/0.8.118.349524 Message-ID: <1337851910.77994.YahooMailNeo@web29606.mail.ird.yahoo.com> Date: Thu, 24 May 2012 10:31:50 +0100 (BST) From: Panos Trakadas To: roll WG MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-796194823-1010839599-1337851910=:77994" Subject: [Roll] New version of draft-zahariad-roll-metrics-composition X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Panos Trakadas List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 May 2012 09:31:56 -0000 ---796194823-1010839599-1337851910=:77994 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Dear all,=0AAn updated version of the document titled "Design Guidelines fo= r Routing Metrics Composition in LLN" has been uploaded, adding a new secti= on (section 5 in version 03) where we highlight generic rules for utilizing= composition approaches.=0ASoon we are planning to specify composition rule= s and guidelines for metrics commonly used per application domain (as descr= ibed within the respective RFCs (5548, 5673, 5826, 5867) ).=0AWe are lookin= g forward for comments or propositions.=0A=0ABest Regards,=0APanos Trakadas= . ---796194823-1010839599-1337851910=:77994 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Dear all,
<= div>An updated version of the document titled "Design Guidelines for Routin= g Metrics Composition in LLN" has been uploaded, adding a new section (sect= ion 5 in version 03) where we highlight generic rules for utilizing composi= tion approaches.
Soon we are planning to specify composition rule= s and guidelines for metrics commonly used per application domain (as descr= ibed within the respective RFCs (5548, 5673, 5826, 5867) ).
We are looking forward fo= r comments or propositions.

Best Regards,
Panos Trakadas.

---796194823-1010839599-1337851910=:77994-- From pthubert@cisco.com Thu May 24 04:55:25 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C439121F863E for ; Thu, 24 May 2012 04:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ep7ER5oIOGe1 for ; Thu, 24 May 2012 04:55:23 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 3F10721F8643 for ; Thu, 24 May 2012 04:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17895; q=dns/txt; s=iport; t=1337860523; x=1339070123; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ryWfU3Rs7gdClYI+zzFhyqFQWfgURQmhIMxZUQdqsS4=; b=MIFRRycCxZNwV33+eTUnqDzO9w1ImxavWnU+YlmC2AHoY0X95j3/9E9W 8OM28L7JZL5ELkt3AfC7ZoO6LnbjvKfzd0fPC05eCx0uTcS+CRzufh9Wd dPl3LBoruMgy/Cd8ueylxp4IjiS/Lue4YZHo2q8w9t9hO5LV3YOuhJiaW Y=; X-IronPort-AV: E=Sophos;i="4.75,649,1330905600"; d="scan'208,217";a="83258851" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-9.cisco.com with ESMTP; 24 May 2012 11:55:22 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q4OBtMET012270 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 May 2012 11:55:22 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.176]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0298.004; Thu, 24 May 2012 06:55:22 -0500 From: "Pascal Thubert (pthubert)" To: JP Vasseur , roll WG Thread-Topic: [Roll] reminder - end of second WG LC Thread-Index: AQHNOS4abwvayPVMQ0mJKdOZhJ5g7pbY1SBQ Date: Thu, 24 May 2012 11:55:22 +0000 Deferred-Delivery: Thu, 24 May 2012 11:55:00 +0000 Message-ID: References: <9850315F-B3E6-4A29-AAD5-B53E6C978F69@thomasclausen.org> <66E2061B-4866-4276-B69A-6FD150D6EB93@cisco.com> <258174AC-25D5-447B-B9A1-11DE371CACD3@cisco.com> In-Reply-To: <258174AC-25D5-447B-B9A1-11DE371CACD3@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.254.53.128] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18924.006 x-tm-as-result: No--57.586500-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD806B0AFxmbrcdx01ciscocom_" MIME-Version: 1.0 Cc: Michael Richardson Subject: Re: [Roll] reminder - end of second WG LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 May 2012 11:55:25 -0000 --_000_E045AECD98228444A58C61C200AE1BD806B0AFxmbrcdx01ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable JP: I find that draft-ietf-roll-p2p-rpl-12 is ready for IESG review. Thanks a bunch to the authors and, in particular, to Mukul for all this har= d work. Cheers, Pascal From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP = Vasseur Sent: mercredi 23 mai 2012 23:44 To: roll WG Cc: Michael Richardson Subject: [Roll] reminder - end of second WG LC Second last call on * draft-ietf-roll-p2p-measurement-05 and * draft-ietf-roll-p2p-rpl-12 will end May 25th at noon ET, just a reminder. Thanks. JP. On May 11, 2012, at 2:20 PM, JP Vasseur wrote: Dear all, A first WG Last Call took place on March 16th on: * draft-ietf-roll-p2p-measurement-04 and * draft-ietf-roll-p2p-rpl-09 Thanks to all of you for the fruitful and constructive comments received du= ring WG Last call, that led to several tickets that have been successfully closed, leading to new revis= ions of these documents. This starts a new 2-week WG last call on: * draft-ietf-roll-p2p-measurement-05 and * draft-ietf-roll-p2p-rpl-12 The WG Last call will end on May 25th at noon ET. Please send your comments= on the mailing list and copy the authors. Thanks. JP and Michael. Begin forwarded message: From: Thomas Heide Clausen > Subject: Re: [Roll] RPL-P2P - status & update Date: April 13, 2012 11:21:00 PM GMT+02:00 To: JP Vasseur > Cc: "roll@ietf.org WG" > Dear JP, Sounds quite reasonable. Have a pleasant weekend you too - I will be spending mine recovering from w= eek-long meetings in the bay area... Best, Thomas On Apr 13, 2012, at 14:16 , JP Vasseur wrote: Hi Thomas, Clarifying a bit more ... what I meant ... Plan is: * Close on the last open ticket * Authors will post a new revision of the document, possibly highlighting t= he changes * Issue another WG LC to make sure that the WG is comfortable with the new = revision Thanks, have a good week-end. JP. On Apr 13, 2012, at 9:03 PM, JP Vasseur wrote: Hi Thomas, Absolutely, the plan was to run another incremental Last Call, on the new r= evision. Cheers. JP. On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen wrote: Hello folks, I've been trying to follow the many mails exchanged as a consequence of the= WGLC of RPL-P2P. Given the volume of changes to the document, I would like to ask that - onc= e the authors estimate that a version of the I-D folding in all proposed ch= anges is ready - the WG be given another 1-2 weeks WGLC before bouncing it = off to the ADs? This just to ensure that the WG gets to give the final version a good revie= w before seeing it off. Thoughts? Thomas -- Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_E045AECD98228444A58C61C200AE1BD806B0AFxmbrcdx01ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

JP:

 <= /p>

I find that draft-ietf-ro= ll-p2p-rpl-12 is ready for IESG review.

Thanks a bunch to the aut= hors and, in particular, to Mukul for all this hard work.=

 <= /p>

Cheers,=

 <= /p>

Pascal<= /p>

 <= /p>

From: roll-bou= nces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur
Sent: mercredi 23 mai 2012 23:44
To: roll WG
Cc: Michael Richardson
Subject: [Roll] reminder - end of second WG LC

 

Second last call on

 

* draft-ietf-roll-p2p-measurement-05 and <= /o:p>

* draft-ietf-roll-p2p-rpl-12

 

will end May 25th at noon ET, just a reminder.<= /o:p>

 

Thanks.

 

JP.

 

On May 11, 2012, at 2:20 PM, JP Vasseur wrote:<= /o:p>



Dear all,

 

A first WG Last Call took place on March 16th on:

* draft-ietf-roll-p2p-measurement-04 and <= /o:p>

* draft-ietf-roll-p2p-rpl-09

 

Thanks to all of you for the fruitful and constructi= ve comments received during WG Last call, that led 

to several tickets that have been successfully close= d, leading to new revisions of these documents.

 

This starts a new 2-week WG last call on:=

* draft-ietf-roll-p2p-measurement-05 and <= /o:p>

* draft-ietf-roll-p2p-rpl-12

 

The WG Last call will end on May 25th at noon ET.&nb= sp;Please send your comments on the mailing list and copy the aut= hors.

 

Thanks.

 

JP and Michael.  

 

 

Begin forwarded message:



From: Thomas Heide Clausen <ietf@thomasclausen.org>

Subject: Re: [Roll] RPL-P2P - stat= us & update

Date: April 13, 2012 11:21:00 PM GMT+02:00

To: JP Vasseur <j= pv@cisco.com>

 

Dear JP,

 

Sounds quite reasonable.

 

Have a pleasant weekend you too - I will be spending= mine recovering from week-long meetings in the bay area...

 

Best,

 

Thomas

 

On Apr 13, 2012, at 14:16 , JP Vasseur wrote:



Hi Thomas,

 

Clarifying a bit more … what I meant …

 

Plan is:

* Close on the last open ticket

* Authors will post a new revision of the document, = possibly highlighting the changes

* Issue another WG LC to make sure that the WG is co= mfortable with the new revision

 

Thanks, have a good week-end.

 

JP.

 

On Apr 13, 2012, at 9:03 PM, JP Vasseur wrote:<= /o:p>



Hi Thomas,

 

Absolutely, the plan was to run another increm= ental Last Call, on the new revision.

 

Cheers.

 

JP.

 

On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen wr= ote:



Hello folks,

I've been trying to follow the many mails exchanged as a consequence of the= WGLC of RPL-P2P.

Given the volume of changes to the document, I would like to ask that - onc= e the authors estimate that a version of the I-D folding in all proposed ch= anges is ready - the WG be given another 1-2 weeks WGLC before bouncing it = off to the ADs?

This just to ensure that the WG gets to give the final version a good revie= w before seeing it off.

Thoughts?

Thomas

--
Thomas Heide Clausen
http://www.thomasclausen.org/=

"Any simple problem can be made insoluble if enough meetings are held = to
discuss it."
  -- Mitchell's Law of Committees

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

 

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

 

 

 

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

 

--_000_E045AECD98228444A58C61C200AE1BD806B0AFxmbrcdx01ciscocom_-- From jpv@cisco.com Thu May 24 06:28:00 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B4D621F8679 for ; Thu, 24 May 2012 06:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.06 X-Spam-Level: X-Spam-Status: No, score=-110.06 tagged_above=-999 required=5 tests=[AWL=0.538, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BRazq3oGu6XQ for ; Thu, 24 May 2012 06:27:59 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 116E821F864D for ; Thu, 24 May 2012 06:27:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=31609; q=dns/txt; s=iport; t=1337866077; x=1339075677; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=h5VVyIrKqIaLP4EP0XAZwTkw+Df10DMdQuFAtCSo/f4=; b=D9H7cJoJLmeoye3ZlBtFXZ4IbPlqdy83ln/UDU5fAzxPQbcwnYOyuHDD nbZorc6rUEJnlVEVomR8U4cEuaEq3viboOaE29ZDX1olHaF8jewKvmAyX yH8YoMAQJB8u75OvWVyX5rZblQyE731sTeVq6T/Es8mqevaaUZ7+S/PTX s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqYEACE2vk9Io8UY/2dsb2JhbABDgkVYsjCCFQEBAQMBAQEBDwFbCwULCxEDAQEBASABBgcnHwkIBhMJGYdmBQubJZ98in8khBxgA5UYhU+IPYFkgmw X-IronPort-AV: E=Sophos;i="4.75,651,1330905600"; d="scan'208,217";a="12931646" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 24 May 2012 13:27:55 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4ODRsdP031257; Thu, 24 May 2012 13:27:54 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); Thu, 24 May 2012 21:27:54 +0800 Received: from [10.60.114.229] ([10.60.114.229]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 May 2012 21:27:49 +0800 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_F23BDD04-B74C-4ACB-A56D-8323D2DA98CA" From: JP Vasseur In-Reply-To: Date: Thu, 24 May 2012 15:27:46 +0200 Message-Id: <04955E8C-5BBD-4B8A-9C59-F643E9C4269E@cisco.com> References: <9850315F-B3E6-4A29-AAD5-B53E6C978F69@thomasclausen.org> <66E2061B-4866-4276-B69A-6FD150D6EB93@cisco.com> <258174AC-25D5-447B-B9A1-11DE371CACD3@cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 24 May 2012 13:27:49.0325 (UTC) FILETIME=[036F8FD0:01CD39B1] Cc: roll WG , Michael Richardson Subject: Re: [Roll] reminder - end of second WG LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 May 2012 13:28:00 -0000 --Apple-Mail=_F23BDD04-B74C-4ACB-A56D-8323D2DA98CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 No, both documents are still under WG Last call. Thanks. JP. On May 24, 2012, at 1:55 PM, Pascal Thubert (pthubert) wrote: > JP: > =20 > I find that draft-ietf-roll-p2p-rpl-12 is ready for IESG review. > Thanks a bunch to the authors and, in particular, to Mukul for all = this hard work. > =20 > Cheers, > =20 > Pascal > =20 > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of JP Vasseur > Sent: mercredi 23 mai 2012 23:44 > To: roll WG > Cc: Michael Richardson > Subject: [Roll] reminder - end of second WG LC > =20 > Second last call on > =20 > * draft-ietf-roll-p2p-measurement-05 and=20 > * draft-ietf-roll-p2p-rpl-12 > =20 > will end May 25th at noon ET, just a reminder. > =20 > Thanks. > =20 > JP. > =20 > On May 11, 2012, at 2:20 PM, JP Vasseur wrote: >=20 >=20 > Dear all, > =20 > A first WG Last Call took place on March 16th on: > * draft-ietf-roll-p2p-measurement-04 and=20 > * draft-ietf-roll-p2p-rpl-09 > =20 > Thanks to all of you for the fruitful and constructive comments = received during WG Last call, that led=20 > to several tickets that have been successfully closed, leading to new = revisions of these documents. > =20 > This starts a new 2-week WG last call on: > * draft-ietf-roll-p2p-measurement-05 and=20 > * draft-ietf-roll-p2p-rpl-12 > =20 > The WG Last call will end on May 25th at noon ET. Please send your = comments on the mailing list and copy the authors. > =20 > Thanks. > =20 > JP and Michael. =20 > =20 > =20 > Begin forwarded message: >=20 >=20 > From: Thomas Heide Clausen > Subject: Re: [Roll] RPL-P2P - status & update > Date: April 13, 2012 11:21:00 PM GMT+02:00 > To: JP Vasseur > Cc: "roll@ietf.org WG" > =20 > Dear JP, > =20 > Sounds quite reasonable. > =20 > Have a pleasant weekend you too - I will be spending mine recovering = from week-long meetings in the bay area... > =20 > Best, > =20 > Thomas > =20 > On Apr 13, 2012, at 14:16 , JP Vasseur wrote: >=20 >=20 > Hi Thomas, > =20 > Clarifying a bit more =85 what I meant =85 > =20 > Plan is: > * Close on the last open ticket > * Authors will post a new revision of the document, possibly = highlighting the changes > * Issue another WG LC to make sure that the WG is comfortable with the = new revision > =20 > Thanks, have a good week-end. > =20 > JP. > =20 > On Apr 13, 2012, at 9:03 PM, JP Vasseur wrote: >=20 >=20 > Hi Thomas, > =20 > Absolutely, the plan was to run another incremental Last Call, on the = new revision. > =20 > Cheers. > =20 > JP. > =20 > On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen wrote: >=20 >=20 > Hello folks, >=20 > I've been trying to follow the many mails exchanged as a consequence = of the WGLC of RPL-P2P. >=20 > Given the volume of changes to the document, I would like to ask that = - once the authors estimate that a version of the I-D folding in all = proposed changes is ready - the WG be given another 1-2 weeks WGLC = before bouncing it off to the ADs? >=20 > This just to ensure that the WG gets to give the final version a good = review before seeing it off. >=20 > Thoughts? >=20 > Thomas >=20 > --=20 > Thomas Heide Clausen > http://www.thomasclausen.org/ >=20 > "Any simple problem can be made insoluble if enough meetings are held = to > discuss it." > -- Mitchell's Law of Committees >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > =20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > =20 > =20 > =20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > =20 --Apple-Mail=_F23BDD04-B74C-4ACB-A56D-8323D2DA98CA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 No, both documents are still under WG Last = call.

Thanks.

JP.
On May 24, 2012, at 1:55 PM, Pascal Thubert (pthubert) = wrote:

I = find that draft-ietf-roll-p2p-rpl-12 is ready for IESG = review.
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org= ] On Behalf Of JP = Vasseur
Sent: mercredi 23 mai 2012 = 23:44
To: roll= WG
Cc: Michael = Richardson
Subject: [Roll] reminder - end of = second WG LC
Second last call = on
* = draft-ietf-roll-p2p-measurement-05 = and 
* = draft-ietf-roll-p2p-rpl-12
=
will end May 25th at noon ET, just a = reminder.
On May 11, = 2012, at 2:20 PM, JP Vasseur wrote:


Dear = all,
A first WG Last Call took = place on March 16th on:
* draft-ietf-roll-p2p-measurement-04 = and 
* = draft-ietf-roll-p2p-rpl-09
 
Thanks to all of you for the fruitful and constructive = comments received during WG Last call, that = led 
to several tickets that = have been successfully closed, leading to new revisions of these = documents.
This starts a new 2-week = WG last call on:
* = draft-ietf-roll-p2p-measurement-05 = and 
* = draft-ietf-roll-p2p-rpl-12
 
The WG Last call will end on May 25th at noon = ET. Please send your comments on the mailing list and = copy the authors.
 
Thanks.
 
JP and Michael.  
 
 
Begin forwarded message:


 Subject: Re: [Roll] RPL-P2P - status & = update
 April = 13, 2012 11:21:00 PM GMT+02:00
To: JP = Vasseur <Cc: "roll@ietf.org WG" <roll@ietf.org>
 
Dear = JP,
Sounds quite = reasonable.
Have a pleasant weekend = you too - I will be spending mine recovering from week-long meetings in = the bay area...
On Apr 13, = 2012, at 14:16 , JP Vasseur wrote:


Hi = Thomas,
Clarifying a bit more =85 = what I meant =85
Plan = is:
* Close on the last open = ticket
* Authors will post a new = revision of the document, possibly highlighting the = changes
* Issue another WG LC to = make sure that the WG is comfortable with the new = revision
Thanks, have a good = week-end.
On Apr 13, 2012, at 9:03 = PM, JP Vasseur wrote:
Hi = Thomas,
Absolutely, the plan was = to run another incremental Last Call, on the new = revision.
On Apr 13, 2012, at 8:25 = PM, Thomas Heide Clausen wrote:


Hello = folks,

I've been trying to follow the many mails exchanged as a = consequence of the WGLC of RPL-P2P.

Given the volume of changes = to the document, I would like to ask that - once the authors estimate = that a version of the I-D folding in all proposed changes is ready - the = WG be given another 1-2 weeks WGLC before bouncing it off to the = ADs?

This just to ensure that the WG gets to give the final = version a good review before seeing it = off.

Thoughts?

Thomas

-- 
Thomas Heide = Clausen
discuss = it."
  -- Mitchell's Law of = Committees

_______________________________________________
Roll = mailing list
Roll@ietf.org
 
_______________________________________________
Roll = mailing list
Roll@ietf.org
To: JP Vasseur Thread-Topic: [Roll] reminder - end of second WG LC Thread-Index: Ac05zuEHbV1e6XKCTRmWzNqsyU+Prg== Date: Thu, 24 May 2012 17:02:10 +0000 Deferred-Delivery: Thu, 24 May 2012 17:02:00 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.80.126] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18924.006 x-tm-as-result: No--56.601100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD806B4B3xmbrcdx01ciscocom_" MIME-Version: 1.0 Cc: roll WG , Michael Richardson Subject: Re: [Roll] reminder - end of second WG LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 24 May 2012 17:02:17 -0000 --_000_E045AECD98228444A58C61C200AE1BD806B4B3xmbrcdx01ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sure; What I'm saying is that I reviewed this doc and I'm happy with it. No more comment from me, I'll be happy to see the draft go to IESG when LC = ends. Cheers, Pascal From: JP Vasseur [mailto:jpv@cisco.com] Sent: jeudi 24 mai 2012 15:28 To: Pascal Thubert (pthubert) Cc: roll WG; Michael Richardson Subject: Re: [Roll] reminder - end of second WG LC No, both documents are still under WG Last call. Thanks. JP. On May 24, 2012, at 1:55 PM, Pascal Thubert (pthubert) wrote: JP: I find that draft-ietf-roll-p2p-rpl-12 is ready for IESG review. Thanks a bunch to the authors and, in particular, to Mukul for all this har= d work. Cheers, Pascal From: roll-bounces@ietf.org [mailto:roll-boun= ces@ietf.org] On Behalf Of JP Vasseu= r Sent: mercredi 23 mai 2012 23:44 To: roll WG Cc: Michael Richardson Subject: [Roll] reminder - end of second WG LC Second last call on * draft-ietf-roll-p2p-measurement-05 and * draft-ietf-roll-p2p-rpl-12 will end May 25th at noon ET, just a reminder. Thanks. JP. On May 11, 2012, at 2:20 PM, JP Vasseur wrote: Dear all, A first WG Last Call took place on March 16th on: * draft-ietf-roll-p2p-measurement-04 and * draft-ietf-roll-p2p-rpl-09 Thanks to all of you for the fruitful and constructive comments received du= ring WG Last call, that led to several tickets that have been successfully closed, leading to new revis= ions of these documents. This starts a new 2-week WG last call on: * draft-ietf-roll-p2p-measurement-05 and * draft-ietf-roll-p2p-rpl-12 The WG Last call will end on May 25th at noon ET. Please send your comments= on the mailing list and copy the authors. Thanks. JP and Michael. Begin forwarded message: From: Thomas Heide Clausen > Subject: Re: [Roll] RPL-P2P - status & update Date: April 13, 2012 11:21:00 PM GMT+02:00 To: JP Vasseur > Cc: "roll@ietf.org WG" > Dear JP, Sounds quite reasonable. Have a pleasant weekend you too - I will be spending mine recovering from w= eek-long meetings in the bay area... Best, Thomas On Apr 13, 2012, at 14:16 , JP Vasseur wrote: Hi Thomas, Clarifying a bit more ... what I meant ... Plan is: * Close on the last open ticket * Authors will post a new revision of the document, possibly highlighting t= he changes * Issue another WG LC to make sure that the WG is comfortable with the new = revision Thanks, have a good week-end. JP. On Apr 13, 2012, at 9:03 PM, JP Vasseur wrote: Hi Thomas, Absolutely, the plan was to run another incremental Last Call, on the new r= evision. Cheers. JP. On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen wrote: Hello folks, I've been trying to follow the many mails exchanged as a consequence of the= WGLC of RPL-P2P. Given the volume of changes to the document, I would like to ask that - onc= e the authors estimate that a version of the I-D folding in all proposed ch= anges is ready - the WG be given another 1-2 weeks WGLC before bouncing it = off to the ADs? This just to ensure that the WG gets to give the final version a good revie= w before seeing it off. Thoughts? Thomas -- Thomas Heide Clausen http://www.thomasclausen.org/ "Any simple problem can be made insoluble if enough meetings are held to discuss it." -- Mitchell's Law of Committees _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_E045AECD98228444A58C61C200AE1BD806B4B3xmbrcdx01ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sure;

 <= /p>

What I’m saying is = that I reviewed this doc and I’m happy with it.

No more comment from me, = I’ll be happy to see the draft go to IESG when LC ends.

 <= /p>

Cheers,=

 <= /p>

Pascal<= /p>

 <= /p>

From: JP Vasse= ur [mailto:jpv@cisco.com]
Sent: jeudi 24 mai 2012 15:28
To: Pascal Thubert (pthubert)
Cc: roll WG; Michael Richardson
Subject: Re: [Roll] reminder - end of second WG LC=

 

No, both documents are still under WG Last call.

 

Thanks.

 

JP.

 

On May 24, 2012, at 1:55 PM, Pascal Thubert (pthuber= t) wrote:

 

JP:

 <= /p>

I find that draft-ietf-ro= ll-p2p-rpl-12 is ready for IESG review.

Thanks a bunch to the aut= hors and, in particular, to Mukul for all this hard work.=

 <= /p>

Cheers,=

 <= /p>

Pascal<= /p>

 <= /p>

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org]=  On Behalf Of JP Vasseur=
Sent: mercredi 23 = mai 2012 23:44
To: roll WG
Cc: Michael Richar= dson
Subject: [Roll] re= minder - end of second WG LC

 

Second last call on

 

* draft-ietf-roll-p2p-measurement-05 and <= /o:p>

* draft-ietf-roll-p2p-rpl-12

 

will end May 25th at noon ET, just a reminder.<= /o:p>

 

Thanks.

 

JP.

 

On May 11, 2012, at 2:20 PM, JP Vasseur wrote:<= /o:p>



Dear all,

 

A first WG Last Call took place on March 16th on:

* draft-ietf-roll-p2p-measurement-04 and <= /o:p>

* draft-ietf-roll-p2p-rpl-09

 

Thanks to all of you for the fruitful and constructi= ve comments received during WG Last call, that led 

to several tickets that have been successfully close= d, leading to new revisions of these documents.

 

This starts a new 2-week WG last call on:=

* draft-ietf-roll-p2p-measurement-05 and <= /o:p>

* draft-ietf-roll-p2p-rpl-12

 

The WG Last call will end on May 25th at noon ET.&nb= sp;Please send your comments on the mailing list and copy the aut= hors.

 

Thanks.

 

JP and Michael.  

 

 

Begin forwarded message:



From: Thomas Heide Clausen <ietf@thomasclausen.org>

Subject: Re: [Roll] RPL-P2P - stat= us & update

Date: April 13, 2012 11:21:00 PM = GMT+02:00

To: JP Vasseur <jpv@cisco.com>

 

Dear JP,

 

Sounds quite reasonable.

 

Have a pleasant weekend you too - I will be spending= mine recovering from week-long meetings in the bay area...

 

Best,

 

Thomas

 

On Apr 13, 2012, at 14:16 , JP Vasseur wrote:



Hi Thomas,

 

Clarifying a bit more … what I meant …

 

Plan is:

* Close on the last open ticket

* Authors will post a new revision of the document, = possibly highlighting the changes

* Issue another WG LC to make sure that the WG is co= mfortable with the new revision

 

Thanks, have a good week-end.

 

JP.

 

On Apr 13, 2012, at 9:03 PM, JP Vasseur wrote:<= /o:p>



Hi Thomas,

 

Absolutely, the plan was to run another incremental Last Call, on the new revision.

 

Cheers.

 

JP.

 

On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen wr= ote:



Hello folks,

I've been trying to follow the many mails exchanged as a consequence of the= WGLC of RPL-P2P.

Given the volume of changes to the document, I would like to ask that - onc= e the authors estimate that a version of the I-D folding in all proposed ch= anges is ready - the WG be given another 1-2 weeks WGLC before bouncing it = off to the ADs?

This just to ensure that the WG gets to give the final version a good revie= w before seeing it off.

Thoughts?

Thomas

-- 
Thomas Heide Clausen
http://www.thomasclausen.org/=

"Any simple problem can be made insoluble if enough meetings are held = to
discuss it."
  -- Mitchell's Law of Committees

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

 

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

 

 

 

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

 

 

--_000_E045AECD98228444A58C61C200AE1BD806B4B3xmbrcdx01ciscocom_-- From jreddy@ti.com Thu May 24 18:39:42 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1263221F8462 for ; Thu, 24 May 2012 18:39:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wOaGVSTK5jQJ for ; Thu, 24 May 2012 18:39:41 -0700 (PDT) Received: from devils.ext.ti.com (devils.ext.ti.com [198.47.26.153]) by ietfa.amsl.com (Postfix) with ESMTP id 55F5821F8460 for ; Thu, 24 May 2012 18:39:41 -0700 (PDT) Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by devils.ext.ti.com (8.13.7/8.13.7) with ESMTP id q4P1deRI006830 for ; Thu, 24 May 2012 20:39:40 -0500 Received: from DFLE71.ent.ti.com (dfle71.ent.ti.com [128.247.5.62]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id q4P1deep007539 for ; Thu, 24 May 2012 20:39:40 -0500 Received: from DLEE10.ent.ti.com ([fe80::843:a4aa:bf01:3f68]) by DFLE71.ent.ti.com ([fe80::29f6:72ad:a62e:2025%21]) with mapi id 14.01.0323.003; Thu, 24 May 2012 20:39:40 -0500 From: "Reddy, Joseph" To: "roll@ietf.org" Thread-Topic: reminder - end of second WG LC Thread-Index: Ac06FyOYTn3bpnu+QeaPj5v03WfWVA== Date: Fri, 25 May 2012 01:39:39 +0000 Message-ID: <2AA5AC69E924D149A8D63EB676AF87DB2CA33DBD@DLEE10.ent.ti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.247.5.50] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] reminder - end of second WG LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 May 2012 01:39:42 -0000 Hi Mukul, Here are some comments on the P2P-RPL draft -Regards, Joseph Section 5: "...By not allowing the generation of DRO messages, an Origin can use P2P-R= PL as purely a mechanism to deliver time-critical application data..." I question the value of this. The use of trickle timer necessarily adds a m= inimum delay on each hop. So, it would be faster to use the normal DODAG in= most cases even if that route takes more hops. And the normal route would = impose much less burden on the intermediate nodes.=20 Section 6.1: "...A P2P-DIO MAY carry one or more RIO and PIO options..." I am not sure how these options should be used by the DAG members. Later on= , in 9.1, it says that "..the temporary DAG must not be used to route packe= ts....". So what is the purpose of RIO and also PIO ? Default DoDAG config option values: DIOIntervalMin of 6 is too small for most networks. For default parameter, = suggest using 7. Also, default Lifetime values of infinity does not seem like a good idea fo= r a "temporary DAG" Section 9.2: Suggest that Imax setting should be less that the DAG lifetime value =20 Section 9.4 Bullet 1:=20 Under what conditions would a router receive the same DIO and a Data-Option= with higher sequence number? I assume that only the Originator can include= a Data-Option ? Same question also arises for section 9.5 ( para 1 ) Section 9.5: "...The Target must transmit the DRO message via the link-local multicast..= " Not sure why it would use link-local multicast...shouldn't it just transmit= along the reverse route collected in the P2P-RDO ? Section 9.6: "...This hop-by-hop lifetime must expire at the end of the lifetime specifi= ed by the default ..." The lifetime specified in the DODAG config option is intended to limit the = DAG lifetime which is used only for discovering the route. However, the act= ual route lifetime would be used for a much longer period of time. If it ex= pires so quickly, then it would seem that practical use of the p2p-rpl is l= imited to the source routing option. Section 11: It would seem that only the Originator of the temporary DAG can use the rou= tes created by it. The intermediate nodes are storing the routes but cannot= actually use them. Is my understanding right ? Section 12: ..In general, P2P-RPL operation does not affect core RPL operation.." I think this is unfortunate as P2P can be used to fix issues with core rpl.= For example, in core RPL, there is no way to repair a downward route until= the actual Target sends another DAO, which can take a long time. It would = be very nice if the DoDag root can use P2P-RPL to discover a route to a Tar= get node that is unreachable and then use the resulting source route as the= downward route. =20 From: roll-bounces@ietf.org [mailto:roll-boun= ces@ietf.org] On Behalf Of JP Vasseu= r Sent: mercredi 23 mai 2012 23:44 To: roll WG Cc: Michael Richardson Subject: [Roll] reminder - end of second WG LC Second last call on * draft-ietf-roll-p2p-measurement-05 and * draft-ietf-roll-p2p-rpl-12 will end May 25th at noon ET, just a reminder. Thanks. JP. On May 11, 2012, at 2:20 PM, JP Vasseur wrote: Dear all, A first WG Last Call took place on March 16th on: * draft-ietf-roll-p2p-measurement-04 and * draft-ietf-roll-p2p-rpl-09 Thanks to all of you for the fruitful and constructive comments received du= ring WG Last call, that led to several tickets that have been successfully = closed, leading to new revisions of these documents. This starts a new 2-week WG last call on: * draft-ietf-roll-p2p-measurement-05 and * draft-ietf-roll-p2p-rpl-12 The WG Last call will end on May 25th at noon ET. Please send your comments= on the mailing list and copy the authors. Thanks. JP and Michael. Begin forwarded message: From trac+roll@trac.tools.ietf.org Fri May 25 07:28:56 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9363C21F8603 for ; Fri, 25 May 2012 07:28:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3UR5aksweC3J for ; Fri, 25 May 2012 07:28:56 -0700 (PDT) Received: from gamay.tools.ietf.org (gamay.tools.ietf.org [208.66.40.242]) by ietfa.amsl.com (Postfix) with ESMTP id 16AB421F85E6 for ; Fri, 25 May 2012 07:28:55 -0700 (PDT) Received: from localhost ([::1] helo=gamay.tools.ietf.org) by gamay.tools.ietf.org with esmtp (Exim 4.77) (envelope-from ) id 1SXvVK-00087K-VD; Fri, 25 May 2012 10:28:35 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.12.2 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.2, by Edgewall Software To: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, mcr@sandelman.ca X-Trac-Project: roll Date: Fri, 25 May 2012 14:28:34 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/99 Message-ID: <058.aaa3fc2efaae8e26a2ada588bce49a89@trac.tools.ietf.org> X-Trac-Ticket-ID: 99 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, mcr@sandelman.ca, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on gamay.tools.ietf.org); SAEximRunCond expanded to false Resent-To: Resent-Message-Id: <20120525142856.16AB421F85E6@ietfa.amsl.com> Resent-Date: Fri, 25 May 2012 07:28:55 -0700 (PDT) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: [Roll] [roll] #99: clarify for readers how/where provisioning of devices occurs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 14:28:56 -0000 #99: clarify for readers how/where provisioning of devices occurs {{{ > Ralph> OK, do I understand the fundamental issue correctly: the > Ralph> assumption that there must be some form of installation > Ralph> process to adapt the device to the specific deployment? > > Yes, that's my understanding of what current manufacturers/system > integrators expect. Remember: there is layer-2 security stuff that also > would need to be initialized before the smart object could even get on > the network to see any kind of announcement. > > I believe that the layer-2 key initialization stuff will progress in the > future. 802.15.9 is chaired by Bob Moskovitz, and they are discussing > DTLS, IKEv2, HIP and a fourth one. > > As long as that is clarified in the document, I am fine with it. }}} -- -------------------------+------------------------------------------------- Reporter: mcr@… | Owner: draft-ietf-roll-minrank-hysteresis- Type: task | of@… Priority: major | Status: new Component: minrank- | Milestone: hysteresis-of | Version: Severity: In WG Last | Keywords: Call | -------------------------+------------------------------------------------- Ticket URL: roll From prvs=485d12915=mukul@uwm.edu Fri May 25 07:32:06 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5151C21F867B for ; Fri, 25 May 2012 07:32:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.392 X-Spam-Level: X-Spam-Status: No, score=-5.392 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YWkhKyuYu0Bz for ; Fri, 25 May 2012 07:32:05 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2A27121F8674 for ; Fri, 25 May 2012 07:32:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAIiXv09/AAAB/2dsb2JhbABFhTSyeQEBAQQBAQEgRAcLGw4DBAEBAwINFgMCKR8JCAYTiA0LqGGJQYkABIEkiV0UAQ+EEIESA4g/jFmPcIJ+gTgBHw Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 449561FD0D5; Fri, 25 May 2012 09:31:58 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta03.pantherlink.uwm.edu Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FM92oHVzucY6; Fri, 25 May 2012 09:31:56 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id D1D971FD0D0; Fri, 25 May 2012 09:31:56 -0500 (CDT) Date: Fri, 25 May 2012 09:31:56 -0500 (CDT) From: Mukul Goyal To: Joseph Reddy Message-ID: <992131173.513367.1337956316701.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CA33DBD@DLEE10.ent.ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] reminder - end of second WG LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 May 2012 14:32:06 -0000 Hi Joseph Thanks for your comments. Please see my response inline. [Joseph] Section 5: "...By not allowing the generation of DRO messages, an Origin can use P2P-RPL as purely a mechanism to deliver time-critical application data..." I question the value of this. The use of trickle timer necessarily adds a minimum delay on each hop. So, it would be faster to use the normal DODAG in most cases even if that route takes more hops. And the normal route would impose much less burden on the intermediate nodes. [Mukul] This feature is perceived useful in scenarios (e.g. in home automation) where there is no global DODAG to provide a default path between the source and the destination or such default path is known to be broken. We could have insisted that P2P-RPL is strictly a route discovery protocol and hence DROs must always be generated. But then we thought the facility to do trickle-controlled data delivery could be really useful in scenarios where the only other option is uncontrolled flooding. And it was so easy to provide this facility (simply use P2P-RPL with data option and with DROs turned off). As I mentioned, this facility was perceived as useful in home automation scenarios. Regarding whether such data delivery could be fast enough, I think one could always adjust the trickle parameters to meet the latency requirements. [Joseph] Section 6.1: "...A P2P-DIO MAY carry one or more RIO and PIO options..." I am not sure how these options should be used by the DAG members. Later on, in 9.1, it says that "..the temporary DAG must not be used to route packets....". So what is the purpose of RIO and also PIO ? [Mukul] The RIO would advertize to the target(s) the origin's connectivity to the specified prefix. Regarding PIO, I would very much like to allow P2P mode DIOs to carry PIOs to propagate prefixes for address selfconfiguration (i.e. have A flag set). I think we could forbid setting the R flag to one in a PIO carried in a P2P mode DIOs. Regarding the L flag, I think we could allow a P2P mode DIO to carry a PIO with L flag set subject to the following rules in RFC 6550: A RPL node acting as a router MUST NOT propagate a PIO with the 'L' flag set. A RPL node acting as a router MAY propagate a PIO with the 'L' flag not set. What do you think? [Joseph] Default DoDAG config option values: DIOIntervalMin of 6 is too small for most networks. For default parameter, suggest using 7. [Mukul] Changing 6 to 7 would double up the minimum latency for route discovery. DIOIntervalMin 6 corresponds to trickle Imin 64ms, which sounds reasonable/useful. As far as I can remember, this value worked just fine in the testing that Sigma Design and INRIA did with their P2P-RPL implementations. Could you share more details regarding why 7 would be better? I will also check with my co-authors in this regard. [Joseph] Also, default Lifetime values of infinity does not seem like a good idea for a "temporary DAG" [Mukul] Lifetime in the configuration option is for routing state and not for the "temporary DAG". Temporary DAG's lifetime is specified in P2P-RDO. [Joseph] Section 9.2: Suggest that Imax setting should be less that the DAG lifetime value [Mukul] I think Imax value is not critical because of the reasons given in Section 9.2: The Imax parameter SHOULD be set to a large value (several orders of magnitude higher than the Imin value) and is unlikely to be critical for P2P-RPL operation. This is because the first receipt of a P2P mode DIO for a particular temporary DAG is considered an inconsistent event and would lead to resetting of Trickle timer duration to the Imin value. Given the temporary nature of the DAGs used in P2P-RPL, Trickle timer may not get a chance to increase much. Default value 20 (from RFC6550) of DIOIntervalDoublings would make Imax much larger than maximum temporary DAG lifetime, which looks fine to me. Could you explain why Imax should be less than DAG lifetime? [Joseph] Section 9.4 Bullet 1: Under what conditions would a router receive the same DIO and a Data-Option with higher sequence number? I assume that only the Originator can include a Data-Option ? Same question also arises for section 9.5 ( para 1 ) [Mukul] Yes, only the origin can include a data option for delivery to the target(s). In theory, the origin might have newer data to convey to the target(s) while the route discovery is still going on. Sequence numbers accounts for that possibility. Note that Data option did not have a sequence number earlier (before the first LC). Then, Pascal raised the possibility what if origin changes the data option. How would intermediate routers and target know that this is the newer data? Hence, we introduced the sequence number. [Joseph] Section 9.5: "...The Target must transmit the DRO message via the link-local multicast.." Not sure why it would use link-local multicast...shouldn't it just transmit along the reverse route collected in the P2P-RDO ? [Mukul] DRO needs to be transmitted by link-local multicast to allow the spread of Stop flag (which says: dont send or process any more DIOs) to as many nodes as possible. Still, only the nodes on the discovered route are allowed to forward it any further. [Joseph] Section 9.6: "...This hop-by-hop lifetime must expire at the end of the lifetime specified by the default ..." The lifetime specified in the DODAG config option is intended to limit the DAG lifetime which is used only for discovering the route. However, the actual route lifetime would be used for a much longer period of time. If it expires so quickly, then it would seem that practical use of the p2p-rpl is limited to the source routing option. [Mukul] The correct text you are quoting is "This hop-by-hop routing state MUST expire at the end of the lifetime specified by the Default Lifetime and Lifetime Unit parameters inside the DODAG Configuration Option used in P2P mode DIOs for this route discovery. " As the text above says, the lifetime in configuration option is for routing state. The DAG's lifetime is specified in P2P Route Discovery Option (P2P-RDO). The DAG's lifetime would be a few seconds. The (hop-by-hop) routing state could potentially live forever. Does this clarify things? [Joseph] Section 11: It would seem that only the Originator of the temporary DAG can use the routes created by it. The intermediate nodes are storing the routes but cannot actually use them. Is my understanding right ? [Mukul] Yes. If using the RPL option (RFC 6553), only the origin can use the discovered route. The intermediate nodes can only use the routing state they store to forward the packets that bear the correct DODAGID (specified as the source IPv6 address of the packet) and the correct RPLInstanceID. [Joseph] Section 12: ..In general, P2P-RPL operation does not affect core RPL operation.." I think this is unfortunate as P2P can be used to fix issues with core rpl. For example, in core RPL, there is no way to repair a downward route until the actual Target sends another DAO, which can take a long time. It would be very nice if the DoDag root can use P2P-RPL to discover a route to a Target node that is unreachable and then use the resulting source route as the downward route. [Mukul] What the text you quoted means is that it does not break core RPL operation. P2P-RPL can certainly be used in the manner you specified. The root of a global DODAG can certainly use P2P-RPL to discover a source route to any target. Just that it will involve creation of a separate temporary DAG. If you want to do this route discovery within the scope of the existing global permanent DAG, it can be done but needs to be written up in a separate document. I dont think this provision should be inside P2P-RPL document. This is because, for RPL deployments that would not otherwise support P2P-RPL, it may be more efficient to simply use an RPL Target Option inside a DIO to trigger DAOs that would allow desired route to be discovered. Ofcourse, this needs to be written up to (since currently Target Option cannot sit inside a non-P2P mode DIO). Thanks Mukul From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: mercredi 23 mai 2012 23:44 To: roll WG Cc: Michael Richardson Subject: [Roll] reminder - end of second WG LC Second last call on * draft-ietf-roll-p2p-measurement-05 and * draft-ietf-roll-p2p-rpl-12 will end May 25th at noon ET, just a reminder. Thanks. JP. On May 11, 2012, at 2:20 PM, JP Vasseur wrote: Dear all, A first WG Last Call took place on March 16th on: * draft-ietf-roll-p2p-measurement-04 and * draft-ietf-roll-p2p-rpl-09 Thanks to all of you for the fruitful and constructive comments received during WG Last call, that led to several tickets that have been successfully closed, leading to new revisions of these documents. This starts a new 2-week WG last call on: * draft-ietf-roll-p2p-measurement-05 and * draft-ietf-roll-p2p-rpl-12 The WG Last call will end on May 25th at noon ET. Please send your comments on the mailing list and copy the authors. Thanks. JP and Michael. Begin forwarded message: _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From gnawali@cs.uh.edu Fri May 25 07:32:32 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88BBF21F8674 for ; Fri, 25 May 2012 07:32:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsP-jaFvKHrX for ; Fri, 25 May 2012 07:32:32 -0700 (PDT) Received: from dijkstra.cs.uh.edu (dijkstra.cs.uh.edu [129.7.240.12]) by ietfa.amsl.com (Postfix) with ESMTP id F2E4821F8673 for ; Fri, 25 May 2012 07:32:31 -0700 (PDT) Received: from localhost (dijkstra.cs.uh.edu [127.0.0.1]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 89D8523CAA5 for ; Fri, 25 May 2012 09:32:31 -0500 (CDT) X-Virus-Scanned: amavisd-new at cs.uh.edu Received: from dijkstra.cs.uh.edu ([127.0.0.1]) by localhost (dijkstra.cs.uh.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KzLOK4Toz8iX for ; Fri, 25 May 2012 09:32:28 -0500 (CDT) Received: from it.cs.uh.edu (it.cs.uh.edu [129.7.240.6]) by dijkstra.cs.uh.edu (Postfix) with ESMTP id 3BA8123CAA2 for ; Fri, 25 May 2012 09:32:28 -0500 (CDT) Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by it.cs.uh.edu (Postfix) with ESMTP id 533B52A280C0 for ; Fri, 25 May 2012 09:28:58 -0500 (CDT) Received: by wgbdr13 with SMTP id dr13so653207wgb.13 for ; Fri, 25 May 2012 07:32:26 -0700 (PDT) Received: by 10.180.100.2 with SMTP id eu2mr31858108wib.10.1337956345601; Fri, 25 May 2012 07:32:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.101.168 with HTTP; Fri, 25 May 2012 07:32:05 -0700 (PDT) In-Reply-To: <058.aaa3fc2efaae8e26a2ada588bce49a89@trac.tools.ietf.org> References: <058.aaa3fc2efaae8e26a2ada588bce49a89@trac.tools.ietf.org> From: Omprakash Gnawali Date: Fri, 25 May 2012 09:32:05 -0500 Message-ID: To: roll@ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, mcr@sandelman.ca Subject: Re: [Roll] [roll] #99: clarify for readers how/where provisioning of devices occurs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 14:32:32 -0000 I was wondering if the first paragraph of 6.1 is enough for things that need to be configured/provisioned for MRHOF. - om_p On Fri, May 25, 2012 at 9:28 AM, roll issue tracker wrote: > #99: clarify for readers how/where provisioning of devices occurs > > =A0{{{ > =A0> =A0 =A0 =A0Ralph> =A0OK, do I understand the fundamental issue corre= ctly: the > =A0> =A0 =A0 =A0Ralph> =A0assumption that there must be some form of inst= allation > =A0> =A0 =A0 =A0Ralph> =A0process to adapt the device to the specific dep= loyment? > =A0> > =A0> Yes, that's my understanding of what current manufacturers/system > =A0> integrators expect. =A0Remember: there is layer-2 security stuff tha= t also > =A0> would need to be initialized before the smart object could even get = on > =A0> the network to see any kind of announcement. > =A0> > =A0> I believe that the layer-2 key initialization stuff will progress in= the > =A0> future. =A0802.15.9 is chaired by Bob Moskovitz, and they are discus= sing > =A0> DTLS, IKEv2, HIP and a fourth one. > =A0> > =A0> > > =A0As long as that is clarified in the document, I am fine with it. > =A0}}} > > -- > -------------------------+-----------------------------------------------= -- > =A0Reporter: =A0mcr@=85 =A0 =A0 =A0 =A0| =A0 =A0 =A0Owner: =A0draft-ietf-= roll-minrank-hysteresis- > =A0 =A0 Type: =A0task =A0 =A0 =A0 =A0 | =A0of@=85 > =A0Priority: =A0major =A0 =A0 =A0 =A0| =A0 =A0 Status: =A0new > Component: =A0minrank- =A0 =A0 | =A0Milestone: > =A0hysteresis-of =A0 =A0 =A0 =A0 =A0| =A0 =A0Version: > =A0Severity: =A0In WG Last =A0 | =A0 Keywords: > =A0Call =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | > -------------------------+-----------------------------------------------= -- > > Ticket URL: > roll > From mcr@sandelman.ca Fri May 25 07:33:48 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29FC721F8617 for ; Fri, 25 May 2012 07:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.954 X-Spam-Level: X-Spam-Status: No, score=-1.954 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KgwEWJyrs+vy for ; Fri, 25 May 2012 07:33:47 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9504421F8674 for ; Fri, 25 May 2012 07:33:46 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 23C1586C4; Fri, 25 May 2012 10:32:06 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 42E839823C; Fri, 25 May 2012 10:33:45 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 3EC8198239; Fri, 25 May 2012 10:33:45 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <4FBE8CCB.2050504@innovationslab.net> References: <25665.1337180676@marajade.sandelman.ca> <4FB3C7CB.70709@innovationslab.net> <4FBA58CC.9040109@innovationslab.net> <19650.1337713406@marajade.sandelman.ca> <593C2D52-E780-4D75-B535-7F2B147642A0@gmail.com> <23542.1337782756@marajade.sandelman.ca> <32356.1337806435@marajade.sandelman.ca> <4FBE8CCB.2050504@innovationslab.net> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) Date: Fri, 25 May 2012 10:33:45 -0400 Message-ID: <8700.1337956425@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Brian Haberman , draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, roll-chairs@tools.ietf.org Subject: [Roll] how to document provisioning model properly X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 May 2012 14:33:48 -0000 (Guys, I pull ietf@ietf.org out, and added the WG) http://trac.tools.ietf.org/wg/roll/trac/ticket/99 I want to note that Ralph and Brian's request is not really specific to MRHOF. JP, how/where can we deal with this? I know that Carstan was writing a 6lowpan/LLN/RPL/ND roadmap document that explained how and where to use all these things together. However, while I hate to sound like a broken record, I think that these things are in fact target application specific, and therefore need to be addressed in the applicability statments. My proposal is that we have to build a table of contents for the applicability statements, and that we need to hold a WG LC on the result. See my other email to the list: http://www.ietf.org/mail-archive/web/roll/current/msg06982.html I really do need some feedback here. -- ] He who is tired of Weird Al is tired of life! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ Kyoto Plus: watch the video then sign the petition. From mcr@sandelman.ca Fri May 25 07:35:50 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A666821F86B8 for ; Fri, 25 May 2012 07:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.871 X-Spam-Level: X-Spam-Status: No, score=-1.871 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4n730N-4M2Yi for ; Fri, 25 May 2012 07:35:48 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD8D21F86B6 for ; Fri, 25 May 2012 07:35:48 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 7183A86C4; Fri, 25 May 2012 10:34:06 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id BA4759823C; Fri, 25 May 2012 10:35:28 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B65FD98239; Fri, 25 May 2012 10:35:28 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <4FBE8CCB.2050504@innovationslab.net> References: <25665.1337180676@marajade.sandelman.ca> <4FB3C7CB.70709@innovationslab.net> <4FBA58CC.9040109@innovationslab.net> <19650.1337713406@marajade.sandelman.ca> <593C2D52-E780-4D75-B535-7F2B147642A0@gmail.com> <23542.1337782756@marajade.sandelman.ca> <32356.1337806435@marajade.sandelman.ca> <4FBE8CCB.2050504@innovationslab.net> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 25 May 2012 10:35:28 -0400 Message-ID: <9063.1337956528@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Brian Haberman , draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org, roll-chairs@tools.ietf.org Subject: [Roll] how to document provisioning model properly X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 May 2012 14:35:50 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable (resend with correct From) (Guys, I pull ietf@ietf.org out, and added the WG) http://trac.tools.ietf.org/wg/roll/trac/ticket/99 I want to note that Ralph and Brian's request is not really specific to=20 MRHOF. JP, how/where can we deal with this? I know that Carstan was writing a 6lowpan/LLN/RPL/ND roadmap document that explained how and where to use all these things together.=20=20 However, while I hate to sound like a broken record, I think that these things are in fact target application specific, and therefore need to be addressed in the applicability statments. My proposal is that we have to build a table of contents for the applicability statements, and that we need to hold a WG LC on the result. See my other email to the list: http://www.ietf.org/mail-archive/web/roll/current/msg06982.html I really do need some feedback here. =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) iQCVAwUAT7+YsIqHRg3pndX9AQISXwP9Fi1T91K2Omb5/wpr5WWoDxz5ru1aFuId JnTxcyDiYUJi7K9dXKvc3fKF8qZoIT1CmbViR4MHcj038VuSB1rLiVezp3hebLJ5 YFkJpGgSo4w9vwekxtR7Vzf7U1Mmqf5nPUAop7yaYCUW+zD+w0ypyNjGwWb3M8ys z1o8jJal9QQ= =5Dfp -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri May 25 07:54:10 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3506221F86CF for ; Fri, 25 May 2012 07:54:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.883 X-Spam-Level: X-Spam-Status: No, score=-1.883 tagged_above=-999 required=5 tests=[AWL=0.071, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bmjp7hYtnku8 for ; Fri, 25 May 2012 07:54:09 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECA021F86C5 for ; Fri, 25 May 2012 07:54:09 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 3225386C4 for ; Fri, 25 May 2012 10:52:26 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id CB9939823C; Fri, 25 May 2012 10:53:51 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id C807B98239 for ; Fri, 25 May 2012 10:53:51 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 25 May 2012 10:53:51 -0400 Message-ID: <12418.1337957631@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] knowing which multiple metrics matter: MRHOF related questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 14:54:10 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Ralph asked some questions a few days ago. His originally DISCUSS is at: http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of/b= allot/ This was my reply. I am particularly interested in replies from Pascal, Anders and Mukul about my assertion about how we would never=20 pick RPL instances by metrics; that they would in fact be seperate RPL Instance numbers and DODAG values, and that these things would provisioned by the network installer. =3D=3D=3D=3D I'm going to reply to your comments in a different order than you asked them, because I think question #3 is most important, and the rest fall out of it. >>>>> "Ralph" =3D=3D Ralph Droms writes: Ralph> 3. Based on (1) and (2), would configuration and selection Ralph> issues be ameliorated if the five candidate selected metrics Ralph> were each asssigned a separate objective function? Use of a Ralph> separate OF code point for each of the five possible selected Ralph> metrics would allow multiple RPL instances. I think that it's important to understand that ROLL has a whole palette of things that need to be provisioned by the "network operator". In contrast to the situation of ISPs and customers, where the ISP is the network operator, ROLL networks are more like highly orchestrated Enterprises: "all your host belong to us" so, when we write something like: "The metric chosen by the network operator to use for path selection." in section 2, we really mean: "The metric chosen by the network operator and provisioned into the node when the firmware was flashed to use for path selection." Ralph> 1. Why is one objective function defined for several potential Ralph> metrics? The details of MRHOF seem to preclude the establishment Ralph> of several RPL instances in an LLN, each of which uses MRHOF with Ralph> a different selected metric. If one had many different RPL Instances, then we would have different RPL Instance numbers in the RPL header. There can be many different DODAG ("destinations") created within that instance. The instances share a common set of (provisioned) parameters. (To put it into DHCP terms: if we have multiple DHCP servers on a link, then one would expect them to all offer IP addresses in the same subnet. If one wanted to have addresses in different subnets, and let the host pick between them, then, one would need different layer-2s: different VLANs or ESSIDs, or... ) If you feel that RPL is rather schizo about provisioning vs configuration, then I agree. It's not always clear to me why some things are advertised while others are provisioned. In BGPv4, we calculate metrics by adding AS entries in the path. (It's always additive), and we add at least one AS entry to the path. One can AS-stuff and add more, but proper operation of BGP does not depend upon the exact algorithm used. Finally, my impression is that how the various metrics are used (singly, or in some combination) to calculate Rank Increase is a question of further research, experimentation, and trade secret.=20=20 So long as the Rank increases, and a node does not flap between parents, the exact details do not matter. Each node can do it's parent selection based upon the available metrics on it's own. It advertises the metrics it has. I hope the authors will correct me if I'm completely off here. --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT7+c/4qHRg3pndX9AQLlAQP/cnxcJOCjm1JhmAA2sHbf7kM2urJ/SxmS knhxQ2iO6fuD7MkPAt41yR8fCMTjT0YiZhtfkjV5ujH65toj8d9jrIPTNnE3h71p 59G3kRSDFKfqRiZGs3okoTZxXgY/1lKBXCDLDfGdlajdEZqBWKu+Ekyu7PzUuYVN XKt+rfQKEiU= =ejWy -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri May 25 08:17:34 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D77E521F86FF for ; Fri, 25 May 2012 08:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03bmGFhAdUTz for ; Fri, 25 May 2012 08:17:34 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 1278921F86EC for ; Fri, 25 May 2012 08:17:33 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 8F99A86C4 for ; Fri, 25 May 2012 11:15:52 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 161B09823C; Fri, 25 May 2012 11:17:32 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 150F598239 for ; Fri, 25 May 2012 11:17:32 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: References: <25665.1337180676@marajade.sandelman.ca> <4FB3C7CB.70709@innovationslab.net> <4FBA58CC.9040109@innovationslab.net> <19650.1337713406@marajade.sandelman.ca> <593C2D52-E780-4D75-B535-7F2B147642A0@gmail.com> <23542.1337782756@marajade.sandelman.ca> <32356.1337806435@marajade.sandelman.ca> <4FBE8CCB.2050504@innovationslab.net> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 25 May 2012 11:17:32 -0400 Message-ID: <17114.1337959052@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] Brian Haberman Discuss on on draft-ietf-roll-minrank-hysteresis-of-10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 15:17:35 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ralph" =3D=3D Ralph Droms writes: Ralph> OK, do I understand the fundamental issue correctly: the Ralph> assumption that there must be some form of installation Ralph> process to adapt the device to the specific deployment? WG: please disagree with this assumption of mine: >>> Yes, that's my understanding of what current >>> manufacturers/system integrators expect. Remember: there is >>> layer-2 security stuff that also would need to be initialized >>> before the smart object could even get on=20 >>> the network to see any kind of announcement. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT7+ii4qHRg3pndX9AQIpegP/dbTjY7t5QNyGydbl1d8MhlLPwgD6wULi U6kpx1hJHth1h4mJMUBDOSJK8xmq/18rojqvA/smK7Ej3Pn6ggF6I45VvCiwaGIW BMvT1Xc4MbKfyohQm+HBlwMPL+FnqtfWOfoTYebN3ICLpSql8TXx4gn5rhJPhCnw nK/q9y8+B2g= =w73u -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Fri May 25 08:30:52 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E8DA21F85C6 for ; Fri, 25 May 2012 08:30:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YcUafo0vF0Pg for ; Fri, 25 May 2012 08:30:52 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id F151021F85AC for ; Fri, 25 May 2012 08:30:51 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 7E2EB86C4; Fri, 25 May 2012 11:29:11 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 160889823C; Fri, 25 May 2012 11:30:51 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0C39C98239; Fri, 25 May 2012 11:30:51 -0400 (EDT) From: Michael Richardson To: Omprakash Gnawali In-Reply-To: References: <058.aaa3fc2efaae8e26a2ada588bce49a89@trac.tools.ietf.org> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 25 May 2012 11:30:50 -0400 Message-ID: <19632.1337959850@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org, draft-ietf-roll-minrank-hysteresis-of@tools.ietf.org Subject: Re: [Roll] [roll] #99: clarify for readers how/where provisioning of devices occurs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 15:30:52 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Omprakash" =3D=3D Omprakash Gnawali writes: Omprakash> I was wondering if the first paragraph of 6.1 is enough for = things Omprakash> that need to be configured/provisioned for MRHOF. I think that it works for *MRHOF*, but I think that we have a bigger picture problem here. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT7+lqoqHRg3pndX9AQIWJQP/Q7KeZuvyJTKUcEx9vMvuvFoM4Om2aupN EJtoW5qYs3EC7H/mb283dFvj/VM7c7lThlEgp2mbiHp8TNAeob64+aH4OtgKuQCi bPWCS66Oz5o28VG/HHcPl/oDSOOx5wTQ1FAaw0YpjN+KjIvODrrU8G7MhwFZYXCS bkHoH/AUcvg= =UdUQ -----END PGP SIGNATURE----- --=-=-=-- From jpv@cisco.com Fri May 25 09:08:17 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E504021F8745 for ; Fri, 25 May 2012 09:08:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.239 X-Spam-Level: X-Spam-Status: No, score=-110.239 tagged_above=-999 required=5 tests=[AWL=0.359, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJkZ+k0-an91 for ; Fri, 25 May 2012 09:08:15 -0700 (PDT) Received: from bgl-iport-1.cisco.com (bgl-iport-1.cisco.com [72.163.197.25]) by ietfa.amsl.com (Postfix) with ESMTP id 89F3221F8746 for ; Fri, 25 May 2012 09:08:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=12696; q=dns/txt; s=iport; t=1337962094; x=1339171694; h=subject:mime-version:from:in-reply-to:date:cc:message-id: references:to; bh=+TjmMoY3MAot76JqxKprViRz+lSgOxrOZkfXw+T/ueY=; b=NkYsC0PbvfgxHPD1CKqNH8hIffa75AVmEpoWD17QSs3EzkG4Xi9J7zWW NX1Q96YA/A7TPzOOCyrklBo2JYZbZtok6OnQML/HOkG3M1N130qiw1y4s SgZ7Om54PLv38i7lMvp5yyJd1NEvT4h8TNVX6n4/l+TiBib/WT/RHvwKp 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnYFANatv09Io8UY/2dsb2JhbABEDoMPr1uDIYIVAQEBAwEBAQEPAVsLBQscAwECAS4nKAgGARIJGYdmBQubRJ9TiwEkhEJgA5UYhU+IPYFkgic7 X-IronPort-AV: E=Sophos;i="4.75,657,1330905600"; d="scan'208,217";a="13029244" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-1.cisco.com with ESMTP; 25 May 2012 16:08:12 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4PG8Can031461; Fri, 25 May 2012 16:08:12 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); Sat, 26 May 2012 00:08:12 +0800 Received: from [10.60.114.229] ([10.60.114.229]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 May 2012 00:08:09 +0800 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/alternative; boundary="Apple-Mail=_3CD2A0E9-3573-427A-AF64-3D7EE0B88980" From: JP Vasseur In-Reply-To: <258174AC-25D5-447B-B9A1-11DE371CACD3@cisco.com> Date: Fri, 25 May 2012 18:08:07 +0200 Message-Id: <56A5FC1D-5D5E-456C-A314-4C43BFF89BE2@cisco.com> References: <9850315F-B3E6-4A29-AAD5-B53E6C978F69@thomasclausen.org> <66E2061B-4866-4276-B69A-6FD150D6EB93@cisco.com> <258174AC-25D5-447B-B9A1-11DE371CACD3@cisco.com> To: roll WG , Mukul Goyal , Emmanuel Baccelli X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 25 May 2012 16:08:09.0546 (UTC) FILETIME=[93F28AA0:01CD3A90] Cc: Michael Richardson Subject: [Roll] End of second WG LC on RPL P2P X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 May 2012 16:08:17 -0000 --Apple-Mail=_3CD2A0E9-3573-427A-AF64-3D7EE0B88980 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Dear all, The second 2-week WG LC on: draft-ietf-roll-p2p-measurement-05 draft-ietf-roll-p2p-rpl-12 has now ended. I saw comments from Joseph Reddy - Authors, could you please address = them and then I'll send the publication request. Thanks. JP and Michael. On May 23, 2012, at 11:44 PM, JP Vasseur wrote: > Second last call on >=20 >> * draft-ietf-roll-p2p-measurement-05 and=20 >> * draft-ietf-roll-p2p-rpl-12 >=20 >=20 > will end May 25th at noon ET, just a reminder. >=20 > Thanks. >=20 > JP. >=20 > On May 11, 2012, at 2:20 PM, JP Vasseur wrote: >=20 >> Dear all, >>=20 >> A first WG Last Call took place on March 16th on: >> * draft-ietf-roll-p2p-measurement-04 and=20 >> * draft-ietf-roll-p2p-rpl-09 >>=20 >> Thanks to all of you for the fruitful and constructive comments = received during WG Last call, that led=20 >> to several tickets that have been successfully closed, leading to new = revisions of these documents. >>=20 >> This starts a new 2-week WG last call on: >> * draft-ietf-roll-p2p-measurement-05 and=20 >> * draft-ietf-roll-p2p-rpl-12 >>=20 >> The WG Last call will end on May 25th at noon ET. Please send your = comments on the mailing list and copy the authors. >>=20 >> Thanks. >>=20 >> JP and Michael. =20 >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: Thomas Heide Clausen >>> Subject: Re: [Roll] RPL-P2P - status & update >>> Date: April 13, 2012 11:21:00 PM GMT+02:00 >>> To: JP Vasseur >>> Cc: "roll@ietf.org WG" >>>=20 >>> Dear JP, >>>=20 >>> Sounds quite reasonable. >>>=20 >>> Have a pleasant weekend you too - I will be spending mine recovering = from week-long meetings in the bay area... >>>=20 >>> Best, >>>=20 >>> Thomas >>>=20 >>> On Apr 13, 2012, at 14:16 , JP Vasseur wrote: >>>=20 >>>> Hi Thomas, >>>>=20 >>>> Clarifying a bit more =85 what I meant =85 >>>>=20 >>>> Plan is: >>>> * Close on the last open ticket >>>> * Authors will post a new revision of the document, possibly = highlighting the changes >>>> * Issue another WG LC to make sure that the WG is comfortable with = the new revision >>>>=20 >>>> Thanks, have a good week-end. >>>>=20 >>>> JP. >>>>=20 >>>> On Apr 13, 2012, at 9:03 PM, JP Vasseur wrote: >>>>=20 >>>>> Hi Thomas, >>>>>=20 >>>>> Absolutely, the plan was to run another incremental Last Call, on = the new revision. >>>>>=20 >>>>> Cheers. >>>>>=20 >>>>> JP. >>>>>=20 >>>>> On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen wrote: >>>>>=20 >>>>>> Hello folks, >>>>>>=20 >>>>>> I've been trying to follow the many mails exchanged as a = consequence of the WGLC of RPL-P2P. >>>>>>=20 >>>>>> Given the volume of changes to the document, I would like to ask = that - once the authors estimate that a version of the I-D folding in = all proposed changes is ready - the WG be given another 1-2 weeks WGLC = before bouncing it off to the ADs? >>>>>>=20 >>>>>> This just to ensure that the WG gets to give the final version a = good review before seeing it off. >>>>>>=20 >>>>>> Thoughts? >>>>>>=20 >>>>>> Thomas >>>>>>=20 >>>>>> --=20 >>>>>> Thomas Heide Clausen >>>>>> http://www.thomasclausen.org/ >>>>>>=20 >>>>>> "Any simple problem can be made insoluble if enough meetings are = held to >>>>>> discuss it." >>>>>> -- Mitchell's Law of Committees >>>>>>=20 >>>>>> _______________________________________________ >>>>>> Roll mailing list >>>>>> Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>=20 >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>>=20 >>>=20 >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail=_3CD2A0E9-3573-427A-AF64-3D7EE0B88980 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Dear = all,

The second 2-week WG LC on:
= draft-ietf-roll-p2p-measurement-05
= draft-ietf-roll-p2p-rpl-12

has now = ended.

I saw comments from Joseph Reddy - = Authors, could you please address them and then I'll send the = publication = request.

Thanks.

JP = and Michael.

On May 23, 2012, at 11:44 PM, JP = Vasseur wrote:

Second last call = on

* draft-ietf-roll-p2p-measurement-05 = and 
* = draft-ietf-roll-p2p-rpl-12
Dear = all,

A first WG Last Call took place on March 16th = on:
* draft-ietf-roll-p2p-measurement-04 and 
* = draft-ietf-roll-p2p-rpl-09

Thanks to all of you = for the fruitful and constructive comments received during WG Last call, = that led 
to several tickets that have been successfully = closed, leading to new revisions of these = documents.

This starts a new 2-week WG last = call on:
* draft-ietf-roll-p2p-measurement-05 = and 
* = draft-ietf-roll-p2p-rpl-12

The WG Last = call will end on May 25th at noon ET. Please send your = comments on the mailing list and copy the = authors.

Thanks.

JP = and Michael. =  


Begin = forwarded message:

From: Thomas Heide = Clausen <ietf@thomasclausen.org>
<= /span>
Subject: Re: [Roll] RPL-P2P - status & = update
Date: April 13, 2012 11:21:00 PM = GMT+02:00
To: JP Vasseur <jpv@cisco.com>

Dear = JP,

Sounds quite = reasonable.

Have a pleasant weekend you too - I = will be spending mine recovering from week-long meetings in the bay = area...

Best,

Thomas

On Apr 13, 2012, at 14:16 , JP Vasseur = wrote:

Hi = Thomas,

Clarifying a bit more =85 what I meant = =85

Plan is:
* Close on the last open = ticket
* Authors will post a new revision of the document, = possibly highlighting the changes
* Issue another WG LC to = make sure that the WG is comfortable with the new = revision

Thanks, have a good = week-end.

JP.

On Apr = 13, 2012, at 9:03 PM, JP Vasseur wrote:

Hi = Thomas,

Absolutely, the plan was to run another = incremental Last Call, on the new = revision.

Cheers.

JP.

On Apr 13, 2012, at 8:25 PM, Thomas Heide Clausen = wrote:

Hello folks,

I've been trying to follow the = many mails exchanged as a consequence of the WGLC of = RPL-P2P.

Given the volume of changes to the document, I would = like to ask that - once the authors estimate that a version of the I-D = folding in all proposed changes is ready - the WG be given another 1-2 = weeks WGLC before bouncing it off to the ADs?

This just to ensure = that the WG gets to give the final version a good review before seeing = it off.

Thoughts?

Thomas

--
Thomas Heide = Clausen
http://www.thomasclausen.org/
"Any simple problem can be made insoluble if enough meetings are = held to
discuss it."
  -- Mitchell's Law of = Committees

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

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



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

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

= --Apple-Mail=_3CD2A0E9-3573-427A-AF64-3D7EE0B88980-- From pthubert@cisco.com Fri May 25 09:31:18 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C304521F873A for ; Fri, 25 May 2012 09:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KfZnLF5NVun for ; Fri, 25 May 2012 09:31:18 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id D4A2021F8723 for ; Fri, 25 May 2012 09:31:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=4319; q=dns/txt; s=iport; t=1337963478; x=1339173078; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=UHZWlkmIdeW2RIrqR/kdFEjcX2i3yQk8Hd+vCb6iaJc=; b=etshHkAZi1X/1U9N1VXT5IpvxVCaVFaKAB+v+Eo4mpGG25ynifQ3GyVm FBTDI/hw5GYSNxjXH7FvEBnzUBjw/Vo5tuBGxKTs1t4HMhk8W09ShUr1s AJL/DEqOghzRRiqjkN6gyG324kCyGfEvflNb0jaYjY4YtTUkgvW2YvfV1 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAC6zv0+tJXHA/2dsb2JhbABEtRaBB4IVAQEBBBIBJ0sEAgEIEQQBAQsUCQchERQJCAIEARIIGoddAwsLm0yVeg2JToofYoRmYAORPYRqiWiDFYFkgmA X-IronPort-AV: E=Sophos;i="4.75,657,1330905600"; d="scan'208";a="86506369" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 25 May 2012 16:31:17 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id q4PGVHkC018526 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 25 May 2012 16:31:17 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.238]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0298.004; Fri, 25 May 2012 11:31:17 -0500 From: "Pascal Thubert (pthubert)" To: Michael Richardson , "roll@ietf.org" Thread-Topic: [Roll] knowing which multiple metrics matter: MRHOF related questions Thread-Index: AQHNOoZBXefq0YiVp0SFfBMSzRPcLZbasPuA Date: Fri, 25 May 2012 16:31:16 +0000 Deferred-Delivery: Fri, 25 May 2012 16:31:00 +0000 Message-ID: References: <12418.1337957631@marajade.sandelman.ca> In-Reply-To: <12418.1337957631@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.95.86] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18926.005 x-tm-as-result: No--26.763200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 16:31:18 -0000 Hi Michael: I think RPL does not want to take party there. The OF is a piece of logic t= o tie metrics and policies together.=20 As such, there could be multiple metrics as long as there is good logic to = tie them in. for instance one would look at optimizing metric A within cont= raints as expressed by metric B and the OF model will allow that. OTOH, it a flows requires a certain optimization (say per one metric) and a= nother requires something different, then certainly you want two instances. So ... it depends! Pascal -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mic= hael Richardson Sent: vendredi 25 mai 2012 16:54 To: roll@ietf.org Subject: [Roll] knowing which multiple metrics matter: MRHOF related questi= ons Ralph asked some questions a few days ago. His originally DISCUSS is at: http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of/b= allot/ This was my reply. I am particularly interested in replies from Pascal, Anders and Mukul about my assertion about how we would never pick R= PL instances by metrics; that they would in fact be seperate RPL Instance n= umbers and DODAG values, and that these things would provisioned by the net= work installer. =3D=3D=3D=3D I'm going to reply to your comments in a different order than you asked the= m, because I think question #3 is most important, and the rest fall out of = it. >>>>> "Ralph" =3D=3D Ralph Droms writes: Ralph> 3. Based on (1) and (2), would configuration and selection Ralph> issues be ameliorated if the five candidate selected metrics Ralph> were each asssigned a separate objective function? Use of a Ralph> separate OF code point for each of the five possible selected Ralph> metrics would allow multiple RPL instances. I think that it's important to understand that ROLL has a whole palette of = things that need to be provisioned by the "network operator". In contrast to the situation of ISPs and customers, where the ISP is the ne= twork operator, ROLL networks are more like highly orchestrated Enterprises: "all your host belong to us" so, when we write something like: "The metric chosen by the network operator to use for path selection." in section 2, we really mean: "The metric chosen by the network operator and provisioned into the node when the firmware was flashed to use for path selection." Ralph> 1. Why is one objective function defined for several potential=20 Ralph> metrics? The details of MRHOF seem to preclude the establishment=20 Ralph> of several RPL instances in an LLN, each of which uses MRHOF with=20 Ralph> a different selected metric. If one had many different RPL Instances, then we would have different RPL Instance numbers in the RPL header. There can be many different DODAG ("destinations") created within that instance. The instances share a= common set of (provisioned) parameters. (To put it into DHCP terms: if we have multiple DHCP servers on a link, th= en one would expect them to all offer IP addresses in the same subnet. If one wanted to have addresses in different subnets, and let the host pi= ck between them, then, one would need different layer-2s: different VLANs = or ESSIDs, or... ) If you feel that RPL is rather schizo about provisioning vs configuration, = then I agree. It's not always clear to me why some things are advertised w= hile others are provisioned. In BGPv4, we calculate metrics by adding AS entries in the path. (It's always additive), and we add at least one AS entry to the path. One can AS-stuff and add more, but proper operation of BGP does not depend = upon the exact algorithm used. Finally, my impression is that how the various metrics are used (singly, or= in some combination) to calculate Rank Increase is a question of further r= esearch, experimentation, and trade secret. =20 So long as the Rank increases, and a node does not flap between parents, th= e exact details do not matter. Each node can do it's parent selection base= d upon the available metrics on it's own. It advertises the metrics it has= . I hope the authors will correct me if I'm completely off here. From jpv@cisco.com Fri May 25 09:43:55 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54C7E21F8758 for ; Fri, 25 May 2012 09:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.329 X-Spam-Level: X-Spam-Status: No, score=-110.329 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HqnmaEvVNAG for ; Fri, 25 May 2012 09:43:54 -0700 (PDT) Received: from bgl-iport-2.cisco.com (bgl-iport-2.cisco.com [72.163.197.26]) by ietfa.amsl.com (Postfix) with ESMTP id D4EED21F8755 for ; Fri, 25 May 2012 09:43:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jpv@cisco.com; l=4848; q=dns/txt; s=iport; t=1337964227; x=1339173827; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=LoxIOM3R9oRxfUrJVz3M5j2N+gnRLTJSjOn+oCL5Y/s=; b=Q/oggYneSeAdfJk5P3Lmm+uf1eEHC7hsBici0eMZP7JUjCQbQkPdRBk2 enKy3rxReWI3v7Q1sUlNTifPAL39Frw4Kd2kObNpjHHIgDQ9LnimSlgI3 QPBGf5pBKXsApPnfG+fQFR2y6wCGkBGvQJgcYNKkV51H+0cTqyLvxsv4Z c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFANW1v09Io8UY/2dsb2JhbABEgx2zAIIVAQEBAwEBAQEPASc0CwUHBAsRBAEBKAchBh8JCAYTIoddAwYFC5tQlXkNiU6KH2KEZmADkT2DW4EPhECFKIMVgWSCYg X-IronPort-AV: E=Sophos;i="4.75,657,1330905600"; d="scan'208";a="13032143" Received: from vla196-nat.cisco.com (HELO bgl-core-2.cisco.com) ([72.163.197.24]) by bgl-iport-2.cisco.com with ESMTP; 25 May 2012 16:43:45 +0000 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by bgl-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id q4PGhiV4005968; Fri, 25 May 2012 16:43:45 GMT Received: from xfe-hkg-412.apac.cisco.com ([64.104.123.71]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 May 2012 00:43:44 +0800 Received: from [10.60.114.229] ([10.60.114.229]) by xfe-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 26 May 2012 00:43:42 +0800 Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: text/plain; charset=us-ascii From: JP Vasseur In-Reply-To: Date: Fri, 25 May 2012 18:43:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <722786C3-64AE-482B-AD69-CE80AD2AD32A@cisco.com> References: <12418.1337957631@marajade.sandelman.ca> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1278) X-OriginalArrivalTime: 25 May 2012 16:43:42.0325 (UTC) FILETIME=[8B2ECA50:01CD3A95] Cc: "roll@ietf.org" Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 16:43:55 -0000 I would agree, the OF solves the tough tension between flexibility and = under-specifcation. On May 25, 2012, at 6:31 PM, Pascal Thubert (pthubert) wrote: > Hi Michael: >=20 > I think RPL does not want to take party there. The OF is a piece of = logic to tie metrics and policies together.=20 > As such, there could be multiple metrics as long as there is good = logic to tie them in. for instance one would look at optimizing metric A = within contraints as expressed by metric B and the OF model will allow = that. >=20 > OTOH, it a flows requires a certain optimization (say per one metric) = and another requires something different, then certainly you want two = instances. >=20 > So ... it depends! >=20 > Pascal >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of Michael Richardson > Sent: vendredi 25 mai 2012 16:54 > To: roll@ietf.org > Subject: [Roll] knowing which multiple metrics matter: MRHOF related = questions >=20 >=20 > Ralph asked some questions a few days ago. > His originally DISCUSS is at: > = http://datatracker.ietf.org/doc/draft-ietf-roll-minrank-hysteresis-of/ball= ot/ >=20 > This was my reply. I am particularly interested in replies from > Pascal, Anders and Mukul about my assertion about how we would never = pick RPL instances by metrics; that they would in fact be seperate RPL = Instance numbers and DODAG values, and that these things would = provisioned by the network installer. >=20 > =3D=3D=3D=3D >=20 > I'm going to reply to your comments in a different order than you = asked them, because I think question #3 is most important, and the rest = fall out of it. >=20 >>>>>> "Ralph" =3D=3D Ralph Droms writes: > Ralph> 3. Based on (1) and (2), would configuration and selection > Ralph> issues be ameliorated if the five candidate selected metrics > Ralph> were each asssigned a separate objective function? Use of a > Ralph> separate OF code point for each of the five possible = selected > Ralph> metrics would allow multiple RPL instances. >=20 > I think that it's important to understand that ROLL has a whole = palette of things that need to be provisioned by the "network operator". >=20 > In contrast to the situation of ISPs and customers, where the ISP is = the network operator, ROLL networks are more like highly orchestrated > Enterprises: "all your host belong to us" >=20 > so, when we write something like: > "The metric chosen by the network operator to use for path > selection." > in section 2, we really mean: > "The metric chosen by the network operator and provisioned into > the node when the firmware was flashed to use for path selection." >=20 > Ralph> 1. Why is one objective function defined for several potential=20= > Ralph> metrics? The details of MRHOF seem to preclude the = establishment=20 > Ralph> of several RPL instances in an LLN, each of which uses MRHOF = with=20 > Ralph> a different selected metric. >=20 > If one had many different RPL Instances, then we would have different > RPL Instance numbers in the RPL header. There can be many different > DODAG ("destinations") created within that instance. The instances = share a common set of (provisioned) parameters. >=20 > (To put it into DHCP terms: if we have multiple DHCP servers on a = link, then one would expect them to all offer IP addresses in the same = subnet. > If one wanted to have addresses in different subnets, and let the host = pick between them, then, one would need different layer-2s: different = VLANs or ESSIDs, or... ) >=20 > If you feel that RPL is rather schizo about provisioning vs = configuration, then I agree. It's not always clear to me why some = things are advertised while others are provisioned. >=20 > In BGPv4, we calculate metrics by adding AS entries in the path. > (It's always additive), and we add at least one AS entry to the path. > One can AS-stuff and add more, but proper operation of BGP does not = depend upon the exact algorithm used. >=20 > Finally, my impression is that how the various metrics are used = (singly, or in some combination) to calculate Rank Increase is a = question of further research, experimentation, and trade secret. =20 >=20 > So long as the Rank increases, and a node does not flap between = parents, the exact details do not matter. Each node can do it's parent = selection based upon the available metrics on it's own. It advertises = the metrics it has. >=20 > I hope the authors will correct me if I'm completely off here. >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Fri May 25 12:29:59 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34AA21F855B for ; Fri, 25 May 2012 12:29:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.904 X-Spam-Level: X-Spam-Status: No, score=-1.904 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qD654-1i4OK6 for ; Fri, 25 May 2012 12:29:59 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id B3AE621F853C for ; Fri, 25 May 2012 12:29:52 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 2D6658528; Fri, 25 May 2012 15:28:11 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 268E59823C; Fri, 25 May 2012 15:29:49 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1E4A598239; Fri, 25 May 2012 15:29:49 -0400 (EDT) From: Michael Richardson To: "Pascal Thubert (pthubert)" In-Reply-To: References: <12418.1337957631@marajade.sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Fri, 25 May 2012 15:29:49 -0400 Message-ID: <31164.1337974189@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: "roll@ietf.org" Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 19:30:00 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Pascal" =3D=3D Pascal Thubert <(pthubert)" > wri= tes: Pascal> I think RPL does not want to take party there. The OF is a Pascal> piece of logic to tie metrics and policies together.=20=20 My question is: =2D do the nodes of a DODAG have to use the same metrics to pick a parent, (and if so, how do they agree) I think that they do not, so long as they use an algorithm (such as MRHOF) which has certain properties. =2D if we had multiple RPL instances in an LLN, using different metrics, then we would have multiple RPL Instances and DODAGs. The different set of metrics would not co-exist in the same RPL Instance. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT7/drIqHRg3pndX9AQK0cQP/SN4UbWENKI0kSmzeCaT4io1GPNfiP7z+ qeqsaDLLccBEx+EUeiVonumJBLdkZYhx85THQun/zqKqsRreTRF/MsqQlieY4qh9 8SxWQNav+SgCCRFP30BHi9yR41ggqjfm6CC+xqSIZvZwPuhfqO2dHZP1wmzM+H7p CL5nre55tyo= =QEFn -----END PGP SIGNATURE----- --=-=-=-- From jreddy@ti.com Fri May 25 13:57:01 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6EA21F87C5 for ; Fri, 25 May 2012 13:57:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.599 X-Spam-Level: X-Spam-Status: No, score=-8.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ck3PsMU2MxDa for ; Fri, 25 May 2012 13:57:00 -0700 (PDT) Received: from bear.ext.ti.com (bear.ext.ti.com [192.94.94.41]) by ietfa.amsl.com (Postfix) with ESMTP id AB64021F8448 for ; Fri, 25 May 2012 13:57:00 -0700 (PDT) Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id q4PKuxth006999; Fri, 25 May 2012 15:57:00 -0500 Received: from DFLE70.ent.ti.com (dfle70.ent.ti.com [128.247.5.40]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id q4PKuxMk009337; Fri, 25 May 2012 15:56:59 -0500 Received: from DLEE10.ent.ti.com ([fe80::843:a4aa:bf01:3f68]) by DFLE70.ent.ti.com ([fe80::db3:609a:aa62:e1ec%22]) with mapi id 14.01.0323.003; Fri, 25 May 2012 15:57:00 -0500 From: "Reddy, Joseph" To: Mukul Goyal Thread-Topic: P2P-RPL: RIO/PIO in P2P-DIO Thread-Index: Ac06uOwwX3Y4CbuVTFqlKGFRgCOm/g== Date: Fri, 25 May 2012 20:56:58 +0000 Message-ID: <2AA5AC69E924D149A8D63EB676AF87DB2CA34049@DLEE10.ent.ti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.247.5.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] P2P-RPL: RIO/PIO in P2P-DIO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 20:57:01 -0000 SGkgTXVrdWwsDQoNClNlZSByZXNwb25zZSBiZWxvdyB0byB5b3VyIHJlc3BvbnNlIG9uIHRoZSBQ SU8vUklPIGluY2x1c2lvbiBpbiBQMlAgRElPIG1lc3NhZ2VzLg0KDQotUmVnYXJkcywgSm9zZXBo DQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCg0KW0pvc2VwaF0NClNlY3Rpb24gNi4x Og0KIi4uLkEgUDJQLURJTyBNQVkgY2Fycnkgb25lIG9yIG1vcmUgUklPIGFuZCBQSU8gb3B0aW9u cy4uLiINCkkgYW0gbm90IHN1cmUgaG93IHRoZXNlIG9wdGlvbnMgc2hvdWxkIGJlIHVzZWQgYnkg dGhlIERBRyBtZW1iZXJzLiBMYXRlciBvbiwgaW4gOS4xLCBpdCBzYXlzIHRoYXQgIi4udGhlIHRl bXBvcmFyeSBEQUcgbXVzdCBub3QgYmUgdXNlZCB0byByb3V0ZSBwYWNrZXRzLi4uLiIuIFNvIHdo YXQgaXMgdGhlIHB1cnBvc2Ugb2YgUklPIGFuZCBhbHNvIFBJTyA/DQoNCltNdWt1bF0NClRoZSBS SU8gd291bGQgYWR2ZXJ0aXplIHRvIHRoZSB0YXJnZXQocykgdGhlIG9yaWdpbidzIGNvbm5lY3Rp dml0eSB0byB0aGUgc3BlY2lmaWVkIHByZWZpeC4gUmVnYXJkaW5nIFBJTywgSSB3b3VsZCB2ZXJ5 IG11Y2ggbGlrZSB0byBhbGxvdyBQMlAgbW9kZSBESU9zIHRvIGNhcnJ5IFBJT3MgdG8gcHJvcGFn YXRlIHByZWZpeGVzIGZvciBhZGRyZXNzIHNlbGZjb25maWd1cmF0aW9uIChpLmUuIGhhdmUgQSBm bGFnIHNldCkuIEkgdGhpbmsgd2UgY291bGQgZm9yYmlkIHNldHRpbmcgdGhlIFIgZmxhZyB0byBv bmUgaW4gYSBQSU8gY2FycmllZCBpbiBhIFAyUCBtb2RlIERJT3MuIFJlZ2FyZGluZyB0aGUgTCBm bGFnLCBJIHRoaW5rIHdlIGNvdWxkIGFsbG93IGEgUDJQIG1vZGUgRElPIHRvIGNhcnJ5IGEgUElP IHdpdGggTCBmbGFnIHNldCBzdWJqZWN0IHRvIHRoZSBmb2xsb3dpbmcgcnVsZXMgaW4gUkZDIDY1 NTA6DQo8Li4uPg0KDQpbSm9zZXBoXQ0KVGhlIFJJTy9QSU8gaW5mb3JtYXRpb24gaXMgc2VudCBi eSB0aGUgT3JpZ2luIHRvIHByb3BhZ2F0ZSBpdHMgY29ubmVjdGl2aXR5IGFuZCBwcmVmaXggaW5m b3JtYXRpb24uIEhvd2V2ZXIsIHRoZSByb3V0ZSBpcyBlc3RhYmxpc2hlZCB0b3dhcmRzIHRoZSBU YXJnZXQuIFNvIEkgZG9u4oCZdCB1bmRlcnN0YW5kIHdoeSB0aGUgT3JpZ2luIGluZm9ybWF0aW9u IGlzIHJlbGV2YW50IC4uDQoNCg0K From jreddy@ti.com Fri May 25 14:07:57 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F87C21F8814 for ; Fri, 25 May 2012 14:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.599 X-Spam-Level: X-Spam-Status: No, score=-9.599 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrl82I1hhzNp for ; Fri, 25 May 2012 14:07:56 -0700 (PDT) Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by ietfa.amsl.com (Postfix) with ESMTP id 5FE7121F880F for ; Fri, 25 May 2012 14:07:56 -0700 (PDT) Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id q4PL7t0h000667; Fri, 25 May 2012 16:07:55 -0500 Received: from DFLE70.ent.ti.com (dfle70.ent.ti.com [128.247.5.40]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id q4PL7tKq020432; Fri, 25 May 2012 16:07:55 -0500 Received: from DLEE10.ent.ti.com ([fe80::843:a4aa:bf01:3f68]) by DFLE70.ent.ti.com ([fe80::db3:609a:aa62:e1ec%22]) with mapi id 14.01.0323.003; Fri, 25 May 2012 16:07:55 -0500 From: "Reddy, Joseph" To: Mukul Goyal Thread-Topic: P2P-RPL: Data-Option in P2P-DIO Thread-Index: Ac06ukqYlqXbLy4uQ+WsQbdrHuAImw== Date: Fri, 25 May 2012 21:07:55 +0000 Message-ID: <2AA5AC69E924D149A8D63EB676AF87DB2CA34066@DLEE10.ent.ti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.247.5.50] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] P2P-RPL: Data-Option in P2P-DIO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 21:07:57 -0000 SGkgTXVrdWwsDQoNClNlZSByZXNwb25zZSBiZWxvdy4uLg0KDQotUmVnYXJkcywgSm9zZXBoDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQoNCltKb3NlcGhdDQpTZWN0aW9uIDkuNA0KQnVs bGV0IDE6IA0KVW5kZXIgd2hhdCBjb25kaXRpb25zIHdvdWxkIGEgcm91dGVyIHJlY2VpdmUgdGhl IHNhbWUgRElPIGFuZCBhIERhdGEtT3B0aW9uIHdpdGggaGlnaGVyIHNlcXVlbmNlIG51bWJlcj8g SSBhc3N1bWUgdGhhdCBvbmx5IHRoZSBPcmlnaW5hdG9yIGNhbiBpbmNsdWRlIGEgRGF0YS1PcHRp b24gPyBTYW1lIHF1ZXN0aW9uIGFsc28gYXJpc2VzIGZvciBzZWN0aW9uIDkuNSAoIHBhcmEgMSAp DQoNCltNdWt1bF0NClllcywgb25seSB0aGUgb3JpZ2luIGNhbiBpbmNsdWRlIGEgZGF0YSBvcHRp b24gZm9yIGRlbGl2ZXJ5IHRvIHRoZSB0YXJnZXQocykuIEluIHRoZW9yeSwgdGhlIG9yaWdpbiBt aWdodCBoYXZlIG5ld2VyIGRhdGEgdG8gY29udmV5IHRvIHRoZSB0YXJnZXQocykgd2hpbGUgdGhl IHJvdXRlIGRpc2NvdmVyeSBpcyBzdGlsbCBnb2luZyBvbi4gU2VxdWVuY2UgbnVtYmVycyBhY2Nv dW50cyBmb3IgdGhhdCBwb3NzaWJpbGl0eS4gTm90ZSB0aGF0IERhdGEgb3B0aW9uIGRpZCBub3Qg aGF2ZSBhIHNlcXVlbmNlIG51bWJlciBlYXJsaWVyIChiZWZvcmUgdGhlIGZpcnN0IExDKS4gVGhl biwgUGFzY2FsIHJhaXNlZCB0aGUgcG9zc2liaWxpdHkgd2hhdCBpZiBvcmlnaW4gY2hhbmdlcyB0 aGUgZGF0YSBvcHRpb24uIEhvdyB3b3VsZCBpbnRlcm1lZGlhdGUgcm91dGVycyBhbmQgdGFyZ2V0 IGtub3cgdGhhdCB0aGlzIGlzIHRoZSBuZXdlciBkYXRhPyBIZW5jZSwgd2UgaW50cm9kdWNlZCB0 aGUgc2VxdWVuY2UgbnVtYmVyLg0KDQpbSm9zZXBoXQ0KSSBkb27igJl0IHRoaW5rIHRoZSBPcmln aW4gc2hvdWxkIGFibGUgdG8gdGhpcy4gSW4gZmFjdCwgdGhlIE9yaWdpbiBtdXN0IG5vdCBtYWtl IGFueSBjaGFuZ2VzIHRvIHRoZSBjb250ZW50cyBvZiB0aGUgRElPIGFuZCByZXRyYW5zbWl0IGl0 IHdpdGhvdXQgdXBkYXRpbmcgdGhlIHZlcnNpb24gbnVtYmVyLiBJZiB0aGUgT3JpZ2luIHdhbnRz IHRvIHNlbmQgZGF0YSwgaXQgc2hvdWxkIHNpbXBseSB3YWl0IHVudGlsIHRoZSBwMnAgcm91dGUg aXMgc2V0dXAgYW5kIHRoZW4gdXNlIGl0LiANCg0KVGhlIHdob2xlIGlkZWEgb2Ygc2VuZGluZyBV RFAgRGF0YSBtZXNzYWdlcyBpbiB0aGUgSUNNUCBtZXNzYWdlIHBheWxvYWQgaXRzZWxmIGRvZXNu 4oCZdCBzZWVtIHF1aXRlIHJpZ2h0LiBJdCBpcyBhbHNvIG5vdCBzaW1wbGUgZnJvbSBhbiBpbXBs ZW1lbnRhdGlvbiBwZXJzcGVjdGl2ZSB0byBtYWtlIHRoaXMga2luZCBvZiBjcm9zcyBsYXllciBp bnRlcmFjdGlvbnMuIA0KDQoNCg0KDQoNCg== From prvs=485d12915=mukul@uwm.edu Fri May 25 14:40:24 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7383521F87F1 for ; Fri, 25 May 2012 14:40:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.995 X-Spam-Level: X-Spam-Status: No, score=-5.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQ6QCRK2Zjg4 for ; Fri, 25 May 2012 14:40:24 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id D4CC621F87E9 for ; Fri, 25 May 2012 14:40:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEADT7v09/AAAB/2dsb2JhbABEhTazBSNEEhsODAINBBUCWQaIIKYUiT6JBIEki3qCEIESA4g/jFmPcIJ+gTgg Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 29A3812E3BA; Fri, 25 May 2012 16:40:23 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JXnvnTJePZWN; Fri, 25 May 2012 16:40:22 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id E830412E3AE; Fri, 25 May 2012 16:40:22 -0500 (CDT) Date: Fri, 25 May 2012 16:40:22 -0500 (CDT) From: Mukul Goyal To: Joseph Reddy Message-ID: <1339758364.520004.1337982022814.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CA34049@DLEE10.ent.ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] P2P-RPL: RIO/PIO in P2P-DIO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 21:40:24 -0000 Hi Joseph Please see inline. Thanks Mukul [Joseph1] Section 6.1: "...A P2P-DIO MAY carry one or more RIO and PIO options..." I am not sure how these options should be used by the DAG members. Later on= , in 9.1, it says that "..the temporary DAG must not be used to route packe= ts....". So what is the purpose of RIO and also PIO ? [Mukul1] The RIO would advertize to the target(s) the origin's connectivity to the s= pecified prefix. Regarding PIO, I would very much like to allow P2P mode DI= Os to carry PIOs to propagate prefixes for address selfconfiguration (i.e. = have A flag set). I think we could forbid setting the R flag to one in a PI= O carried in a P2P mode DIOs. Regarding the L flag, I think we could allow = a P2P mode DIO to carry a PIO with L flag set subject to the following rule= s in RFC 6550: <...> [Joseph2] The RIO/PIO information is sent by the Origin to propagate its connectivity= and prefix information. However, the route is established towards the Targ= et. So I don=E2=80=99t understand why the Origin information is relevant .. [Mukul2] Here is some relevant text from Section 9.3: "A router SHOULD discard a received P2P mode DIO with no further processing if it does not have bidirectional reachability with the neighbor that generated the received DIO. Note that bidirectional reachability does not mean that the link must have the same values for a routing metric in both directions. A router SHOULD calculate the values of the link-level routing metrics included in the received DIO taking in account the metric's value in both forward and Backward directions. Bidirectional reachability along a discovered route allows the Target to use this route to reach the Origin. In particular, the DRO messages travel from the Target to the Origin along a discovered route. " So, the target can certainly use a discovered route as a source route to re= ach the origin. The backward direction route may not meet desired routing c= onstraints but does provide a way to reach the origin. So, it may be useful= for the target to know what destination prefixes can be reached via the or= igin. In fact, it makes sense to allow the target to include one or more R= IOs in its DRO to let origin know what destination prefixes could be reache= d via the target. Regarding the PIO, I think the most critical need is to allow the propagati= on of address self-configuration prefixes via P2P mode DIOs. These prefixes= can be used not only by the target but also the other nodes that join the = temporary DAG. I am not too sure about allowing PIOs with L flag set inside= the P2P mode DIOs. Would certainly like to hear your views on this. From prvs=485d12915=mukul@uwm.edu Fri May 25 14:47:39 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B893F21F880F for ; Fri, 25 May 2012 14:47:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.197 X-Spam-Level: X-Spam-Status: No, score=-6.197 tagged_above=-999 required=5 tests=[AWL=0.402, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvGPHIpz60p6 for ; Fri, 25 May 2012 14:47:39 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 10CE821F880E for ; Fri, 25 May 2012 14:47:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAHr9v09/AAAB/2dsb2JhbABEhTazBCNWGw4MAg0ZAlkGiCCmEIk6iQSBJI4KgRIDiD+MWY9wgn4 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 986C9E6A8E; Fri, 25 May 2012 16:47:35 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta01.pantherlink.uwm.edu Received: from mta01.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta01.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m2ti8AhPPFxy; Fri, 25 May 2012 16:47:35 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 69F2EE6A72; Fri, 25 May 2012 16:47:35 -0500 (CDT) Date: Fri, 25 May 2012 16:47:35 -0500 (CDT) From: Mukul Goyal To: Joseph Reddy Message-ID: <183104642.520057.1337982455333.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CA34066@DLEE10.ent.ti.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] P2P-RPL: Data-Option in P2P-DIO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2012 21:47:39 -0000 Hi Joseph Please see inline. Thanks Mukul [Joseph1] Section 9.4 Bullet 1:=20 Under what conditions would a router receive the same DIO and a Data-Option= with higher sequence number? I assume that only the Originator can include= a Data-Option ? Same question also arises for section 9.5 ( para 1 ) [Mukul1] Yes, only the origin can include a data option for delivery to the target(s= ). In theory, the origin might have newer data to convey to the target(s) w= hile the route discovery is still going on. Sequence numbers accounts for t= hat possibility. Note that Data option did not have a sequence number earli= er (before the first LC). Then, Pascal raised the possibility what if origi= n changes the data option. How would intermediate routers and target know t= hat this is the newer data? Hence, we introduced the sequence number. [Joseph2] I don=E2=80=99t think the Origin should able to this. In fact, the Origin m= ust not make any changes to the contents of the DIO and retransmit it witho= ut updating the version number. If the Origin wants to send data, it should= simply wait until the p2p route is setup and then use it.=20 The whole idea of sending UDP Data messages in the ICMP message payload its= elf doesn=E2=80=99t seem quite right. It is also not simple from an impleme= ntation perspective to make this kind of cross layer interactions.=20 [Mukul2] I think that implementation concerns (regarding sending UDP data inside ICM= P message) might be valid and would like to hear more opinions in this rega= rd. But, I also think that LLNs need cross layer interactions and this expe= rimental RFC might be the perfect place to check if this works or not. Cert= ainly, the need to piggyback data on route discovery packets is real in man= y LLN applications. In my opinion, we should allow this unless there are ov= erpowering reasons why this is a bad idea. From prvs=486a8a597=mukul@uwm.edu Fri May 25 22:26:24 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2E121F851C for ; Fri, 25 May 2012 22:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8wytaV5WCiR for ; Fri, 25 May 2012 22:26:23 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id A19F521F851A for ; Fri, 25 May 2012 22:26:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwEAC5owE9/AAAB/2dsb2JhbABEhTazBiNWKQwCDRkCWQaIHqYliSiJBIEkjguBEgOIP4xXj3CCfg Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id D97FD12E3BB; Sat, 26 May 2012 00:26:22 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rs43AiX6OezO; Sat, 26 May 2012 00:26:22 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 9BEF712E3BA; Sat, 26 May 2012 00:26:22 -0500 (CDT) Date: Sat, 26 May 2012 00:26:22 -0500 (CDT) From: Mukul Goyal To: Michael Richardson Message-ID: <831338825.521366.1338009982543.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <566085064.521293.1338006033112.JavaMail.root@mail17.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: [Roll] Ralph's DISCUSS on MRHOF spec X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 05:26:24 -0000 Hi Michael This would be my response to the questions Ralph asked. Thanks Mukul [Ralph] 1. Why is one objective function defined for several potential metrics? The details of MRHOF seem to preclude the establishment of several RPL instances in an LLN, each of which uses MRHOF with a different selected metric. [Mukul] It is certainly possible to establish multiple RPL Instances in an LLN with MRHOF (or any other OF) as the OF. These RPL Instances may or may not use different routing metrics. An RPL Instance is associated with one particular OF as per RFC 6550. The OF converts the aggregated routing metric values to a rank value. Whether a particular OF could work with a particular metric depends on the OF. E.g. MRHOF specification says that MRHOF only works with additive metrics. So, the choice of routing metrics to be used in a particular DODAG (identified by the DODAGID) inside a particular RPL Instance may depend on the particular OF being used but, in general, the choice of OF and the choice of routing metrics are separate/independent issues. [Ralph] 2. How are the nodes in the RPL instance informed about the selected metric? My understanding of RPL is that only the objective function is included in the DIO received as an advertisement for a particular RPL instance, which means a node can't know the selected metric for that RPL instance and can't meaningfully decide among multiple RPL instances all using MRHOF as the objective function. As a followup to (1), if there were a way to encode the selected metric for a RPL instance in the DAO, a node would be able to select which RPL instance to use for a particular type of traffic. [Mukul] The root of a DODAG includes the selected metric objects in the Metric Container Option(s) inside its DIO. The nodes that join this DODAG include the same metric objects in their DIOs and so on. Thats how the nodes come to know which routing metrics are in use in a particular DODAG in a particular RPL Instance. [Ralph] 3. Based on (1) and (2), would configuration and selection issues be ameliorated if the five candidate selected metrics were each asssigned a separate objective function? Use of a separate OF code point for each of the five possible selected metrics would allow multiple RPL instances. [Mukul] Multiple RPL instances with same OF are already allowed. The whole idea behind OF is to separate the rank selection logic from the routing metrics. [Ralph] 4. Related to the above, I don't see anything in section 6 about managing the selected metric. Don't all of the nodes that join a RPL instance using MRHOF have to be configured to use the same selected metric? [Mukul] Yes. As mentioned above, the root of a DODAG selects which routing metrics would be used and includes these metric objects inside the Metric Container inside the DIO. A node can join this DAG only if it supports the routin metrics being used. [Ralph] 5. In section 3.2.2: a node MAY use a different objective function to select which of these neighbors should be considered to have the lowest cost. seems to contradict the statement in the Introduction that "all nodes in a network use a common OF." Should "different objective function" be replaced with "some other selection criteria?" [Mukul] That makes sense to me. [Ralph] 6. In section 5, are the RECOMMENDED values appropriate for all selected metrics or just for ETX? Are there any references that might be cited that would give background on the working group experience with ETX and the development of the recommended values? 7. In section 6.1, why not "MUST support the DODAG Configuration option?" I don't see any RFC 2119 requirements on the implementation of the DODAG Configuration option (which would appera to be an oversight), but I don't understand how a node can operate in a RPL instance without, for example, being able to determine the Objective Function used by that instance. [Mukul] That particular statement indeed sounds redundant to me. I think every RPL implementation MUST understand the DODAG Configuration Option. From prvs=486a8a597=mukul@uwm.edu Fri May 25 23:00:59 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C3DC21F85D1 for ; Fri, 25 May 2012 23:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.358 X-Spam-Level: X-Spam-Status: No, score=-6.358 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IteVONyiPnVW for ; Fri, 25 May 2012 23:00:58 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by ietfa.amsl.com (Postfix) with ESMTP id 65FE421F851B for ; Fri, 25 May 2012 23:00:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAHxwwE9/AAAB/2dsb2JhbABEhTayfwEBAQQBAQEgSwsMDxEEAQEDAg0ZAikoCAYTiAsLpg+JJIkEgSSJXoQtgRIDiD+MV4EPjmGCfg Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id D96D512E3CA; Sat, 26 May 2012 01:00:57 -0500 (CDT) X-Virus-Scanned: amavisd-new at mta02.pantherlink.uwm.edu Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoP0vnEd4e2x; Sat, 26 May 2012 01:00:57 -0500 (CDT) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id E29AB12E3CD; Sat, 26 May 2012 01:00:53 -0500 (CDT) Date: Sat, 26 May 2012 01:00:53 -0500 (CDT) From: Mukul Goyal To: Michael Richardson Message-ID: <669980998.521393.1338012053807.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <31164.1337974189@marajade.sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 May 2012 06:00:59 -0000 Hi Michael Here is my take: [MCR] - do the nodes of a DODAG have to use the same metrics to pick a parent, (and if so, how do they agree) I think that they do not, so long as they use an algorithm (such as MRHOF) which has certain properties. [Mukul] Yes, the nodes in a DODAG have to use the same metrics. Otherwise, it is not possible for an OF to map the aggregated (from root till this node) values of the metrics to a rank. [MCR] - if we had multiple RPL instances in an LLN, using different metrics, then we would have multiple RPL Instances and DODAGs. The different set of metrics would not co-exist in the same RPL Instance. [Mukul] Not sure what does the first sentence mean. About the second, different sets of metrics can certainly coexist in the same RPL instance. An RPL Instance is associated with a particular OF but different DODAGs in the RPL Instance can certainly use different routing metrics. Thanks Mukul ----- Original Message ----- From: "Michael Richardson" To: "Pascal Thubert (pthubert)" Cc: roll@ietf.org Sent: Friday, May 25, 2012 2:29:49 PM Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> I think RPL does not want to take party there. The OF is a Pascal> piece of logic to tie metrics and policies together. My question is: - do the nodes of a DODAG have to use the same metrics to pick a parent, (and if so, how do they agree) I think that they do not, so long as they use an algorithm (such as MRHOF) which has certain properties. - if we had multiple RPL instances in an LLN, using different metrics, then we would have multiple RPL Instances and DODAGs. The different set of metrics would not co-exist in the same RPL Instance. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon May 28 12:05:02 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7FA21F85A8 for ; Mon, 28 May 2012 12:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gUtXw0Zf7Vjl for ; Mon, 28 May 2012 12:05:01 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 416B521F85A5 for ; Mon, 28 May 2012 12:05:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pthubert@cisco.com; l=1626; q=dns/txt; s=iport; t=1338231901; x=1339441501; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=dRu06+7halqyQNZyI4KrW1MNNSVrSM0zunEB3wxneYA=; b=nFxlw1Jmu+OP83Axf4fOQwzHsSuoX/3NWkSf1j11eYoBfSfLf/O24mab 20qzEyHKU1adoPVjqerVWyl4QqL8x1W4ft5Wxv9oAFfIk8FGSHJPi9UHP 2NTbpSM/boa8oc8o3r4HWrBa1DNg39idYHsZBmRRlz7WWB+GqjwtsvVBI w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAHjLw0+tJXG9/2dsb2JhbABEtWCBB4IYAQEEEgEnPxACAQgiFBAyJQIEDgUIGodpC5hHnzWPYmADliaMfYFlgmA X-IronPort-AV: E=Sophos;i="4.75,672,1330905600"; d="scan'208";a="87340225" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 28 May 2012 19:05:00 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id q4SJ50gw008388 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 May 2012 19:05:00 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.238]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0298.004; Mon, 28 May 2012 14:05:00 -0500 From: "Pascal Thubert (pthubert)" To: Michael Richardson Thread-Topic: [Roll] knowing which multiple metrics matter: MRHOF related questions Thread-Index: AQHNOqzFx9D7pmKKKUa/9nhCRcvc8JbfkeWA Date: Mon, 28 May 2012 19:04:59 +0000 Deferred-Delivery: Mon, 28 May 2012 19:04:00 +0000 Message-ID: References: <12418.1337957631@marajade.sandelman.ca> <31164.1337974189@marajade.sandelman.ca> In-Reply-To: <31164.1337974189@marajade.sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.87.128] x-tm-as-product-ver: SMEX-10.2.0.1135-6.800.1017-18934.001 x-tm-as-result: No--33.164300-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] knowing which multiple metrics matter: MRHOF related questions X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 May 2012 19:05:02 -0000 Hello Micheal >>>>> "Pascal" =3D=3D Pascal Thubert <(pthubert)" > wri= tes: Pascal> I think RPL does not want to take party there. The OF is a Pascal> piece of logic to tie metrics and policies together. =20 My question is: - do the nodes of a DODAG have to use the same metrics to pick a parent, (and if so, how do they agree) I think that they do not, so long as they use an algorithm (such as MRHOF) which has certain properties. [Pascal] The current spec requires that all players of an instance play by= the same rule, that is same OF, in order to guarantee the expected result.= =20 The goal there was deeper than the OF, like same OF with same parameterizat= ion. MRHOF is generic and allows various incarnations, depending in the met= rics; all those incarnations are to be seen as different OFs WRT to RPL 's = uniqueness rule. Note that this rule is not for looplessness, the Rank would assure that any= way. - if we had multiple RPL instances in an LLN, using different metrics, then we would have multiple RPL Instances and DODAGs. The different set of metrics would not co-exist in the same RPL Instance. [Pascal] I think we agree. An instance can use multiple metrics bound by so= me logic. But those metrics and that logic must be identical throughout the= instance.=20 A different (set of) metric means a different OF even if MRHOF is behind bo= th. Cheers, Pascal --=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From Anders_Brandt@sigmadesigns.com Tue May 29 00:32:27 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9228821F84D6 for ; Tue, 29 May 2012 00:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rlZrJFG1+u2g for ; Tue, 29 May 2012 00:32:26 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 6118821F8593 for ; Tue, 29 May 2012 00:32:26 -0700 (PDT) From: Anders Brandt To: Michael Richardson , "roll@ietf.org" Thread-Topic: draft-brandt-roll-rpl-applicability-home-building-01 reposted as -02 Thread-Index: Ac09bLngqU8xNOxRSDqgqaf6s0lFYw== Date: Tue, 29 May 2012 07:32:23 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0ABFB7B9@cph-ex1> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com Subject: [Roll] draft-brandt-roll-rpl-applicability-home-building-01 reposted as -02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 07:32:27 -0000 As per request by the ROLL WG co-chair, I have reposted this applicability = statement as revision -02. http://www.ietf.org/id/draft-brandt-roll-rpl-applicability-home-building-02= .txt No changes have been made since the -01 version. The purpose is to make this a live document which can be adopted as a WG do= c. It is the intention that another -03 revision will be created; reflecting t= he introduction of RPL-P2P, which solves the issues that are addressed in -01 (and -02). Thanks, Anders > -----Original Message----- > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of > Michael Richardson > Sent: Wednesday, May 23, 2012 16:14 > To: roll@ietf.org > Cc: Anders Brandt > Subject: Re: [Roll] proposal for common table of contents for applicabili= ty > statements >=20 >=20 > >>>>> "Anders" =3D=3D Anders Brandt > writes: > Anders> It is here >=20 > Anders> http://tools.ietf.org/html/draft-brandt-roll-rpl-applicabilit= y- > home-building-01 >=20 > Anders> In its current state it is more like a problem statement... >=20 > It expired. > Can you at least repost the -01 document (as -02)? >=20 > I would like to propose that this become a WG document. >=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From Anders_Brandt@sigmadesigns.com Tue May 29 00:32:46 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB49D21F85A7 for ; Tue, 29 May 2012 00:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 99YoYyLPokZR for ; Tue, 29 May 2012 00:32:46 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id BB30F21F84D6 for ; Tue, 29 May 2012 00:32:45 -0700 (PDT) From: Anders Brandt To: Michael Richardson , "roll@ietf.org" Thread-Topic: [Roll] proposal for common table of contents for applicability statements Thread-Index: AQHNOO5LCzDCX9kzvk+cqad4hwEID5bgaIgg Date: Tue, 29 May 2012 07:32:43 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0ABFB7CD@cph-ex1> References: <20120430114209.21250.82110.idtracker@ietfa.amsl.com> <18151.1335822136@marajade.sandelman.ca> <10134.1337103877@marajade.sandelman.ca> <03F31C213F2C6941BFDDBB4336E9E6CD0ABE8F25@cph-ex1> <22501.1337782430@marajade.sandelman.ca> In-Reply-To: <22501.1337782430@marajade.sandelman.ca> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.68] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-FEAS-SYSTEM-WL: anders_brandt@sigmadesigns.com Subject: Re: [Roll] proposal for common table of contents for applicability statements X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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 May 2012 07:32:46 -0000 Michael, > I would like to propose that this become a WG document. Done! - Anders > -----Original Message----- > From: mcr@sandelman.ca [mailto:mcr@sandelman.ca] On Behalf Of > Michael Richardson > Sent: Wednesday, May 23, 2012 16:14 > To: roll@ietf.org > Cc: Anders Brandt > Subject: Re: [Roll] proposal for common table of contents for applicabili= ty > statements >=20 >=20 > >>>>> "Anders" =3D=3D Anders Brandt > writes: > Anders> It is here >=20 > Anders> http://tools.ietf.org/html/draft-brandt-roll-rpl-applicabilit= y- > home-building-01 >=20 > Anders> In its current state it is more like a problem statement... >=20 > It expired. > Can you at least repost the -01 document (as -02)? >=20 > I would like to propose that this become a WG document. >=20 >=20 >=20 > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From Jakob_Buron@sigmadesigns.com Tue May 29 06:24:06 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79C6621F87A5 for ; Tue, 29 May 2012 06:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.509 X-Spam-Level: X-Spam-Status: No, score=-2.509 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NOmvx9xz8d-I for ; Tue, 29 May 2012 06:24:06 -0700 (PDT) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id A0CFD21F85CC for ; Tue, 29 May 2012 06:24:05 -0700 (PDT) From: Jakob Buron To: "'Reddy, Joseph'" , Mukul Goyal Thread-Topic: P2P-RPL: Data-Option in P2P-DIO Thread-Index: Ac06ukqYlqXbLy4uQ+WsQbdrHuAImwC49CSg Date: Tue, 29 May 2012 13:24:03 +0000 Message-ID: <6CD8B4189A89EB4FB816FA9827F6F65F0ABCD132@cph-ex1> References: <2AA5AC69E924D149A8D63EB676AF87DB2CA34066@DLEE10.ent.ti.com> In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CA34066@DLEE10.ent.ti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.77] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-FEAS-SYSTEM-WL: jakob_buron@sigmadesigns.com Cc: "roll@ietf.org" Subject: Re: [Roll] P2P-RPL: Data-Option in P2P-DIO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 13:24:06 -0000 SGksIHBsZWFzZSBzZWUgbXkgY29tbWVudHMgaW5saW5lLg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+IEZyb206IHJvbGwtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJvbGwtYm91 bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+IFJlZGR5LCBKb3NlcGgNCj4gU2VudDogRnJp ZGF5LCBNYXkgMjUsIDIwMTIgMTE6MDggUE0NCj4gVG86IE11a3VsIEdveWFsDQo+IENjOiByb2xs QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbUm9sbF0gUDJQLVJQTDogRGF0YS1PcHRpb24gaW4g UDJQLURJTw0KPiANCj4gSGkgTXVrdWwsDQo+IA0KPiBTZWUgcmVzcG9uc2UgYmVsb3cuLi4NCj4g DQo+IC1SZWdhcmRzLCBKb3NlcGgNCj4gDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ IA0KPiBbSm9zZXBoXQ0KPiBTZWN0aW9uIDkuNA0KPiBCdWxsZXQgMToNCj4gVW5kZXIgd2hhdCBj b25kaXRpb25zIHdvdWxkIGEgcm91dGVyIHJlY2VpdmUgdGhlIHNhbWUgRElPIGFuZCBhIERhdGEt DQo+IE9wdGlvbiB3aXRoIGhpZ2hlciBzZXF1ZW5jZSBudW1iZXI/IEkgYXNzdW1lIHRoYXQgb25s eSB0aGUgT3JpZ2luYXRvciBjYW4NCj4gaW5jbHVkZSBhIERhdGEtT3B0aW9uID8gU2FtZSBxdWVz dGlvbiBhbHNvIGFyaXNlcyBmb3Igc2VjdGlvbiA5LjUgKCBwYXJhDQo+IDEgKQ0KPiANCj4gW011 a3VsXQ0KPiBZZXMsIG9ubHkgdGhlIG9yaWdpbiBjYW4gaW5jbHVkZSBhIGRhdGEgb3B0aW9uIGZv ciBkZWxpdmVyeSB0byB0aGUNCj4gdGFyZ2V0KHMpLiBJbiB0aGVvcnksIHRoZSBvcmlnaW4gbWln aHQgaGF2ZSBuZXdlciBkYXRhIHRvIGNvbnZleSB0byB0aGUNCj4gdGFyZ2V0KHMpIHdoaWxlIHRo ZSByb3V0ZSBkaXNjb3ZlcnkgaXMgc3RpbGwgZ29pbmcgb24uIFNlcXVlbmNlIG51bWJlcnMNCj4g YWNjb3VudHMgZm9yIHRoYXQgcG9zc2liaWxpdHkuIE5vdGUgdGhhdCBEYXRhIG9wdGlvbiBkaWQg bm90IGhhdmUgYQ0KPiBzZXF1ZW5jZSBudW1iZXIgZWFybGllciAoYmVmb3JlIHRoZSBmaXJzdCBM QykuIFRoZW4sIFBhc2NhbCByYWlzZWQgdGhlDQo+IHBvc3NpYmlsaXR5IHdoYXQgaWYgb3JpZ2lu IGNoYW5nZXMgdGhlIGRhdGEgb3B0aW9uLiBIb3cgd291bGQNCj4gaW50ZXJtZWRpYXRlIHJvdXRl cnMgYW5kIHRhcmdldCBrbm93IHRoYXQgdGhpcyBpcyB0aGUgbmV3ZXIgZGF0YT8gSGVuY2UsDQo+ IHdlIGludHJvZHVjZWQgdGhlIHNlcXVlbmNlIG51bWJlci4NCj4gDQo+IFtKb3NlcGhdDQo+IEkg ZG9u4oCZdCB0aGluayB0aGUgT3JpZ2luIHNob3VsZCBhYmxlIHRvIHRoaXMuIEluIGZhY3QsIHRo ZSBPcmlnaW4gbXVzdA0KPiBub3QgbWFrZSBhbnkgY2hhbmdlcyB0byB0aGUgY29udGVudHMgb2Yg dGhlIERJTyBhbmQgcmV0cmFuc21pdCBpdCB3aXRob3V0DQo+IHVwZGF0aW5nIHRoZSB2ZXJzaW9u IG51bWJlci4gSWYgdGhlIE9yaWdpbiB3YW50cyB0byBzZW5kIGRhdGEsIGl0IHNob3VsZA0KPiBz aW1wbHkgd2FpdCB1bnRpbCB0aGUgcDJwIHJvdXRlIGlzIHNldHVwIGFuZCB0aGVuIHVzZSBpdC4N Cj4gDQo+IFRoZSB3aG9sZSBpZGVhIG9mIHNlbmRpbmcgVURQIERhdGEgbWVzc2FnZXMgaW4gdGhl IElDTVAgbWVzc2FnZSBwYXlsb2FkDQo+IGl0c2VsZiBkb2VzbuKAmXQgc2VlbSBxdWl0ZSByaWdo dC4gSXQgaXMgYWxzbyBub3Qgc2ltcGxlIGZyb20gYW4NCj4gaW1wbGVtZW50YXRpb24gcGVyc3Bl Y3RpdmUgdG8gbWFrZSB0aGlzIGtpbmQgb2YgY3Jvc3MgbGF5ZXIgaW50ZXJhY3Rpb25zLg0KPiAN CltKYWtvYl0NCkkgdW5kZXJzdGFuZCB0aGUgY29uY2VybiBhYm91dCB0aGUgRGF0YSBPcHRpb24g YW5kIGNyb3NzLWxheWVyIGludGVyYWN0aW9ucy4gSSBhbHNvIGJlbGlldmUgdGhhdCBpdCBpcyBh IHNlbnNpYmxlIGFuZCBuZWNlc3NhcnkgZGVzaWduIGNob2ljZSBmb3IgaG9tZSBhdXRvbWF0aW9u IG5ldHdvcmtzLiBIb21lIGF1dG9tYXRpb24gZnJlcXVlbnRseSByZXF1aXJlcyBsb3ctbGF0ZW5j eSBtZXNzYWdlcyB0byBiZSBkZWxpdmVyZWQgdG8gdGFyZ2V0cyBmb3Igd2hpY2ggdGhlIG9yaWdp bmF0b3IgaGFzIG5vIHJvdXRlLiBBbiBleGFtcGxlIGlzIGEgcmVtb3RlIGxpZ2h0IHN3aXRjaCB0 aGF0IG5lZWRzIHRvIGNvbnRyb2wgYSByZWxvY2F0ZWQgbGFtcC4gVGhlIGZhc3Rlc3Qgd2F5IHRv IGRvIHRoYXQgaW4gYSByZWFjdGl2ZSByb3V0aW5nIHNjaGVtZSBpcyB0byBwaWdneWJhY2sgdGhl IGRhdGEgb24gdGhlIHJvdXRpbmcgcGFja2V0cy4gVGhlIG90aGVyIG9wdGlvbiB3b3VsZCBiZSB0 byB1c2Ugc2ltcGxlIGZsb29kaW5nLCB3aXRoIG5vIHRyaWNrbGUgY29udHJvbCwgd2hpY2ggd291 bGQgaW52b2x2ZSBnZW5lcmF0aW5nIGEgaHVnZSBudW1iZXIgb2YgcGFja2V0cy4gUGlnZ3liYWNr aW5nIGRhdGEgb24gcm91dGluZyBwYWNrZXRzIGhlbHBzIGF2b2lkIGdlbmVyYXRpbmcgZXh0cmEg cGFja2V0cy4NCg0KSG9tZSBhdXRvbWF0aW9uIG5ldHdvcmtzIGRvIG5vdCBuZWVkIHRvIHVwZGF0 ZSB0aGUgRGF0YSBPcHRpb24gd2hpbGUgYSBkaXNjb3ZlcnkgaXMgaW4gcHJvZ3Jlc3MuIEkgYW0g b2theSB3aXRoIHJlbW92aW5nIHRoZSBzZXF1ZW5jZSBudW1iZXJzIGlmIHRoZXkgYWRkIHRvbyBt dWNoIGNvbXBsZXhpdHkuDQoNCkJlc3QgcmVnYXJkcywNCkpha29iDQo+IA0KPiANCj4gDQo+IA0K PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBSb2xs IG1haWxpbmcgbGlzdA0KPiBSb2xsQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vcm9sbA0K From mcr@sandelman.ca Tue May 29 11:02:57 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A270811E8114 for ; Tue, 29 May 2012 11:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9I2YFiul+8i1 for ; Tue, 29 May 2012 11:02:57 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by ietfa.amsl.com (Postfix) with ESMTP id 8130E11E8110 for ; Tue, 29 May 2012 11:02:55 -0700 (PDT) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id D5D6088E9 for ; Tue, 29 May 2012 14:00:59 -0400 (EDT) Received: by sandelman.ca (Postfix, from userid 179) id 92A8DCD4D5; Tue, 29 May 2012 14:02:48 -0400 (EDT) Received: from marajade.sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8F2DFDC015 for ; Tue, 29 May 2012 14:02:48 -0400 (EDT) From: Michael Richardson To: "roll@ietf.org" In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD0ABFB7B9@cph-ex1> References: <03F31C213F2C6941BFDDBB4336E9E6CD0ABFB7B9@cph-ex1> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Tue, 29 May 2012 14:02:48 -0400 Message-ID: <32315.1338314568@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] draft-brandt-roll-rpl-applicability-home-building-01 reposted as -02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 May 2012 18:02:57 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Anders" =3D=3D Anders Brandt writes: Anders> As per request by the ROLL WG co-chair, I have reposted this Anders> applicability statement as revision -02.=20 Anders> http://www.ietf.org/id/draft-brandt-roll-rpl-applicability-home= -building-02.txt Anders> No changes have been made since the -01 version.=20 Anders> The purpose is to make this a live document which can be Anders> adopted as a WG doc.=20 Anders> It is the intention that another -03 revision will be Anders> created; reflecting the introduction of RPL-P2P,=20 Anders> which solves the issues that are addressed in -01 (and -02). I propose adopting this document as WG document. Please comment by June 11, 2012. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iQCVAwUAT8UPSIqHRg3pndX9AQKJ0AP+JtpYZ+ALepZnAbafIQUiVIaTyUQSRn2t HPIUVtjtL/VPQrqV2c8IvOSCqLUffaqxDy8BSOPQSrP7Lk2CLZabL8UPU/V3lwmp 9IvAGv55/28kZRPQ+gpUO/oC45JTr39zmtuCbOu6uVEJMqa0+8KyUDXedVNDQd3K Z0RT0DBzBO4= =CiSg -----END PGP SIGNATURE----- --=-=-=-- From B10623@freescale.com Wed May 30 01:58:55 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B2621F86E3 for ; Wed, 30 May 2012 01:58:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.367 X-Spam-Level: X-Spam-Status: No, score=-3.367 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKN2g1KT-HI3 for ; Wed, 30 May 2012 01:58:54 -0700 (PDT) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe003.messaging.microsoft.com [213.199.154.141]) by ietfa.amsl.com (Postfix) with ESMTP id 0E93A21F86D7 for ; Wed, 30 May 2012 01:58:53 -0700 (PDT) Received: from mail58-db3-R.bigfish.com (10.3.81.231) by DB3EHSOBE003.bigfish.com (10.3.84.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 May 2012 08:58:23 +0000 Received: from mail58-db3 (localhost [127.0.0.1]) by mail58-db3-R.bigfish.com (Postfix) with ESMTP id 7ED12120317 for ; Wed, 30 May 2012 08:58:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:70.37.183.190; KIP:(null); UIP:(null); IPV:NLI; H:mail.freescale.net; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VS1(zzc85fhzz1202hzz8275bh8275dhz2dh2a8h668h839h8e2h8e3hd25hf0ahbe9i) Received: from mail58-db3 (localhost.localdomain [127.0.0.1]) by mail58-db3 (MessageSwitch) id 1338368302140831_7342; Wed, 30 May 2012 08:58:22 +0000 (UTC) Received: from DB3EHSMHS006.bigfish.com (unknown [10.3.81.228]) by mail58-db3.bigfish.com (Postfix) with ESMTP id 20E7C1E0044 for ; Wed, 30 May 2012 08:58:22 +0000 (UTC) Received: from mail.freescale.net (70.37.183.190) by DB3EHSMHS006.bigfish.com (10.3.87.106) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 May 2012 08:58:20 +0000 Received: from 039-SN1MPN1-001.039d.mgd.msft.net ([169.254.1.135]) by 039-SN1MMR1-003.039d.mgd.msft.net ([10.84.1.16]) with mapi id 14.02.0298.005; Wed, 30 May 2012 03:58:24 -0500 From: Tecuceanu Andreea-Dana-B10623 To: "roll@ietf.org" Thread-Topic: RPLInstanceID parameter from Source Routing Header is missing in RFC6554 Thread-Index: Ac0+Pc2lbhIKR8s+RJStkW2FSI3EUQABIDNQ Date: Wed, 30 May 2012 08:58:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.171.73.68] Content-Type: multipart/alternative; boundary="_000_C4731EA2F8833047869F2B5DB5F72C262E3CD9039SN1MPN1001039d_" MIME-Version: 1.0 X-OriginatorOrg: freescale.com Subject: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 08:58:55 -0000 --_000_C4731EA2F8833047869F2B5DB5F72C262E3CD9039SN1MPN1001039d_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have observed that the RPLInstanceID field from Source Routing header (pr= esent in draft-ietf-6man-rpl-routing-header-07) was removed in RFC6554. Are there particular reasons for this? This field is necessary at the DODAG= Root when it receives a Destination Unreachable with code "Error in Sourc= e Routing Header" to identify the instance with the problem (only if there = are two instances with the same prefix and if the node is Root in both of t= hem). Andreea Tecuceanu (Freescale Semiconductor) --_000_C4731EA2F8833047869F2B5DB5F72C262E3CD9039SN1MPN1001039d_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

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

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

&n= bsp;

 

Andreea Tecuceanu=
(Freescale Semiconductor)

--_000_C4731EA2F8833047869F2B5DB5F72C262E3CD9039SN1MPN1001039d_-- From adrian@olddog.co.uk Wed May 30 02:44:18 2012 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBBCB21F86DF for ; Wed, 30 May 2012 02:44:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.307, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QFBJavneZ9Iz for ; Wed, 30 May 2012 02:44:17 -0700 (PDT) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id AA34921F86DE for ; Wed, 30 May 2012 02:44:15 -0700 (PDT) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q4U9i9T1011304; Wed, 30 May 2012 10:44:10 +0100 Received: from 950129200 (dsl-sp-81-140-15-32.in-addr.broadbandscope.com [81.140.15.32]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id q4U9i7CK011243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 May 2012 10:44:08 +0100 From: "Adrian Farrel" To: "'Tecuceanu Andreea-Dana-B10623'" , References: In-Reply-To: Date: Wed, 30 May 2012 10:44:06 +0100 Message-ID: <0c2f01cd3e48$c1e7be10$45b73a30$@olddog.co.uk> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0C30_01CD3E51.23B092E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKeZsMS7YMnABm+3AE7qQKQGdnfRJU/ws5Q Content-Language: en-gb Subject: Re: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 May 2012 09:44:18 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0C30_01CD3E51.23B092E0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, There seems to be a thread on this at http://www.ietf.org/mail-archive/web/ipv6/current/thrd2.html#15124 It looks like there was some form of agreement on the 6man list (where I suppose the discussion belonged). There was also a related thread on the Roll list at http://www.ietf.org/mail-archive/web/roll/current/msg06579.html Adrian From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Tecuceanu Andreea-Dana-B10623 Sent: 30 May 2012 09:58 To: roll@ietf.org Subject: [Roll] RPLInstanceID parameter from Source Routing Header is missing in RFC6554 Hello, I have observed that the RPLInstanceID field from Source Routing header (present in draft-ietf-6man-rpl-routing-header-07) was removed in RFC6554. Are there particular reasons for this? This field is necessary at the DODAG Root when it receives a Destination Unreachable with code "Error in Source Routing Header" to identify the instance with the problem (only if there are two instances with the same prefix and if the node is Root in both of them). Andreea Tecuceanu (Freescale Semiconductor) ------=_NextPart_000_0C30_01CD3E51.23B092E0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

There seems to be a = thread on this at = http://www.ietf.org/mail-archive/web/ipv6/current/thrd2.html#15124

 

It looks like there = was some form of agreement on the 6man list (where I suppose the = discussion belonged).

 

There was also a = related thread on the Roll list at = http://www.ietf.org/mail-archive/web/roll/current/msg06579.html

 

Adrian

 

From: = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Tecuceanu Andreea-Dana-B10623
Sent: 30 May 2012 = 09:58
To: roll@ietf.org
Subject: [Roll] = RPLInstanceID parameter from Source Routing Header is missing in = RFC6554

 

Hello,

 

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

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

 <= /p>

 

Andreea Tecuceanu
(Freescale Semiconductor)

=
------=_NextPart_000_0C30_01CD3E51.23B092E0--