From wwwrun@core3.amsl.com Fri Jul 23 09:47:21 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 775303A69F0; Fri, 23 Jul 2010 09:47:18 -0700 (PDT) To: pthubert@cisco.com,wintert@acm.org,rpl-authors@external.cisco.com From: IETF Secretariat Message-Id: <20100723164718.775303A69F0@core3.amsl.com> Date: Fri, 23 Jul 2010 09:47:18 -0700 (PDT) X-Mailman-Approved-At: Sun, 01 Aug 2010 14:06:25 -0700 Cc: culler@eecs.berkeley.edu, roll@ietf.org, adrian.farrel@huawei.com, ipr-announce@ietf.org Subject: [Roll] IPR Disclosure: Certicom Corp.'s Statement of IPR claimed in draft-ietf-roll-rpl-10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 16:47:21 -0000 Dear Pascal Thubert, Tim Winter, ROLL Team: An IPR disclosure that pertains to your Internet-Draft entitled "RPL: IPv6 Routing Protocol for Low power and Lossy Networks" (draft-ietf-roll-rpl) was submitted to the IETF Secretariat on 2010-07-21 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1366/). The title of the IPR disclosure is "Certicom Corp.'s Statement of IPR claimed in draft-ietf-roll-rpl-10." The IETF Secretariat From alexandru.petrescu@gmail.com Mon Aug 2 01:01:05 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02D973A6863 for ; Mon, 2 Aug 2010 01:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.143 X-Spam-Level: X-Spam-Status: No, score=-2.143 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0fXnAO92ocy for ; Mon, 2 Aug 2010 01:01:03 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id D48073A6AC2 for ; Mon, 2 Aug 2010 01:01:00 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o7281Nsm023288 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Aug 2010 10:01:24 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o7281NKb020019; Mon, 2 Aug 2010 10:01:23 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o7281Mpf017763; Mon, 2 Aug 2010 10:01:23 +0200 Message-ID: <4C567B53.302@gmail.com> Date: Mon, 02 Aug 2010 10:01:23 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: JP Vasseur References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> <4C543BB7.4010200@gmail.com> <2815B6B7-1F49-4AA5-9509-A82C9695FAB0@cisco.com> In-Reply-To: <2815B6B7-1F49-4AA5-9509-A82C9695FAB0@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Status change on Trickle I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 08:01:06 -0000 Le 31/07/2010 22:40, JP Vasseur a écrit : > > On Jul 31, 2010, at 5:05 PM, Alexandru Petrescu wrote: > >> Le 30/07/2010 22:54, JP Vasseur a écrit : >>> >>> On Jul 30, 2010, at 2:09 PM, Pascal Thubert (pthubert) wrote: >>> >>>> Alex: >>>> >>>> We need to be very clear that the WG is chartered for Standard >>>> Track, not Informational. So RPL is and will stay on that >>>> track. >>> >>> That's correct. >>> >>>> Moving Trickle to standard track is a good move, highly >>>> deserved for a method that's well understood and proven, and I >>>> support it 100%. >>>> >>> >>> As a WG LC, I do favor to have the trickle ID move to Std track >>> too. >> >> Would Trickle Stds Track mean it is mandatory in order to implement >> RPL? >> > > If you want Alex I can give you a call and explain the process next > week. In a nutshell, Trickle is a normative reference (answer to your > question is of course "yes") and RPL is std track according to our > charter. Now we can either have the trickle ID be an informative ref > in which case we have what we call a downref or simply move trickle > to Std track. Ok. If Trickle is put as Informative reference in RPL - will we still have a 'downref' problem? I don't think so. I think a downref/downward problem appears only when the referred document is already StdsTrack, and problem be solved by simply annotating as 'lower maturity'. > For the process in general, let me know if you need more pointers to > understand the process. Yes, please send in. I am only aware of RFC4897 "Handling Normative References to Standards-Track Documents". Alex > > Thanks. > > JP. > >> Alex >> >>> >>> JP. >>> >>>> Safe trip back, >>>> >>>> Pascal >>>> >>>>> -----Original Message----- From: roll-bounces@ietf.org >>>>> [mailto:roll-bounces@ietf.org] On Behalf >>>> Of >>>>> Alexandru Petrescu Sent: Friday, July 30, 2010 8:19 AM To: >>>>> roll@ietf.org Subject: [Roll] Status change on Trickle I-D >>>>> (was: Draft ROLL WG minutesposted) >>>>> >>>>>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02 >>>>>> (Phil - 5mn) [160] Quick update on the changes in -02. >>>>>> Currently in LC. >>>>>> >>>>>> JP> ID is a normative reference in RPL core spec (thus we >>>>>> have a downref). Discussion on ID status JP> Will come back >>>>>> to the list to consider status change (informational to >>>>>> standard track) >>>>> >>>>> Just a quick note to consider more ways to solve this >>>>> problem (RPL >>>> spec >>>>> 'downref'erencing a draft it fully relies on): >>>>> >>>>> -move draft-ietf-roll-trickle in the Informative References >>>>> section. This implies making Trickle parameters less >>>>> mandatory in RPL. -change the track of the base spec to >>>>> Informational (this implies >>>> change to >>>>> communication to SDO requiring this RP, I suppose). >>>>> >>>>> Also worth mentioning the use of BCP tag on the Trickle >>>>> draft... >>>> Trickle being >>>>> common practice in widespread use yet not really a protocol >>>>> (timer management). >>>>> >>>>> These may have already been considered, >>>>> >>>>> Alex _______________________________________________ Roll >>>>> mailing list Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>> _______________________________________________ Roll mailing >>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >>> >> > > From jpv@cisco.com Mon Aug 2 01:19:23 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81BA3A6AD3 for ; Mon, 2 Aug 2010 01:19:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSd0l6T+H+Ss for ; Mon, 2 Aug 2010 01:19:23 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C75CE3A6ACC for ; Mon, 2 Aug 2010 01:19:22 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABocVkytJV2a/2dsb2JhbACgDnGkVZo4hTkEiH+CPgwB X-IronPort-AV: E=Sophos;i="4.55,302,1278288000"; d="scan'208";a="142188976" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 02 Aug 2010 08:19:49 +0000 Received: from xbh-rcd-301.cisco.com (xbh-rcd-301.cisco.com [72.163.63.8]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o728Jncg026903; Mon, 2 Aug 2010 08:19:49 GMT Received: from xfe-rcd-201.cisco.com ([72.163.62.204]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Aug 2010 03:19:49 -0500 Received: from [192.168.1.10] ([10.82.242.249]) by xfe-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Aug 2010 03:19:49 -0500 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C567B53.302@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Aug 2010 10:19:47 +0200 References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> <4C543BB7.4010200@gmail.com> <2815B6B7-1F49-4AA5-9509-A82C9695FAB0@cisco.com> <4C567B53.302@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 02 Aug 2010 08:19:49.0239 (UTC) FILETIME=[79657870:01CB321B] Cc: ROLL WG Subject: Re: [Roll] Status change on Trickle I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 08:19:24 -0000 Hi Alex, OK I'll try to call you to explain ... If Trickle moves to Std track, the problem is solved. Otherwise, we =20 have a downref issue, which is solvable. Can you simply say what you would lean toward for the trickle ID ? Informational Standard Thanks. JP. On Aug 2, 2010, at 10:01 AM, Alexandru Petrescu wrote: > Le 31/07/2010 22:40, JP Vasseur a =E9crit : >> >> On Jul 31, 2010, at 5:05 PM, Alexandru Petrescu wrote: >> >>> Le 30/07/2010 22:54, JP Vasseur a =E9crit : >>>> >>>> On Jul 30, 2010, at 2:09 PM, Pascal Thubert (pthubert) wrote: >>>> >>>>> Alex: >>>>> >>>>> We need to be very clear that the WG is chartered for Standard >>>>> Track, not Informational. So RPL is and will stay on that >>>>> track. >>>> >>>> That's correct. >>>> >>>>> Moving Trickle to standard track is a good move, highly >>>>> deserved for a method that's well understood and proven, and I >>>>> support it 100%. >>>>> >>>> >>>> As a WG LC, I do favor to have the trickle ID move to Std track >>>> too. >>> >>> Would Trickle Stds Track mean it is mandatory in order to implement >>> RPL? >>> >> >> If you want Alex I can give you a call and explain the process next >> week. In a nutshell, Trickle is a normative reference (answer to your >> question is of course "yes") and RPL is std track according to our >> charter. Now we can either have the trickle ID be an informative ref >> in which case we have what we call a downref or simply move trickle >> to Std track. > > Ok. If Trickle is put as Informative reference in RPL - will we still > have a 'downref' problem? I don't think so. > > I think a downref/downward problem appears only when the referred > document is already StdsTrack, and problem be solved by simply > annotating as 'lower maturity'. > >> For the process in general, let me know if you need more pointers to >> understand the process. > > Yes, please send in. I am only aware of RFC4897 "Handling Normative > References to Standards-Track Documents". > > Alex > > >> >> Thanks. >> >> JP. >> >>> Alex >>> >>>> >>>> JP. >>>> >>>>> Safe trip back, >>>>> >>>>> Pascal >>>>> >>>>>> -----Original Message----- From: roll-bounces@ietf.org >>>>>> [mailto:roll-bounces@ietf.org] On Behalf >>>>> Of >>>>>> Alexandru Petrescu Sent: Friday, July 30, 2010 8:19 AM To: >>>>>> roll@ietf.org Subject: [Roll] Status change on Trickle I-D >>>>>> (was: Draft ROLL WG minutesposted) >>>>>> >>>>>>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02 >>>>>>> (Phil - 5mn) [160] Quick update on the changes in -02. >>>>>>> Currently in LC. >>>>>>> >>>>>>> JP> ID is a normative reference in RPL core spec (thus we >>>>>>> have a downref). Discussion on ID status JP> Will come back >>>>>>> to the list to consider status change (informational to >>>>>>> standard track) >>>>>> >>>>>> Just a quick note to consider more ways to solve this >>>>>> problem (RPL >>>>> spec >>>>>> 'downref'erencing a draft it fully relies on): >>>>>> >>>>>> -move draft-ietf-roll-trickle in the Informative References >>>>>> section. This implies making Trickle parameters less >>>>>> mandatory in RPL. -change the track of the base spec to >>>>>> Informational (this implies >>>>> change to >>>>>> communication to SDO requiring this RP, I suppose). >>>>>> >>>>>> Also worth mentioning the use of BCP tag on the Trickle >>>>>> draft... >>>>> Trickle being >>>>>> common practice in widespread use yet not really a protocol >>>>>> (timer management). >>>>>> >>>>>> These may have already been considered, >>>>>> >>>>>> Alex _______________________________________________ Roll >>>>>> mailing list Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>> _______________________________________________ Roll mailing >>>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>>> >>>> >>> >> >> > > From jpv@cisco.com Mon Aug 2 01:26:16 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FE713A695D for ; Mon, 2 Aug 2010 01:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.154 X-Spam-Level: X-Spam-Status: No, score=-10.154 tagged_above=-999 required=5 tests=[AWL=0.444, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMDDPSk1OWwr for ; Mon, 2 Aug 2010 01:26:14 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0FC933A6AF5 for ; Mon, 2 Aug 2010 01:26:13 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjoFALodVkytJV2Y/2dsb2JhbACBRJgMhj5xpD+aOIU5BIh/gj4MAQ X-IronPort-AV: E=Sophos;i="4.55,302,1278288000"; d="scan'208,217";a="142143386" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-1.cisco.com with ESMTP; 02 Aug 2010 08:26:40 +0000 Received: from xbh-rcd-302.cisco.com (xbh-rcd-302.cisco.com [72.163.63.9]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o728Qeik000687 for ; Mon, 2 Aug 2010 08:26:40 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-302.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Aug 2010 03:26:40 -0500 Received: from [192.168.1.10] ([10.82.242.249]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Aug 2010 03:26:39 -0500 Message-Id: <85BBD155-1DFB-4F11-B634-2FB055FF363A@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-4--364795922 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Aug 2010 10:26:38 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 02 Aug 2010 08:26:39.0583 (UTC) FILETIME=[6DFAFEF0:01CB321C] Subject: [Roll] ALL *** Status change on Trickle I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 08:26:16 -0000 --Apple-Mail-4--364795922 Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Dear all, Several of you expressed their preferences already. Others could you =20 please chime in ? (a) Move Trickle on Std track (which as I explained in other emails =20 sorts out the downref issue) - 4 in Favor so far (b) Keep it on the Informational Track Thanks. JP. Begin forwarded message: > From: JP Vasseur > Date: August 2, 2010 10:19:47 AM CEDT > To: Alexandru Petrescu > Cc: ROLL WG > Subject: Re: [Roll] Status change on Trickle I-D > > Hi Alex, > > OK I'll try to call you to explain ... > > If Trickle moves to Std track, the problem is solved. Otherwise, we =20= > have a downref issue, which > is solvable. > > Can you simply say what you would lean toward for the trickle ID ? > Informational > Standard > > Thanks. > > JP. > > On Aug 2, 2010, at 10:01 AM, Alexandru Petrescu wrote: > >> Le 31/07/2010 22:40, JP Vasseur a =E9crit : >>> >>> On Jul 31, 2010, at 5:05 PM, Alexandru Petrescu wrote: >>> >>>> Le 30/07/2010 22:54, JP Vasseur a =E9crit : >>>>> >>>>> On Jul 30, 2010, at 2:09 PM, Pascal Thubert (pthubert) wrote: >>>>> >>>>>> Alex: >>>>>> >>>>>> We need to be very clear that the WG is chartered for Standard >>>>>> Track, not Informational. So RPL is and will stay on that >>>>>> track. >>>>> >>>>> That's correct. >>>>> >>>>>> Moving Trickle to standard track is a good move, highly >>>>>> deserved for a method that's well understood and proven, and I >>>>>> support it 100%. >>>>>> >>>>> >>>>> As a WG LC, I do favor to have the trickle ID move to Std track >>>>> too. >>>> >>>> Would Trickle Stds Track mean it is mandatory in order to implement >>>> RPL? >>>> >>> >>> If you want Alex I can give you a call and explain the process next >>> week. In a nutshell, Trickle is a normative reference (answer to =20 >>> your >>> question is of course "yes") and RPL is std track according to our >>> charter. Now we can either have the trickle ID be an informative ref >>> in which case we have what we call a downref or simply move trickle >>> to Std track. >> >> Ok. If Trickle is put as Informative reference in RPL - will we =20 >> still >> have a 'downref' problem? I don't think so. >> >> I think a downref/downward problem appears only when the referred >> document is already StdsTrack, and problem be solved by simply >> annotating as 'lower maturity'. >> >>> For the process in general, let me know if you need more pointers to >>> understand the process. >> >> Yes, please send in. I am only aware of RFC4897 "Handling Normative >> References to Standards-Track Documents". >> >> Alex >> >> >>> >>> Thanks. >>> >>> JP. >>> >>>> Alex >>>> >>>>> >>>>> JP. >>>>> >>>>>> Safe trip back, >>>>>> >>>>>> Pascal >>>>>> >>>>>>> -----Original Message----- From: roll-bounces@ietf.org >>>>>>> [mailto:roll-bounces@ietf.org] On Behalf >>>>>> Of >>>>>>> Alexandru Petrescu Sent: Friday, July 30, 2010 8:19 AM To: >>>>>>> roll@ietf.org Subject: [Roll] Status change on Trickle I-D >>>>>>> (was: Draft ROLL WG minutesposted) >>>>>>> >>>>>>>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02 >>>>>>>> (Phil - 5mn) [160] Quick update on the changes in -02. >>>>>>>> Currently in LC. >>>>>>>> >>>>>>>> JP> ID is a normative reference in RPL core spec (thus we >>>>>>>> have a downref). Discussion on ID status JP> Will come back >>>>>>>> to the list to consider status change (informational to >>>>>>>> standard track) >>>>>>> >>>>>>> Just a quick note to consider more ways to solve this >>>>>>> problem (RPL >>>>>> spec >>>>>>> 'downref'erencing a draft it fully relies on): >>>>>>> >>>>>>> -move draft-ietf-roll-trickle in the Informative References >>>>>>> section. This implies making Trickle parameters less >>>>>>> mandatory in RPL. -change the track of the base spec to >>>>>>> Informational (this implies >>>>>> change to >>>>>>> communication to SDO requiring this RP, I suppose). >>>>>>> >>>>>>> Also worth mentioning the use of BCP tag on the Trickle >>>>>>> draft... >>>>>> Trickle being >>>>>>> common practice in widespread use yet not really a protocol >>>>>>> (timer management). >>>>>>> >>>>>>> These may have already been considered, >>>>>>> >>>>>>> Alex _______________________________________________ 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 --Apple-Mail-4--364795922 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear = all,

Several of you expressed their preferences = already. Others could you please chime in ?
(a) Move Trickle = on Std track (which as I explained in other emails sorts out the downref = issue) - 4 in Favor so far
(b) Keep it on the = Informational = Track

Thanks.

JP.
<= div>

Begin forwarded message:

From: = JP Vasseur <jpv@cisco.com>
Date: = August 2, 2010 10:19:47 AM CEDT
To: Alexandru = Petrescu <alexandru.petrescu@gmail.com<= /a>>
Subject: = Re: [Roll] Status change on Trickle = I-D

=
Hi Alex,

OK I'll try to call you to explain = ...

If Trickle moves to Std track, the problem is solved. = Otherwise, we have a downref issue, which
is solvable.

Can you = simply say what you would lean toward for the trickle ID ?
= Informational
= Standard

Thanks.

JP.

On Aug 2, 2010, at = 10:01 AM, Alexandru Petrescu wrote:

Le = 31/07/2010 22:40, JP Vasseur a =E9crit :

On Jul 31, 2010, at 5:05 PM, = Alexandru Petrescu wrote:

Le = 30/07/2010 22:54, JP Vasseur a =E9crit = :

On Jul 30, 2010, at 2:09 PM, = Pascal Thubert (pthubert) = wrote:

Alex:

We = need to be very clear that the WG is chartered for = Standard
Track, = not Informational. So RPL is and will stay on = that
<= blockquote type=3D"cite">
track.

That's = correct.

Moving = Trickle to standard track is a good move, = highly
deserved= for a method that's well understood and proven, and = I
support = it = 100%.
=


As a WG LC, I do favor to have = the trickle ID move to Std = track
too.
=

Would = Trickle Stds Track mean it is mandatory in order to = implement
RPL?


If you want Alex I can give you = a call and explain the process = next
week. In a nutshell, Trickle is a normative reference = (answer to your
question is of course "yes") and = RPL is std track according to = our
charter. Now we can either have the trickle ID be an = informative ref
in which case we have what we = call a downref or simply move = trickle
to Std track.

Ok.  If = Trickle is put as Informative reference in RPL - will we = still
have a 'downref' = problem?  I don't think so.

I think a = downref/downward problem appears only when the = referred
document is already = StdsTrack, and problem be solved by simply
annotating as 'lower = maturity'.

For the process in general, let me know if you need more = pointers to
understand the = process.

Yes, please = send in.  I am only aware of RFC4897 "Handling = Normative
References to = Standards-Track Documents".

Alex



Thanks.

JP.

Alex


JP.
<= blockquote type=3D"cite">

Safe = trip = back,
=

Pascal

-----Original Message----- From: = roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] = On = Behalf
Of
Alexandru Petrescu Sent: Friday, = July 30, 2010 8:19 AM = To:
roll@ietf.org Subject: [Roll] Status = change on Trickle = I-D
(was: Draft ROLL WG = minutesposted)

5) The Trickle Algorithm - = draft-levis-roll-trickle-02
(Phil = - 5mn) [160] Quick update on the changes in = -02.
<= /blockquote>
Currently in = LC.

JP> ID is a normative = reference in RPL core spec (thus = we
have a downref). Discussion on = ID status JP> Will come = back
<= /blockquote>
to the list to consider status = change (informational = to
standard = track)

Just a = quick note to consider more ways to solve = this
<= /blockquote>
problem = (RPL
<= /blockquote>
spec
=
'downref'erencing a draft it fully relies = on):
<= /blockquote>

-move = draft-ietf-roll-trickle in the Informative = References
section.= This implies making Trickle parameters = less
<= /blockquote>
mandatory in RPL. -change the track of the base spec = to
Informational (this = implies
change = to
communication to SDO requiring = this RP, I = suppose).

Also = worth mentioning the use of BCP tag on the = Trickle
draft...
Trickle = being
=
common practice in widespread = use yet not really a = protocol
(timer = management).

These = may have already been = considered,

Alex = _______________________________________________ = Roll
<= /blockquote>
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-4--364795922-- From alexandru.petrescu@gmail.com Mon Aug 2 02:09:43 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 767383A6B34 for ; Mon, 2 Aug 2010 02:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.15 X-Spam-Level: X-Spam-Status: No, score=-2.15 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ozGtOqjeJFY for ; Mon, 2 Aug 2010 02:09:42 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 2BFD33A6ACB for ; Mon, 2 Aug 2010 02:09:42 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o729A5Vk017574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Aug 2010 11:10:05 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o729A5fC009712; Mon, 2 Aug 2010 11:10:05 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o729A4dT012858; Mon, 2 Aug 2010 11:10:05 +0200 Message-ID: <4C568B6C.5070501@gmail.com> Date: Mon, 02 Aug 2010 11:10:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: JP Vasseur References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> <4C543BB7.4010200@gmail.com> <2815B6B7-1F49-4AA5-9509-A82C9695FAB0@cisco.com> <4C567B53.302@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Status change on Trickle I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 09:09:43 -0000 Le 02/08/2010 10:19, JP Vasseur a écrit : > Hi Alex, > > OK I'll try to call you to explain ... > > If Trickle moves to Std track, the problem is solved. I think if one puts Trickle on Stds Track then there should be a note in RPL saying Trickle is "lower maturity", as RFC4897 recommends. > Otherwise, we have a downref issue, No, you have a downref (or downward) issue _only_ if you put Trickle on Stds Track. If you keep Trickle on INFORMATIONAL, and make the reference "Informative" then you have no problem. If you keep Trickle on INFORMATIONAL and keep Trickle referred as "Normative Reference" then you simply have a wrong document, not necessarily a "downref". It becomes a downref or downward problem when you put it on StdsTrack. > which is solvable. There exist a solution to the downref problem. But here we don't have a downref problem, I believe. You are about to transform the "wrong document" problem (Normative reference pointing to an INFORMATIONAL document) into a downref problem. Alex > Can you simply say what you would lean toward for the trickle ID ? > Informational Standard > > Thanks. > > JP. > > On Aug 2, 2010, at 10:01 AM, Alexandru Petrescu wrote: > >> Le 31/07/2010 22:40, JP Vasseur a écrit : >>> >>> On Jul 31, 2010, at 5:05 PM, Alexandru Petrescu wrote: >>> >>>> Le 30/07/2010 22:54, JP Vasseur a écrit : >>>>> >>>>> On Jul 30, 2010, at 2:09 PM, Pascal Thubert (pthubert) >>>>> wrote: >>>>> >>>>>> Alex: >>>>>> >>>>>> We need to be very clear that the WG is chartered for >>>>>> Standard Track, not Informational. So RPL is and will stay >>>>>> on that track. >>>>> >>>>> That's correct. >>>>> >>>>>> Moving Trickle to standard track is a good move, highly >>>>>> deserved for a method that's well understood and proven, >>>>>> and I support it 100%. >>>>>> >>>>> >>>>> As a WG LC, I do favor to have the trickle ID move to Std >>>>> track too. >>>> >>>> Would Trickle Stds Track mean it is mandatory in order to >>>> implement RPL? >>>> >>> >>> If you want Alex I can give you a call and explain the process >>> next week. In a nutshell, Trickle is a normative reference >>> (answer to your question is of course "yes") and RPL is std track >>> according to our charter. Now we can either have the trickle ID >>> be an informative ref in which case we have what we call a >>> downref or simply move trickle to Std track. >> >> Ok. If Trickle is put as Informative reference in RPL - will we >> still have a 'downref' problem? I don't think so. >> >> I think a downref/downward problem appears only when the referred >> document is already StdsTrack, and problem be solved by simply >> annotating as 'lower maturity'. >> >>> For the process in general, let me know if you need more pointers >>> to understand the process. >> >> Yes, please send in. I am only aware of RFC4897 "Handling >> Normative References to Standards-Track Documents". >> >> Alex >> >> >>> >>> Thanks. >>> >>> JP. >>> >>>> Alex >>>> >>>>> >>>>> JP. >>>>> >>>>>> Safe trip back, >>>>>> >>>>>> Pascal >>>>>> >>>>>>> -----Original Message----- From: roll-bounces@ietf.org >>>>>>> [mailto:roll-bounces@ietf.org] On Behalf >>>>>> Of >>>>>>> Alexandru Petrescu Sent: Friday, July 30, 2010 8:19 AM >>>>>>> To: roll@ietf.org Subject: [Roll] Status change on >>>>>>> Trickle I-D (was: Draft ROLL WG minutesposted) >>>>>>> >>>>>>>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02 >>>>>>>> (Phil - 5mn) [160] Quick update on the changes in -02. >>>>>>>> Currently in LC. >>>>>>>> >>>>>>>> JP> ID is a normative reference in RPL core spec (thus >>>>>>>> we have a downref). Discussion on ID status JP> Will >>>>>>>> come back to the list to consider status change >>>>>>>> (informational to standard track) >>>>>>> >>>>>>> Just a quick note to consider more ways to solve this >>>>>>> problem (RPL >>>>>> spec >>>>>>> 'downref'erencing a draft it fully relies on): >>>>>>> >>>>>>> -move draft-ietf-roll-trickle in the Informative >>>>>>> References section. This implies making Trickle >>>>>>> parameters less mandatory in RPL. -change the track of >>>>>>> the base spec to Informational (this implies >>>>>> change to >>>>>>> communication to SDO requiring this RP, I suppose). >>>>>>> >>>>>>> Also worth mentioning the use of BCP tag on the Trickle >>>>>>> draft... >>>>>> Trickle being >>>>>>> common practice in widespread use yet not really a >>>>>>> protocol (timer management). >>>>>>> >>>>>>> These may have already been considered, >>>>>>> >>>>>>> Alex _______________________________________________ >>>>>>> Roll mailing list Roll@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>> _______________________________________________ Roll >>>>>> mailing list Roll@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>> >>>>> >>>> >>> >>> >> >> > > From jpv@cisco.com Mon Aug 2 03:35:12 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 370B43A6BAB for ; Mon, 2 Aug 2010 03:35:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.235 X-Spam-Level: X-Spam-Status: No, score=-10.235 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoqR9dqE1yqX for ; Mon, 2 Aug 2010 03:34:53 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 6531B3A6A6F for ; Mon, 2 Aug 2010 03:34:09 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAMo7VkytJV2a/2dsb2JhbACgDXGkJ5pahTkEiH+CPgwB X-IronPort-AV: E=Sophos;i="4.55,302,1278288000"; d="scan'208";a="142233167" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-2.cisco.com with ESMTP; 02 Aug 2010 10:33:53 +0000 Received: from xbh-rcd-102.cisco.com (xbh-rcd-102.cisco.com [72.163.62.139]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id o72AXrwD022045; Mon, 2 Aug 2010 10:33:53 GMT Received: from xfe-rcd-101.cisco.com ([72.163.62.136]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Aug 2010 05:33:53 -0500 Received: from [192.168.1.10] ([10.82.242.249]) by xfe-rcd-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Aug 2010 05:33:52 -0500 Message-Id: <93B5CDDF-35A8-4667-BACC-0442749905C1@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C568B6C.5070501@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 2 Aug 2010 12:33:50 +0200 References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> <4C543BB7.4010200@gmail.com> <2815B6B7-1F49-4AA5-9509-A82C9695FAB0@cisco.com> <4C567B53.302@gmail.com> <4C568B6C.5070501@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 02 Aug 2010 10:33:52.0197 (UTC) FILETIME=[335F7750:01CB322E] Cc: ROLL WG Subject: Re: [Roll] Status change on Trickle I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 10:35:13 -0000 On Aug 2, 2010, at 11:10 AM, Alexandru Petrescu wrote: > Le 02/08/2010 10:19, JP Vasseur a =E9crit : >> Hi Alex, >> >> OK I'll try to call you to explain ... >> >> If Trickle moves to Std track, the problem is solved. > > I think if one puts Trickle on Stds Track then there should be a > note in RPL saying Trickle is "lower maturity", as RFC4897 recommends. > >> Otherwise, we have a downref issue, > > No, you have a downref (or downward) issue _only_ if you put Trickle =20= > on > Stds Track. If you keep Trickle on INFORMATIONAL, and make the > reference "Informative" then you have no problem. > > If you keep Trickle on INFORMATIONAL and keep Trickle referred as > "Normative Reference" then you simply have a wrong document, not > necessarily a "downref". It becomes a downref or downward problem =20 > when > you put it on StdsTrack. =3D> Alex you keep mis-understanding. Again I propose to try to call you = =20 and explain. Trickle is a normative reference for RPL, there is no question about =20 (co-chair hat on, see your AD too if you need a confirmation). For the process, I'll try to call you and explain. Feel free to tell =20 us if you are OK to move trickle to Std. JP. > >> which is solvable. > > There exist a solution to the downref problem. > > But here we don't have a downref problem, I believe. You are about to > transform the "wrong document" problem (Normative reference pointing =20= > to > an INFORMATIONAL document) into a downref problem. > > Alex > >> Can you simply say what you would lean toward for the trickle ID ? >> Informational Standard >> >> Thanks. >> >> JP. >> >> On Aug 2, 2010, at 10:01 AM, Alexandru Petrescu wrote: >> >>> Le 31/07/2010 22:40, JP Vasseur a =E9crit : >>>> >>>> On Jul 31, 2010, at 5:05 PM, Alexandru Petrescu wrote: >>>> >>>>> Le 30/07/2010 22:54, JP Vasseur a =E9crit : >>>>>> >>>>>> On Jul 30, 2010, at 2:09 PM, Pascal Thubert (pthubert) >>>>>> wrote: >>>>>> >>>>>>> Alex: >>>>>>> >>>>>>> We need to be very clear that the WG is chartered for >>>>>>> Standard Track, not Informational. So RPL is and will stay >>>>>>> on that track. >>>>>> >>>>>> That's correct. >>>>>> >>>>>>> Moving Trickle to standard track is a good move, highly >>>>>>> deserved for a method that's well understood and proven, >>>>>>> and I support it 100%. >>>>>>> >>>>>> >>>>>> As a WG LC, I do favor to have the trickle ID move to Std >>>>>> track too. >>>>> >>>>> Would Trickle Stds Track mean it is mandatory in order to >>>>> implement RPL? >>>>> >>>> >>>> If you want Alex I can give you a call and explain the process >>>> next week. In a nutshell, Trickle is a normative reference >>>> (answer to your question is of course "yes") and RPL is std track >>>> according to our charter. Now we can either have the trickle ID >>>> be an informative ref in which case we have what we call a >>>> downref or simply move trickle to Std track. >>> >>> Ok. If Trickle is put as Informative reference in RPL - will we >>> still have a 'downref' problem? I don't think so. >>> >>> I think a downref/downward problem appears only when the referred >>> document is already StdsTrack, and problem be solved by simply >>> annotating as 'lower maturity'. >>> >>>> For the process in general, let me know if you need more pointers >>>> to understand the process. >>> >>> Yes, please send in. I am only aware of RFC4897 "Handling >>> Normative References to Standards-Track Documents". >>> >>> Alex >>> >>> >>>> >>>> Thanks. >>>> >>>> JP. >>>> >>>>> Alex >>>>> >>>>>> >>>>>> JP. >>>>>> >>>>>>> Safe trip back, >>>>>>> >>>>>>> Pascal >>>>>>> >>>>>>>> -----Original Message----- From: roll-bounces@ietf.org >>>>>>>> [mailto:roll-bounces@ietf.org] On Behalf >>>>>>> Of >>>>>>>> Alexandru Petrescu Sent: Friday, July 30, 2010 8:19 AM >>>>>>>> To: roll@ietf.org Subject: [Roll] Status change on >>>>>>>> Trickle I-D (was: Draft ROLL WG minutesposted) >>>>>>>> >>>>>>>>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02 >>>>>>>>> (Phil - 5mn) [160] Quick update on the changes in -02. >>>>>>>>> Currently in LC. >>>>>>>>> >>>>>>>>> JP> ID is a normative reference in RPL core spec (thus >>>>>>>>> we have a downref). Discussion on ID status JP> Will >>>>>>>>> come back to the list to consider status change >>>>>>>>> (informational to standard track) >>>>>>>> >>>>>>>> Just a quick note to consider more ways to solve this >>>>>>>> problem (RPL >>>>>>> spec >>>>>>>> 'downref'erencing a draft it fully relies on): >>>>>>>> >>>>>>>> -move draft-ietf-roll-trickle in the Informative >>>>>>>> References section. This implies making Trickle >>>>>>>> parameters less mandatory in RPL. -change the track of >>>>>>>> the base spec to Informational (this implies >>>>>>> change to >>>>>>>> communication to SDO requiring this RP, I suppose). >>>>>>>> >>>>>>>> Also worth mentioning the use of BCP tag on the Trickle >>>>>>>> draft... >>>>>>> Trickle being >>>>>>>> common practice in widespread use yet not really a >>>>>>>> protocol (timer management). >>>>>>>> >>>>>>>> These may have already been considered, >>>>>>>> >>>>>>>> Alex _______________________________________________ >>>>>>>> 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 alexandru.petrescu@gmail.com Mon Aug 2 04:54:23 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F6B43A6BE2 for ; Mon, 2 Aug 2010 04:54:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.152 X-Spam-Level: X-Spam-Status: No, score=-2.152 tagged_above=-999 required=5 tests=[AWL=0.097, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ExMotDfN1xN for ; Mon, 2 Aug 2010 04:54:21 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 1E9DF3A6BAA for ; Mon, 2 Aug 2010 04:54:20 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o72BsiHS000958 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Aug 2010 13:54:44 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o72Bsiku006816; Mon, 2 Aug 2010 13:54:44 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o72Bshhe018241; Mon, 2 Aug 2010 13:54:44 +0200 Message-ID: <4C56B203.2080003@gmail.com> Date: Mon, 02 Aug 2010 13:54:43 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: JP Vasseur References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> <4C543BB7.4010200@gmail.com> <2815B6B7-1F49-4AA5-9509-A82C9695FAB0@cisco.com> <4C567B53.302@gmail.com> <4C568B6C.5070501@gmail.com> <93B5CDDF-35A8-4667-BACC-0442749905C1@cisco.com> In-Reply-To: <93B5CDDF-35A8-4667-BACC-0442749905C1@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Status change on Trickle I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 11:54:23 -0000 I think we misunderstand each other altogether because I rely on RFCs whereas you rely on the current thinking among Chairs, ADs - in which case my comments are just comments, see below. Le 02/08/2010 12:33, JP Vasseur a écrit : > > On Aug 2, 2010, at 11:10 AM, Alexandru Petrescu wrote: > >> Le 02/08/2010 10:19, JP Vasseur a écrit : >>> Hi Alex, >>> >>> OK I'll try to call you to explain ... >>> >>> If Trickle moves to Std track, the problem is solved. >> >> I think if one puts Trickle on Stds Track then there should be a >> note in RPL saying Trickle is "lower maturity", as RFC4897 >> recommends. >> >>> Otherwise, we have a downref issue, >> >> No, you have a downref (or downward) issue _only_ if you put >> Trickle on Stds Track. If you keep Trickle on INFORMATIONAL, and >> make the reference "Informative" then you have no problem. >> >> If you keep Trickle on INFORMATIONAL and keep Trickle referred as >> "Normative Reference" then you simply have a wrong document, not >> necessarily a "downref". It becomes a downref or downward problem >> when you put it on StdsTrack. > > => Alex you keep mis-understanding. Again I propose to try to call > you and explain. Trickle is a normative reference for RPL, there is > no question about (co-chair hat on, see your AD too if you need a > confirmation). > > For the process, I'll try to call you and explain. Feel free to tell > us if you are OK to move trickle to Std. Let me unfold the scenario showing that Trickle on StdsTrack may not be the best thing to do, by the interest (quick proceeding to IESG, mandatory Trickle offering great features). For example, you insist that because Trickle is referred to as Normative by RPL then we need to make it StdsTrack, such as to avoid 'downref' problem. This logic is contrary to RFC3967 which allows for INFORMATIVE Normative references; it says "There are a number of circumstances in which an IETF document may need to make a normative reference to a document at a lower maturity level [...] o A standards track document may need to refer to a protocol or algorithm developed by an external body but modified, adapted, or profiled by an IETF informational RFC [...]" [...] and especially this: " Once a specific down reference to a particular document has been accepted by the community (e.g., has been mentioned in several Last Calls), an Area Director may waive subsequent notices in the Last Call of down references to it." Do we accept the down reference? I do. Your question to the WG does not ask this acceptance, it rather asks "INFORMATIONAL vs StdsTrack", which is a poor indicator of whether we have accepted the downref or not, IMHO. Moreover - by that RFC, your problem (downref) could quickly be solved by an AD waiving subsequent notices in the LC of the down references (i.e. when the Trickle draft is LC'ed), and keeping Trickle as INFORMATIONAL. This is faster to IESG, IMHO. OTOH, ok, accept for a second we don't do Trickle INFORMATIONAL but Stds Track. Then we fall on RFC4897, by which one has to do the following: " An author or editor who requires a normative downward reference to a Standards-Track RFC uses the following very simple procedure: o The reference text (i.e., in the "Normative References" section of the source document) is written as usual. o A note is included in the reference text that indicates that the reference is to a target document of a lower maturity level, that some caution should be used since it may be less stable than the document from which it is being referenced, and, optionally, explaining why the downward reference is appropriate." I.e. you have to spin RPL draf-12, and you have to say Trickle is less mature than RPL. I do not know whether you agree with this intention, but that's what RFC4897 normally requires. If you agree with the intention - then I am fine, I will check later the RPL document see whether it says "Trickle less mature" somewhere. Again, these are non-blocking comments. You seem to have more people who need Trickle on the StdsTrack anyways, and I typically abide to consensus and Chairs' indications. (this discussion may interest the RPL HbH, RH drafts too, as it concerns Trickle in the same way). Alex > > JP. > >> >>> which is solvable. >> >> There exist a solution to the downref problem. >> >> But here we don't have a downref problem, I believe. You are about >> to transform the "wrong document" problem (Normative reference >> pointing to an INFORMATIONAL document) into a downref problem. >> >> Alex >> >>> Can you simply say what you would lean toward for the trickle ID >>> ? Informational Standard >>> >>> Thanks. >>> >>> JP. >>> >>> On Aug 2, 2010, at 10:01 AM, Alexandru Petrescu wrote: >>> >>>> Le 31/07/2010 22:40, JP Vasseur a écrit : >>>>> >>>>> On Jul 31, 2010, at 5:05 PM, Alexandru Petrescu wrote: >>>>> >>>>>> Le 30/07/2010 22:54, JP Vasseur a écrit : >>>>>>> >>>>>>> On Jul 30, 2010, at 2:09 PM, Pascal Thubert (pthubert) >>>>>>> wrote: >>>>>>> >>>>>>>> Alex: >>>>>>>> >>>>>>>> We need to be very clear that the WG is chartered for >>>>>>>> Standard Track, not Informational. So RPL is and will >>>>>>>> stay on that track. >>>>>>> >>>>>>> That's correct. >>>>>>> >>>>>>>> Moving Trickle to standard track is a good move, highly >>>>>>>> deserved for a method that's well understood and >>>>>>>> proven, and I support it 100%. >>>>>>>> >>>>>>> >>>>>>> As a WG LC, I do favor to have the trickle ID move to Std >>>>>>> track too. >>>>>> >>>>>> Would Trickle Stds Track mean it is mandatory in order to >>>>>> implement RPL? >>>>>> >>>>> >>>>> If you want Alex I can give you a call and explain the >>>>> process next week. In a nutshell, Trickle is a normative >>>>> reference (answer to your question is of course "yes") and >>>>> RPL is std track according to our charter. Now we can either >>>>> have the trickle ID be an informative ref in which case we >>>>> have what we call a downref or simply move trickle to Std >>>>> track. >>>> >>>> Ok. If Trickle is put as Informative reference in RPL - will we >>>> still have a 'downref' problem? I don't think so. >>>> >>>> I think a downref/downward problem appears only when the >>>> referred document is already StdsTrack, and problem be solved >>>> by simply annotating as 'lower maturity'. >>>> >>>>> For the process in general, let me know if you need more >>>>> pointers to understand the process. >>>> >>>> Yes, please send in. I am only aware of RFC4897 "Handling >>>> Normative References to Standards-Track Documents". >>>> >>>> Alex >>>> >>>> >>>>> >>>>> Thanks. >>>>> >>>>> JP. >>>>> >>>>>> Alex >>>>>> >>>>>>> >>>>>>> JP. >>>>>>> >>>>>>>> Safe trip back, >>>>>>>> >>>>>>>> Pascal >>>>>>>> >>>>>>>>> -----Original Message----- From: >>>>>>>>> roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] >>>>>>>>> On Behalf >>>>>>>> Of >>>>>>>>> Alexandru Petrescu Sent: Friday, July 30, 2010 8:19 >>>>>>>>> AM To: roll@ietf.org Subject: [Roll] Status change on >>>>>>>>> Trickle I-D (was: Draft ROLL WG minutesposted) >>>>>>>>> >>>>>>>>>> 5) The Trickle Algorithm - >>>>>>>>>> draft-levis-roll-trickle-02 (Phil - 5mn) [160] >>>>>>>>>> Quick update on the changes in -02. Currently in >>>>>>>>>> LC. >>>>>>>>>> >>>>>>>>>> JP> ID is a normative reference in RPL core spec >>>>>>>>>> (thus we have a downref). Discussion on ID status >>>>>>>>>> JP> Will come back to the list to consider status >>>>>>>>>> change (informational to standard track) >>>>>>>>> >>>>>>>>> Just a quick note to consider more ways to solve this >>>>>>>>> problem (RPL >>>>>>>> spec >>>>>>>>> 'downref'erencing a draft it fully relies on): >>>>>>>>> >>>>>>>>> -move draft-ietf-roll-trickle in the Informative >>>>>>>>> References section. This implies making Trickle >>>>>>>>> parameters less mandatory in RPL. -change the track >>>>>>>>> of the base spec to Informational (this implies >>>>>>>> change to >>>>>>>>> communication to SDO requiring this RP, I suppose). >>>>>>>>> >>>>>>>>> Also worth mentioning the use of BCP tag on the >>>>>>>>> Trickle draft... >>>>>>>> Trickle being >>>>>>>>> common practice in widespread use yet not really a >>>>>>>>> protocol (timer management). >>>>>>>>> >>>>>>>>> These may have already been considered, >>>>>>>>> >>>>>>>>> Alex _______________________________________________ >>>>>>>>> Roll mailing list Roll@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>>> _______________________________________________ Roll >>>>>>>> mailing list Roll@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/roll >>>>>>> >>>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > > From pal@cs.stanford.edu Mon Aug 2 07:25:12 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D813A3A6B54 for ; Mon, 2 Aug 2010 07:25:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E96erqGZ59wm for ; Mon, 2 Aug 2010 07:25:12 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 037B93A6A05 for ; Mon, 2 Aug 2010 07:25:12 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OfvxT-0008FS-Ia; Mon, 02 Aug 2010 07:25:39 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: <4C568B6C.5070501@gmail.com> Date: Mon, 2 Aug 2010 07:25:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> <4C543BB7.4010200@gmail.com> <2815B6B7-1F49-4AA5-9509-A82C9695FAB0@cisco.com> <4C567B53.302@gmail.com> <4C568B6C.5070501@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 72f97ea9660f372cf635c7c250d627db Cc: ROLL WG Subject: Re: [Roll] Status change on Trickle I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 14:25:12 -0000 On Aug 2, 2010, at 2:10 AM, Alexandru Petrescu wrote: > Le 02/08/2010 10:19, JP Vasseur a =E9crit : >> Hi Alex, >>=20 >> OK I'll try to call you to explain ... >>=20 >> If Trickle moves to Std track, the problem is solved. >=20 > I think if one puts Trickle on Stds Track then there should be a > note in RPL saying Trickle is "lower maturity", as RFC4897 recommends. >=20 >> Otherwise, we have a downref issue, >=20 > No, you have a downref (or downward) issue _only_ if you put Trickle = on > Stds Track. If you keep Trickle on INFORMATIONAL, and make the > reference "Informative" then you have no problem. >=20 > If you keep Trickle on INFORMATIONAL and keep Trickle referred as > "Normative Reference" then you simply have a wrong document, not > necessarily a "downref". It becomes a downref or downward problem = when > you put it on StdsTrack. >=20 >> which is solvable. >=20 > There exist a solution to the downref problem. >=20 > But here we don't have a downref problem, I believe. You are about to > transform the "wrong document" problem (Normative reference pointing = to > an INFORMATIONAL document) into a downref problem. It's worth noting that Trickle used to be part of the RPL draft. The WG = agreed that moving Trickle into a separate draft was a good idea because = it would allow simpler references in future drafts (e.g., Jonathan and = Richard's Trickle-based multicast). This happened in version -08. I am = amazed that my accidentally marking the draft as Informational (due to = being an IETF neophyte) could cause such a disagreement. A cursory reading of the draft text would show that Trickle is a = normative reference (Section 8.3 in -11). Changing fundamental technical = features of RPL for easily solved procedural reasons seems like terrible = engineering and design, IMHO. Phil= From alexandru.petrescu@gmail.com Mon Aug 2 08:27:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA99B3A67AE for ; Mon, 2 Aug 2010 08:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N23tz3pnML2w for ; Mon, 2 Aug 2010 08:27:01 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 80C123A6B8E for ; Mon, 2 Aug 2010 08:27:01 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o72FRJ4K011935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Aug 2010 17:27:19 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o72FRJRK025306; Mon, 2 Aug 2010 17:27:19 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o72FRIml015011; Mon, 2 Aug 2010 17:27:19 +0200 Message-ID: <4C56E3D6.7050305@gmail.com> Date: Mon, 02 Aug 2010 17:27:18 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Philip Levis References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> <4C543BB7.4010200@gmail.com> <2815B6B7-1F49-4AA5-9509-A82C9695FAB0@cisco.com> <4C567B53.302@gmail.com> <4C568B6C.5070501@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Status change on Trickle I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 15:27:02 -0000 Le 02/08/2010 16:25, Philip Levis a écrit : > > On Aug 2, 2010, at 2:10 AM, Alexandru Petrescu wrote: > >> Le 02/08/2010 10:19, JP Vasseur a écrit : >>> Hi Alex, >>> >>> OK I'll try to call you to explain ... >>> >>> If Trickle moves to Std track, the problem is solved. >> >> I think if one puts Trickle on Stds Track then there should be a >> note in RPL saying Trickle is "lower maturity", as RFC4897 >> recommends. >> >>> Otherwise, we have a downref issue, >> >> No, you have a downref (or downward) issue _only_ if you put >> Trickle on Stds Track. If you keep Trickle on INFORMATIONAL, and >> make the reference "Informative" then you have no problem. >> >> If you keep Trickle on INFORMATIONAL and keep Trickle referred as >> "Normative Reference" then you simply have a wrong document, not >> necessarily a "downref". It becomes a downref or downward problem >> when you put it on StdsTrack. >> >>> which is solvable. >> >> There exist a solution to the downref problem. >> >> But here we don't have a downref problem, I believe. You are about >> to transform the "wrong document" problem (Normative reference >> pointing to an INFORMATIONAL document) into a downref problem. > > It's worth noting that Trickle used to be part of the RPL draft. The > WG agreed that moving Trickle into a separate draft was a good idea > because it would allow simpler references in future drafts (e.g., > Jonathan and Richard's Trickle-based multicast). This happened in > version -08. I am amazed that my accidentally marking the draft as > Informational (due to being an IETF neophyte) could cause such a > disagreement. > > A cursory reading of the draft text would show that Trickle is a > normative reference (Section 8.3 in -11). Yes, Trickle I-D is a Normative reference in RPL -11. > Changing fundamental technical features of RPL for easily solved > procedural reasons seems like terrible engineering and design, IMHO. Philip: do you think RPL draft would go faster to IESG if Trickle Normative ref were on StdsTrack? I believe it would be slower than if it were INFORMATIONAL. (an LC for Trickle would be needed, etc.) IMHO Alex From ietf@thomasclausen.org Mon Aug 2 08:42:58 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C67D33A6899 for ; Mon, 2 Aug 2010 08:42:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgKukX+nlEZp for ; Mon, 2 Aug 2010 08:42:57 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id AEF5A3A68CD for ; Mon, 2 Aug 2010 08:42:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id A0E8D32280A0; Mon, 2 Aug 2010 08:43:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.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 hgblob.tigertech.net (Postfix) with ESMTPSA id B54373236DB2; Mon, 2 Aug 2010 08:43:24 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=iso-8859-1 From: Thomas Heide Clausen In-Reply-To: <4C56E3D6.7050305@gmail.com> Date: Mon, 2 Aug 2010 17:43:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <788B1A64-E953-47C5-9E84-74234AB5D425@thomasclausen.org> References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> <4C543BB7.4010200@gmail.com> <2815B6B7-1F49-4AA5-9509-A82C9695FAB0@cisco.com> <4C567B53.302@gmail.com> <4C568B6C.5070501@gmail.com> <4C56E3D6.7050305@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1078) Cc: ROLL WG Subject: Re: [Roll] Status change on Trickle I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 15:42:58 -0000 Dear Alex, 1) A downref is if a document has a normative reference to a = document at a lower maturity level, e.g. a std. track document referencing an experimental or = informational RFC normatively. =09 A "proposed standard" referencing another "proposed standard" is = not a downref, ever. =09 I believe that what the WG chairs were suggesting was for RPL = and TRICKLE to both be published as "proposed standard", i.e. no downref. 2) Observing what I have seen in the RTG area, most ADs have IETF = LCed also experimental and informational documents in the past years. This is a healthy = thing to do. I believe that, therefore, the choice of maturity level (exp., inf, PS, DS, ...) = would not impact the publication=20 timing. (In general, choosing the "maturity level" of the document based = on "how to publish it fast" would be a bad strategy). 3) I believe that it is not unheard of to move several documents = forward together, i.e. to WGLC, LC them together - if they have mutual reference, or if they = happen to be ready at the same time. In general, the IETF and even the IESG seems to be rather = good at multitasking, and it may even be an advantage to get both to review concurrently. 4) Downref's, as in the case where RPL would be on std. track and = TRICKLE as informational, tends to require explanations to the ADs. Reasonably so, I would = say. However often to more than one AD ;) I'm speaking from experience in saying that. 5) My conclusion is, that the most smooth sailing would ensure by = having the TRICKLE document at the same maturity level as RPL. Which means publishing both = as std. track or both as informational. 6) My personal recommendation is to aim to move both forward on = std. track. If TRICKLE is=20 considered "ready" by the WG, nothing prevents the chairs to = consult with the ADs and progress the document, with RPL following shortly (possibly in = part in parallel). So, while I am not Phil, I will give you my opinion: the maturity level = chosen for TRICKLE will neither slow down nor speed up the document = progress, and the maturity level for publication should be chosen = according to (shocking, I know) the actual maturity of the = specification. For the below..... >>> I think if one puts Trickle on Stds Track then there should be a >>> note in RPL saying Trickle is "lower maturity", as RFC4897 >>> recommends. >>>=20 >>>> Otherwise, we have a downref issue, >>=20 I do not think that your reading and understanding of 4897 is accurate. = If RPL and Trickle are both on std. track and being forwarded as PS, = then there is no downref issue. Thomas On Aug 2, 2010, at 17:27 , Alexandru Petrescu wrote: > Le 02/08/2010 16:25, Philip Levis a =E9crit : >>=20 >> On Aug 2, 2010, at 2:10 AM, Alexandru Petrescu wrote: >>=20 >>> Le 02/08/2010 10:19, JP Vasseur a =E9crit : >>>> Hi Alex, >>>>=20 >>>> OK I'll try to call you to explain ... >>>>=20 >>>> If Trickle moves to Std track, the problem is solved. >>>=20 >>> I think if one puts Trickle on Stds Track then there should be a >>> note in RPL saying Trickle is "lower maturity", as RFC4897 >>> recommends. >>>=20 >>>> Otherwise, we have a downref issue, >>>=20 >>> No, you have a downref (or downward) issue _only_ if you put >>> Trickle on Stds Track. If you keep Trickle on INFORMATIONAL, and >>> make the reference "Informative" then you have no problem. >>>=20 >>> If you keep Trickle on INFORMATIONAL and keep Trickle referred as >>> "Normative Reference" then you simply have a wrong document, not >>> necessarily a "downref". It becomes a downref or downward problem >>> when you put it on StdsTrack. >>>=20 >>>> which is solvable. >>>=20 >>> There exist a solution to the downref problem. >>>=20 >>> But here we don't have a downref problem, I believe. You are about >>> to transform the "wrong document" problem (Normative reference >>> pointing to an INFORMATIONAL document) into a downref problem. >>=20 >> It's worth noting that Trickle used to be part of the RPL draft. The >> WG agreed that moving Trickle into a separate draft was a good idea >> because it would allow simpler references in future drafts (e.g., >> Jonathan and Richard's Trickle-based multicast). This happened in >> version -08. I am amazed that my accidentally marking the draft as >> Informational (due to being an IETF neophyte) could cause such a >> disagreement. >>=20 >> A cursory reading of the draft text would show that Trickle is a >> normative reference (Section 8.3 in -11). >=20 > Yes, Trickle I-D is a Normative reference in RPL -11. >=20 >> Changing fundamental technical features of RPL for easily solved >> procedural reasons seems like terrible engineering and design, IMHO. >=20 > Philip: do you think RPL draft would go faster to IESG if Trickle > Normative ref were on StdsTrack? >=20 > I believe it would be slower than if it were INFORMATIONAL. (an LC for = Trickle would be needed, etc.) >=20 > IMHO >=20 > Alex >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pister@eecs.berkeley.edu Mon Aug 2 09:45:06 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 709533A67E3 for ; Mon, 2 Aug 2010 09:45:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEXaM5j9JK5v for ; Mon, 2 Aug 2010 09:45:04 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id CF8513A6ABE for ; Mon, 2 Aug 2010 09:45:04 -0700 (PDT) Received: from [10.10.40.32] (cust-67-203-88-62.static.o1.com [67.203.88.62]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o72GjIpL022435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Aug 2010 09:45:24 -0700 (PDT) Message-ID: <4C56F61E.1020808@eecs.berkeley.edu> Date: Mon, 02 Aug 2010 09:45:18 -0700 From: Kris Pister User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Pascal Thubert (pthubert)" References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] Status change on Trickle I-D (was: Draft ROLL WG minutesposted) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 16:45:06 -0000 I agree that trickle should move to standards track. ksjp Pascal Thubert (pthubert) wrote: > Alex: > > We need to be very clear that the WG is chartered for Standard Track, > not Informational. So RPL is and will stay on that track. > Moving Trickle to standard track is a good move, highly deserved for a > method that's well understood and proven, and I support it 100%. > > Safe trip back, > > Pascal > > >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> > Of > >> Alexandru Petrescu >> Sent: Friday, July 30, 2010 8:19 AM >> To: roll@ietf.org >> Subject: [Roll] Status change on Trickle I-D (was: Draft ROLL WG >> minutesposted) >> >> >>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02 (Phil - 5mn) >>> [160] Quick update on the changes in -02. Currently in LC. >>> >>> JP> ID is a normative reference in RPL core spec (thus we have a >>> downref). Discussion on ID status JP> Will come back to the list to >>> consider status change (informational to standard track) >>> >> Just a quick note to consider more ways to solve this problem (RPL >> > spec > >> 'downref'erencing a draft it fully relies on): >> >> -move draft-ietf-roll-trickle in the Informative References section. >> This implies making Trickle parameters less mandatory in RPL. >> -change the track of the base spec to Informational (this implies >> > change to > >> communication to SDO requiring this RP, I suppose). >> >> Also worth mentioning the use of BCP tag on the Trickle draft... >> > Trickle being > >> common practice in widespread use yet not really a protocol (timer >> management). >> >> These may have already been considered, >> >> Alex >> _______________________________________________ >> 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 Matteo.Paris@ember.com Mon Aug 2 10:03:55 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 313863A6965 for ; Mon, 2 Aug 2010 10:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KFRZNwPvzTzM for ; Mon, 2 Aug 2010 10:03:53 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 474663A680A for ; Mon, 2 Aug 2010 10:03:53 -0700 (PDT) Received: from [192.168.100.103] ([192.168.81.65]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 2 Aug 2010 13:04:20 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <85BBD155-1DFB-4F11-B634-2FB055FF363A@cisco.com> References: <85BBD155-1DFB-4F11-B634-2FB055FF363A@cisco.com> Date: Mon, 2 Aug 2010 13:04:19 -0400 To: JP Vasseur , ROLL WG From: Matteo Paris Content-Type: multipart/alternative; boundary="============_-931353836==_ma============" X-OriginalArrivalTime: 02 Aug 2010 17:04:20.0550 (UTC) FILETIME=[BFC26E60:01CB3264] Subject: Re: [Roll] ALL *** Status change on Trickle I-D X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 17:03:55 -0000 --============_-931353836==_ma============ Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable I choose (a), move Trickle on Std track. Matteo At 10:26 AM +0200 8/2/10, JP Vasseur wrote: >Dear all, > >Several of you expressed their preferences=20 >already. Others could you please chime in ? >(a) Move Trickle on Std track (which as I=20 >explained in other emails sorts out the downref=20 >issue) - 4 in Favor so far >(b) Keep it on the Informational Track > >Thanks. > >JP. > >Begin forwarded message: > >>From: JP Vasseur <jpv@cisco.com> >>Date: August 2, 2010 10:19:47 AM CEDT >>To: Alexandru Petrescu=20 >><alexandru.petrescu@gmail.com> >>Cc: ROLL WG <roll@ietf.org> >>Subject: Re: [Roll] Status change on Trickle I-D >> >>Hi Alex, >> >>OK I'll try to call you to explain ... >> >>If Trickle moves to Std track, the problem is=20 >>solved. Otherwise, we have a downref issue,=20 >>which >>is solvable. >> >>Can you simply say what you would lean toward for the trickle ID ? >> Informational >> Standard >> >>Thanks. >> >>JP. >> >>On Aug 2, 2010, at 10:01 AM, Alexandru Petrescu wrote: >> >>>Le 31/07/2010 22:40, JP Vasseur a =E9crit : >>> >>>> >>>>On Jul 31, 2010, at 5:05 PM, Alexandru Petrescu wrote: >>>> >>>> >>>>>Le 30/07/2010 22:54, JP Vasseur a =E9crit : >>>>> >>>>>> >>>>>>On Jul 30, 2010, at 2:09 PM, Pascal Thubert (pthubert) wrote: >>>>>> >>>>>> >>>>>>>Alex: >>>>>>> >>>>>>> >>>>>>>We need to be very clear that the WG is chartered for Standard >>>>>>> >>>>>>>Track, not Informational. So RPL is and will stay on that >>>>>>> >>>>>>>track. >>>>>>> >>>>>> >>>>>>That's correct. >>>>>> >>>>>> >>>>>>>Moving Trickle to standard track is a good move, highly >>>>>>> >>>>>>>deserved for a method that's well understood and proven, and I >>>>>>> >>>>>>>support it 100%. >>>>>>> >>>>>>> >>>>>> >>>>>>As a WG LC, I do favor to have the trickle ID move to Std track >>>>>> >>>>>>too. >>>>>> >>>>> >>>>>Would Trickle Stds Track mean it is mandatory in order to implement >>>>> >>>>>RPL? >>>>> >>>>> >>>> >>>>If you want Alex I can give you a call and explain the process next >>>> >>>>week. In a nutshell, Trickle is a normative reference (answer to your >>>> >>>>question is of course "yes") and RPL is std track according to our >>>> >>>>charter. Now we can either have the trickle ID be an informative ref >>>> >>>>in which case we have what we call a downref or simply move trickle >>>> >>>>to Std track. >>>> >>> >>>Ok. If Trickle is put as Informative reference in RPL - will we still >>> >>>have a 'downref' problem? I don't think so. >>> >>> >>>I think a downref/downward problem appears only when the referred >>> >>>document is already StdsTrack, and problem be solved by simply >>> >>>annotating as 'lower maturity'. >>> >>> >>>>For the process in general, let me know if you need more pointers to >>>> >>>>understand the process. >>>> >>> >>>Yes, please send in. I am only aware of RFC4897 "Handling Normative >>> >>>References to Standards-Track Documents". >>> >>> >>>Alex >>> >>> >>> >>>> >>>>Thanks. >>>> >>>> >>>>JP. >>>> >>>> >>>>>Alex >>>>> >>>>> >>>>>> >>>>>>JP. >>>>>> >>>>>> >>>>>>>Safe trip back, >>>>>>> >>>>>>> >>>>>>>Pascal >>>>>>> >>>>>>> >>>>>>>>-----Original Message----- From:=20 >>>>>>>>roll-bounces@ietf.org >>>>>>>> >>>>>>>>[mailto:roll-bounces@ietf.org] On Beha= lf >>>>>>>> >>>>>>>Of >>>>>>> >>>>>>>>Alexandru Petrescu Sent: Friday, July 30, 2010 8:19 AM To: >>>>>>>> >>>>>>>>roll@ietf.org=20 >>>>>>>>Subject: [Roll] Status change on Trickle=20 >>>>>>>>I-D >>>>>>>> >>>>>>>>(was: Draft ROLL WG minutesposted) >>>>>>>> >>>>>>>> >>>>>>>>>5) The Trickle Algorithm - draft-levis-roll-trickle-02 >>>>>>>>> >>>>>>>>>(Phil - 5mn) [160] Quick update on the changes in -02. >>>>>>>>> >>>>>>>>>Currently in LC. >>>>>>>>> >>>>>>>>> >>>>>>>>>JP> ID is a normative reference in RPL core spec (thus we >>>>>>>>> >>>>>>>>>have a downref). Discussion on ID status JP> Will come back >>>>>>>>> >>>>>>>>>to the list to consider status change (informational to >>>>>>>>> >>>>>>>>>standard track) >>>>>>>>> >>>>>>>> >>>>>>>>Just a quick note to consider more ways to solve this >>>>>>>> >>>>>>>>problem (RPL >>>>>>>> >>>>>>>spec >>>>>>> >>>>>>>>'downref'erencing a draft it fully relies on): >>>>>>>> >>>>>>>> >>>>>>>>-move draft-ietf-roll-trickle in the Informative References >>>>>>>> >>>>>>>>section. This implies making Trickle parameters less >>>>>>>> >>>>>>>>mandatory in RPL. -change the track of the base spec to >>>>>>>> >>>>>>>>Informational (this implies >>>>>>>> >>>>>>>change to >>>>>>> >>>>>>>>communication to SDO requiring this RP, I suppose). >>>>>>>> >>>>>>>> >>>>>>>>Also worth mentioning the use of BCP tag on the Trickle >>>>>>>> >>>>>>>>draft... >>>>>>>> >>>>>>>Trickle being >>>>>>> >>>>>>>>common practice in widespread use yet not really a protocol >>>>>>>> >>>>>>>>(timer management). >>>>>>>> >>>>>>>> >>>>>>>>These may have already been considered, >>>>>>>> >>>>>>>> >>>>>>>>Alex _______________________________________________ Roll >>>>>>>> >>>>>>>>mailing list Roll@ietf.org >>>>>>>> >>>>>>>>https://www.ietf.org/mai= lman/listinfo/roll >>>>>>>> >>>>>>>_______________________________________________ Roll mailing >>>>>>> >>>>>>>list Roll@ietf.org=20 >>>>>>>https://www.ietf.org/mail= man/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 --============_-931353836==_ma============ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Roll] ALL *** Status change on Trickle I-D

I choose (a), move Trickle on Std track.

Matteo

At 10:26 AM +0200 8/2/10, JP Vasseur wrote:
Dear all,

Several of you expressed their preferences already. Others could you please chime in ?
(a) Move Trickle on Std track (which as I explained in other emails sorts out the downref issue) - 4 in =46avor so far
(b) Keep it on the Informational Track

Thanks.

JP.

Begin forwarded message:

From: JP Vasseur <jpv@cisco.com>
Date: August 2, 2010 10:19:47 AM CEDT
To: Alexandru Petrescu <alexandru.petrescu@gmail.com>
Cc: ROLL WG <roll@ietf.org>
Subject: Re: [Roll] Status change on Trickle I-D

Hi Alex,

OK I'll try to call you to explain ...

If Trickle moves to Std track, the problem is solved. Otherwise, we have a downref issue, which
is solvable.

Can you simply say what you would lean toward for the trickle ID ?
     Informational
   Standard

Thanks.

JP.

On Aug 2, 2010, at 10:01 AM, Alexandru Petrescu wrote:
Le 31/07/2010 22:40, JP Vasseur a =E9crit :

On Jul 31, 2010, at 5:05 PM, Alexandru Petrescu wrote:

Le 30/07/2010 22:54, JP Vasseur a =E9crit :

On Jul 30, 2010, at 2:09 PM, Pascal Thubert (pthubert) wrote:

Alex:

We need to be very clear that the WG is chartered for Standard
Track, not Informational. So RPL is and will stay on that
track.

That's correct.

Moving Trickle to standard track is a good move, highly
deserved for a method that's well understood and proven, and I
support it 100%.


As a WG LC, I do favor to have the trickle ID move to Std track
too.

Would Trickle Stds Track mean it is mandatory in order to implement
RPL?


If you want Alex I can give you a call and explain the process next
week. In a nutshell, Trickle is a normative reference (answer to your
question is of course "yes") and RPL is std track according to our
charter. Now we can either have the trickle ID be an informative ref
in which case we have what we call a downref or simply move trickle
to Std track.

Ok.  If Trickle is put as Informative reference in RPL - will we still
have a 'downref' problem?  I don't think so.

I think a downref/downward problem appears only when the referred
document is already StdsTrack, and problem be solved by simply
annotating as 'lower maturity'.

For the process in general, let me know if you need more pointers to
understand the process.

Yes, please send in.  I am only aware of RFC4897 "Handling Normative
References to Standards-Track Documents".

Alex



Thanks.

JP.

Alex


JP.

Safe trip back,

Pascal

-----Original Message----- From: roll-bounces@ietf.org
[mailto:roll-bounces@ietf.org] On Behalf
Of
Alexandru Petrescu Sent: Friday, July 30, 2010 8:19 AM To:
roll@ietf.org Subject: [Roll] Status change on Trickle I-D
(was: Draft ROLL WG minutesposted)

5) The Trickle Algorithm - draft-levis-roll-trickle-02
(Phil - 5mn) [160] Quick update on the changes in -02.
Currently in LC.

JP> ID is a normative reference in RPL core spec (thus we
have a downref). Discussion on ID status JP> Will come back
to the list to consider status change (informational to
standard track)

Just a quick note to consider more ways to solve this
problem (RPL
spec
'downref'erencing a draft it fully relies on):

-move draft-ietf-roll-trickle in the Informative References
section. This implies making Trickle parameters less
mandatory in RPL. -change the track of the base spec to
Informational (this implies
change to
communication to SDO requiring this RP, I suppose).

Also worth mentioning the use of BCP tag on the Trickle
draft...
Trickle being
common practice in widespread use yet not really a protocol
(timer management).

These may have already been considered,

Alex _______________________________________________ Roll
mailing list Roll@ietf.org

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








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


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

--============_-931353836==_ma============-- From alexandru.petrescu@gmail.com Mon Aug 2 12:05:18 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB7683A6C36 for ; Mon, 2 Aug 2010 12:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.999 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oJUmbNt0vMCv for ; Mon, 2 Aug 2010 12:05:17 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 322F63A6C29 for ; Mon, 2 Aug 2010 12:05:15 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 009589400FB; Mon, 2 Aug 2010 21:05:36 +0200 (CEST) Message-ID: <4C5716FC.7060806@gmail.com> Date: Mon, 02 Aug 2010 21:05:32 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Thomas Heide Clausen References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> <4C543BB7.4010200@gmail.com> <2815B6B7-1F49-4AA5-9509-A82C9695FAB0@cisco.com> <4C567B53.302@gmail.com> <4C568B6C.5070501@gmail.com> <4C56E3D6.7050305@gmail.com> <788B1A64-E953-47C5-9E84-74234AB5D425@thomasclausen.org> In-Reply-To: <788B1A64-E953-47C5-9E84-74234AB5D425@thomasclausen.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100802-1, 02/08/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] what is a downref and LC for Trickle? (was: Status change on Trickle I-D) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 19:05:19 -0000 Le 02/08/2010 17:43, Thomas Heide Clausen a écrit : > Dear Alex, > > 1) A downref is if a document has a normative reference to a > document at a lower maturity level, e.g. a std. track document > referencing an experimental or informational RFC normatively. > > A "proposed standard" referencing another "proposed standard" is not > a downref, ever. Thomas - where is "downref" defined that way? I see the "down-ref" RFC3967 to mean "downward" reference as you say - towards INFORMATIONAL or EXPERIMENTAL. I see however "downward" reference in RFC4897 to be "[...] a normative downward reference to a Standards-Track RFC" - this seems to contradict what you say (PS ref'ing another PS can't be a downref.) > I believe that what the WG chairs were suggesting was for RPL and > TRICKLE to both be published as "proposed standard", i.e. no > downref. Ok, that's a good suggestion, provided we see LC on Trickle, no? > 2) Observing what I have seen in the RTG area, most ADs have IETF > LCed also experimental and informational documents in the past > years. This is a healthy thing to do. I think so too. > I believe that, therefore, the choice of maturity level (exp., inf, > PS, DS, ...) would not impact the publication timing. > > (In general, choosing the "maturity level" of the document based on > "how to publish it fast" would be a bad strategy). > > 3) I believe that it is not unheard of to move several documents > forward together, i.e. to WGLC, LC them together Right, I agree. However the LC was _only_ on the RPL doc. If by 'RPL' Chairs meant actually RPL+Trickle + probably RH... then that LC was different indeed. > - if they have mutual reference, or if they happen to be ready at > the same time. In general, the IETF and even the IESG seems to be > rather good at multitasking, and it may even be an advantage to get > both to review concurrently. > > 4) Downref's, as in the case where RPL would be on std. track and > TRICKLE as informational, tends to require explanations to the ADs. Right... But forwarding a draft to IESG which has't been LC'ed would also require explanations to ADs I believe. > Reasonably so, I would say. However often to more than one AD ;) I'm > speaking from experience in saying that. :-) > 5) My conclusion is, that the most smooth sailing would ensure by > having the TRICKLE document at the same maturity level as RPL. Which > means publishing both as std. track or both as informational. Ok, I read that. In this case, smooth sailing would be ensured _if_ we had a LC on Trickle I-D. > 6) My personal recommendation is to aim to move both forward on std. > track. If TRICKLE is considered "ready" by the WG, nothing prevents > the chairs to consult with the ADs and progress the document, with > RPL following shortly (possibly in part in parallel). > > So, while I am not Phil, I will give you my opinion: the maturity > level chosen for TRICKLE will neither slow down nor speed up the > document progress, and the maturity level for publication should be > chosen according to (shocking, I know) the actual maturity of the > specification. > > For the below..... > >>>> I think if one puts Trickle on Stds Track then there should be >>>> a note in RPL saying Trickle is "lower maturity", as RFC4897 >>>> recommends. >>>> >>>>> Otherwise, we have a downref issue, >>> > > > I do not think that your reading and understanding of 4897 is > accurate. If RPL and Trickle are both on std. track and being > forwarded as PS, then there is no downref issue. I see what you mean - you propose to forward Trickle I-D together with the RPL I-D simultaneously to IESG - makes some sense if the last LC covered it too. And by logical extension, was the RPL LC actually about all these documents: draft-ietf-roll-rpl-10 draft-ietf-6man-rpl-option-00 draft-ietf-6man-rpl-routing-header-00 draft-ietf-roll-routing-metrics-08 draft-ietf-roll-trickle-02 (the last 4 are all Normative references and on the StdsTrack) Alex > > Thomas > > On Aug 2, 2010, at 17:27 , Alexandru Petrescu wrote: > >> Le 02/08/2010 16:25, Philip Levis a écrit : >>> >>> On Aug 2, 2010, at 2:10 AM, Alexandru Petrescu wrote: >>> >>>> Le 02/08/2010 10:19, JP Vasseur a écrit : >>>>> Hi Alex, >>>>> >>>>> OK I'll try to call you to explain ... >>>>> >>>>> If Trickle moves to Std track, the problem is solved. >>>> >>>> I think if one puts Trickle on Stds Track then there should be >>>> a note in RPL saying Trickle is "lower maturity", as RFC4897 >>>> recommends. >>>> >>>>> Otherwise, we have a downref issue, >>>> >>>> No, you have a downref (or downward) issue _only_ if you put >>>> Trickle on Stds Track. If you keep Trickle on INFORMATIONAL, >>>> and make the reference "Informative" then you have no problem. >>>> >>>> If you keep Trickle on INFORMATIONAL and keep Trickle referred >>>> as "Normative Reference" then you simply have a wrong document, >>>> not necessarily a "downref". It becomes a downref or downward >>>> problem when you put it on StdsTrack. >>>> >>>>> which is solvable. >>>> >>>> There exist a solution to the downref problem. >>>> >>>> But here we don't have a downref problem, I believe. You are >>>> about to transform the "wrong document" problem (Normative >>>> reference pointing to an INFORMATIONAL document) into a >>>> downref problem. >>> >>> It's worth noting that Trickle used to be part of the RPL draft. >>> The WG agreed that moving Trickle into a separate draft was a >>> good idea because it would allow simpler references in future >>> drafts (e.g., Jonathan and Richard's Trickle-based multicast). >>> This happened in version -08. I am amazed that my accidentally >>> marking the draft as Informational (due to being an IETF >>> neophyte) could cause such a disagreement. >>> >>> A cursory reading of the draft text would show that Trickle is a >>> normative reference (Section 8.3 in -11). >> >> Yes, Trickle I-D is a Normative reference in RPL -11. >> >>> Changing fundamental technical features of RPL for easily solved >>> procedural reasons seems like terrible engineering and design, >>> IMHO. >> >> Philip: do you think RPL draft would go faster to IESG if Trickle >> Normative ref were on StdsTrack? >> >> I believe it would be slower than if it were INFORMATIONAL. (an LC >> for Trickle would be needed, etc.) >> >> IMHO >> >> Alex >> >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > From pal@cs.stanford.edu Mon Aug 2 13:19:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 93B283A6BC9 for ; Mon, 2 Aug 2010 13:19:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.018 X-Spam-Level: X-Spam-Status: No, score=-6.018 tagged_above=-999 required=5 tests=[AWL=-0.019, BAYES_00=-2.599, J_CHICKENPOX_37=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGgvBk9GZy8w for ; Mon, 2 Aug 2010 13:19:01 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id C4DB83A698C for ; Mon, 2 Aug 2010 13:19:01 -0700 (PDT) Received: from [172.27.75.91] by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Og1Tt-0005oO-FO; Mon, 02 Aug 2010 13:19:29 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4C5716FC.7060806@gmail.com> Date: Mon, 2 Aug 2010 13:19:28 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <07C37609-83B9-4591-AE48-985E4C74632F@cs.stanford.edu> References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> <4C543BB7.4010200@gmail.com> <2815B6B7-1F49-4AA5-9509-A82C9695FAB0@cisco.com> <4C567B53.302@gmail.com> <4C568B6C.5070501@gmail.com> <4C56E3D6.7050305@gmail.com> <788B1A64-E953-47C5-9E84-74234AB5D425@thomasclausen.org> <4C5716FC.7060806@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 2c21b60125577a2cbf52524016395bed Cc: ROLL WG Subject: Re: [Roll] what is a downref and LC for Trickle? (was: Status change on Trickle I-D) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:19:02 -0000 On Aug 2, 2010, at 12:05 PM, Alexandru Petrescu wrote: >=20 >> I believe that what the WG chairs were suggesting was for RPL and >> TRICKLE to both be published as "proposed standard", i.e. no >> downref. >=20 > Ok, that's a good suggestion, provided we see LC on Trickle, no? >=20 >> 2) Observing what I have seen in the RTG area, most ADs have IETF >> LCed also experimental and informational documents in the past >> years. This is a healthy thing to do. >=20 > I think so too. >=20 >> I believe that, therefore, the choice of maturity level (exp., inf, >> PS, DS, ...) would not impact the publication timing. >>=20 >> (In general, choosing the "maturity level" of the document based on >> "how to publish it fast" would be a bad strategy). >>=20 >> 3) I believe that it is not unheard of to move several documents >> forward together, i.e. to WGLC, LC them together >=20 > Right, I agree. However the LC was _only_ on the RPL doc. >=20 > If by 'RPL' Chairs meant actually RPL+Trickle + probably RH... then = that > LC was different indeed. >=20 Alex, Please pay closer attention: > From: JP Vasseur > Date: July 28, 2010 1:05:41 AM PDT > To: ROLL WG > Subject: [Roll] WG Last Call on draft-ietf-roll-trickle-02 >=20 > Dear WG, >=20 > draft-ietf-roll-trickle-02 is stable and now ready for WG Last Call. >=20 > This starts a 2-week Working Group last call ending on August 11 at = 9:00am ET. >=20 > Please send your comments to the authors and the list. >=20 > Thanks. >=20 > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll Phil= From alexandru.petrescu@gmail.com Mon Aug 2 13:24:47 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A07B63A686C for ; Mon, 2 Aug 2010 13:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.31 X-Spam-Level: X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIceucJwNLNq for ; Mon, 2 Aug 2010 13:24:46 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 8CCD43A681E for ; Mon, 2 Aug 2010 13:24:44 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 9F6FC9400B5; Mon, 2 Aug 2010 22:25:07 +0200 (CEST) Message-ID: <4C57299F.8090102@gmail.com> Date: Mon, 02 Aug 2010 22:25:03 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Philip Levis References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> <4C543BB7.4010200@gmail.com> <2815B6B7-1F49-4AA5-9509-A82C9695FAB0@cisco.com> <4C567B53.302@gmail.com> <4C568B6C.5070501@gmail.com> <4C56E3D6.7050305@gmail.com> <788B1A64-E953-47C5-9E84-74234AB5D425@thomasclausen.org> <4C5716FC.7060806@gmail.com> <07C37609-83B9-4591-AE48-985E4C74632F@cs.stanford.edu> In-Reply-To: <07C37609-83B9-4591-AE48-985E4C74632F@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100802-1, 02/08/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] what is a downref and LC for Trickle? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:24:47 -0000 Sorry Phil - ok, there is a LC for Trickle I-D, I missed it, not in my mailbox. Alex Le 02/08/2010 22:19, Philip Levis a écrit : > > On Aug 2, 2010, at 12:05 PM, Alexandru Petrescu wrote: > >> >>> I believe that what the WG chairs were suggesting was for RPL and >>> TRICKLE to both be published as "proposed standard", i.e. no >>> downref. >> >> Ok, that's a good suggestion, provided we see LC on Trickle, no? >> >>> 2) Observing what I have seen in the RTG area, most ADs have IETF >>> LCed also experimental and informational documents in the past >>> years. This is a healthy thing to do. >> >> I think so too. >> >>> I believe that, therefore, the choice of maturity level (exp., inf, >>> PS, DS, ...) would not impact the publication timing. >>> >>> (In general, choosing the "maturity level" of the document based on >>> "how to publish it fast" would be a bad strategy). >>> >>> 3) I believe that it is not unheard of to move several documents >>> forward together, i.e. to WGLC, LC them together >> >> Right, I agree. However the LC was _only_ on the RPL doc. >> >> If by 'RPL' Chairs meant actually RPL+Trickle + probably RH... then that >> LC was different indeed. >> > > Alex, > > Please pay closer attention: > >> From: JP Vasseur >> Date: July 28, 2010 1:05:41 AM PDT >> To: ROLL WG >> Subject: [Roll] WG Last Call on draft-ietf-roll-trickle-02 >> >> Dear WG, >> >> draft-ietf-roll-trickle-02 is stable and now ready for WG Last Call. >> >> This starts a 2-week Working Group last call ending on August 11 at 9:00am ET. >> >> Please send your comments to the authors and the list. >> >> Thanks. >> >> JP. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > > Phil From dominique.barthel@orange-ftgroup.com Mon Aug 2 13:37:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A86553A681A for ; Mon, 2 Aug 2010 13:37:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.446 X-Spam-Level: X-Spam-Status: No, score=-1.446 tagged_above=-999 required=5 tests=[AWL=-0.798, BAYES_50=0.001, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nOh8GYrGjxWO for ; Mon, 2 Aug 2010 13:37:01 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 40F9C3A6784 for ; Mon, 2 Aug 2010 13:37:01 -0700 (PDT) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id ACFC7760007 for ; Mon, 2 Aug 2010 22:38:52 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 3631B768001 for ; Mon, 2 Aug 2010 22:35:19 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Aug 2010 22:31:19 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3281.A9770DE6" Date: Mon, 2 Aug 2010 22:31:18 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF017977BD@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on path cost propagation in the DODAG Thread-Index: AcsyTUuaXAzYhngsQtOLSlzb/Ajzxw== From: To: X-OriginalArrivalTime: 02 Aug 2010 20:31:19.0740 (UTC) FILETIME=[AA2C6FC0:01CB3281] Subject: [Roll] Question on path cost propagation in the DODAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:37:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3281.A9770DE6 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hello Phil, all, Our mutual questions and ensuing discussion at the IETF78 meeting in Maastricht uncovered a different understanding of the way path costs are propagated in the DODAG. To the whole Working Group benefit, here's the discussion again. Let's suppose that node X has selected node A as its preferred parent, and nodes B and C as alternate parents. In addition, let's suppose node Y is a child for node X. During the life of the network, path costs propagated by DIOs are likely to fluctuate while the ranks and parenthood relationship are kept more stable, by only updating them on persistent and significant changes in costs (see [1]). The question is, what metric should X advertise in its own DIOs to Y? * answer 1) X should always advertize the cost derived from that of node A, no matter what B and C advertize, because A is the preferred parent of X. * answer 2) X should advertize the best cost derived from its complete current parent set, as in a distance vector routing protocol. Because B and C are likely to be used as next-hops in addition to A (low-power and lossy links come and go), it is right to somehow take them into account in the cost propagated to Y. * answer 3) This decision is left to the implementer. I couldn't find in RPL -11 any text providing an answer to this question. I'm curious to hear opinions from the Working Group, notably those who have implemented RPL? Note that in RPL-11, _the_ preferred parent can actually be a set of parents [2]. Thanks, Dominique ----------------------- References [1] RPL-11 Section 3.6 "The stability of the rank determines the stability of the routing topology. Some dampening or filtering is RECOMMENDED to keep the topology stable, and thus the rank does not necessarily change as fast as some link or node metrics would. A new DODAG Version would be a good opportunity to reconcile the discrepancies that might form over time between metrics and ranks within a DODAG Version." [2] RPL-11 Section 8.2.1. "The preferred parent is conceptually a single parent although it may be a set of multiple parents if those parents are equally preferred and have identical rank." ------_=_NextPart_001_01CB3281.A9770DE6 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Question on path cost propagation in the DODAG

Hello Phil, all,

Our mutual questions and ensuing = discussion at the IETF78 meeting in Maastricht uncovered a different = understanding of the way path costs are propagated in the = DODAG.

To the whole Working Group benefit, = here's the discussion again.

Let's suppose that node X has selected = node A as its preferred parent, and nodes B and C as alternate parents. = In addition, let's suppose node Y is a child for node X.

During the life of the network, path = costs propagated by DIOs are likely to fluctuate while the ranks and = parenthood relationship are kept more stable, by only updating them on = persistent and significant changes in costs (see [1]).

The question is, what metric should X = advertise in its own DIOs to Y?
* answer 1)
X should always advertize the cost = derived from that of node A, no matter what B and C advertize, because A = is the preferred parent of X.

* answer 2)
X should advertize the best cost = derived from its complete current parent set, as in a distance vector = routing protocol. Because B and C are likely to be used as next-hops in = addition to A (low-power and lossy links come and go), it is right to = somehow take them into account in the cost propagated to Y.

* answer 3)
This decision is left to the = implementer.

I couldn't find in RPL -11 any text = providing an answer to this question.
I'm curious to hear opinions from the = Working Group, notably those who have implemented RPL?
Note that in RPL-11, _the_ preferred = parent can actually be a set of parents [2].
Thanks,

Dominique

-----------------------
References

[1] RPL-11 Section 3.6
"The stability of the rank = determines the stability of the routing topology. Some dampening or = filtering is RECOMMENDED
to keep the topology stable, and thus = the rank does not necessarily change as fast as some link or node = metrics
would. A new DODAG Version would be a = good opportunity to reconcile the discrepancies that might form over = time between
metrics and ranks within a DODAG = Version."

[2] RPL-11 Section 8.2.1.
"The preferred parent is = conceptually a single parent although it may be a set of multiple = parents if those parents are
equally preferred and have identical = rank."

------_=_NextPart_001_01CB3281.A9770DE6-- From dominique.barthel@orange-ftgroup.com Mon Aug 2 13:41:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628A53A681A for ; Mon, 2 Aug 2010 13:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SE+gpNxl6cB4 for ; Mon, 2 Aug 2010 13:41:23 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 1FB883A6784 for ; Mon, 2 Aug 2010 13:41:23 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9CF34738003 for ; Mon, 2 Aug 2010 22:42:02 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 9431F738002 for ; Mon, 2 Aug 2010 22:42:02 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 2 Aug 2010 22:41: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="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 2 Aug 2010 22:40:35 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF017977C0@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4C56F61E.1020808@eecs.berkeley.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Status change on Trickle I-D (was: Draft ROLLWG minutesposted) Thread-Index: AcsyYkbcyo56YH8sSzqtWl9H7BDCZQAIGkHw References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <4C56F61E.1020808@eecs.berkeley.edu> From: To: X-OriginalArrivalTime: 02 Aug 2010 20:41:49.0346 (UTC) FILETIME=[2172B020:01CB3283] Subject: Re: [Roll] Status change on Trickle I-D (was: Draft ROLLWG minutesposted) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:41:24 -0000 Moving Trickle to Std Track seems the most sensible move to me. Trickle seems to be applicable to a wide sprectrum of protocols, = therefore is likely to be referenced as Normative in several future Std = Track documents. Dominique -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = Kris Pister Envoy=E9 : lundi 2 ao=FBt 2010 18:45 =C0 : Pascal Thubert (pthubert) Cc : roll@ietf.org Objet : Re: [Roll] Status change on Trickle I-D (was: Draft ROLLWG = minutesposted) I agree that trickle should move to standards track. ksjp Pascal Thubert (pthubert) wrote: > Alex: > > We need to be very clear that the WG is chartered for Standard Track,=20 > not Informational. So RPL is and will stay on that track. > Moving Trickle to standard track is a good move, highly deserved for a = > method that's well understood and proven, and I support it 100%. > > Safe trip back, > > Pascal > > =20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> =20 > Of > =20 >> Alexandru Petrescu >> Sent: Friday, July 30, 2010 8:19 AM >> To: roll@ietf.org >> Subject: [Roll] Status change on Trickle I-D (was: Draft ROLL WG >> minutesposted) >> >> =20 >>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02 (Phil - 5mn) = >>> [160] Quick update on the changes in -02. Currently in LC. >>> >>> JP> ID is a normative reference in RPL core spec (thus we have a >>> downref). Discussion on ID status JP> Will come back to the list to=20 >>> consider status change (informational to standard track) >>> =20 >> Just a quick note to consider more ways to solve this problem (RPL >> =20 > spec > =20 >> 'downref'erencing a draft it fully relies on): >> >> -move draft-ietf-roll-trickle in the Informative References section. >> This implies making Trickle parameters less mandatory in RPL. >> -change the track of the base spec to Informational (this implies >> =20 > change to > =20 >> communication to SDO requiring this RP, I suppose). >> >> Also worth mentioning the use of BCP tag on the Trickle draft... >> =20 > Trickle being > =20 >> common practice in widespread use yet not really a protocol (timer=20 >> management). >> >> These may have already been considered, >> >> Alex >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> =20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Mon Aug 2 13:43:31 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B568D3A6B93 for ; Mon, 2 Aug 2010 13:43:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.316 X-Spam-Level: X-Spam-Status: No, score=-6.316 tagged_above=-999 required=5 tests=[AWL=0.283, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylY7HZWQJszP for ; Mon, 2 Aug 2010 13:43:30 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id DACD33A686E for ; Mon, 2 Aug 2010 13:43:30 -0700 (PDT) Received: from [172.27.75.91] by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Og1ra-000189-AG; Mon, 02 Aug 2010 13:43:58 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF017977BD@ftrdmel0.rd.francetelecom.fr> Date: Mon, 2 Aug 2010 13:43:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8E09C72DBC577D489F13A71228C0B7BF017977BD@ftrdmel0.rd.francetelecom.fr> To: X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 3134a374f3853b94094f80bd9e2b84a0 Cc: roll@ietf.org Subject: Re: [Roll] Question on path cost propagation in the DODAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:43:31 -0000 On Aug 2, 2010, at 1:31 PM, = wrote: > Hello Phil, all, >=20 > Our mutual questions and ensuing discussion at the IETF78 meeting in = Maastricht uncovered a different understanding of the way path costs are = propagated in the DODAG. >=20 > To the whole Working Group benefit, here's the discussion again. >=20 > Let's suppose that node X has selected node A as its preferred parent, = and nodes B and C as alternate parents. In addition, let's suppose node = Y is a child for node X. >=20 > During the life of the network, path costs propagated by DIOs are = likely to fluctuate while the ranks and parenthood relationship are kept = more stable, by only updating them on persistent and significant changes = in costs (see [1]). >=20 > The question is, what metric should X advertise in its own DIOs to Y?=20= > * answer 1)=20 > X should always advertize the cost derived from that of node A, no = matter what B and C advertize, because A is the preferred parent of X. >=20 > * answer 2)=20 > X should advertize the best cost derived from its complete current = parent set, as in a distance vector routing protocol. Because B and C = are likely to be used as next-hops in addition to A (low-power and lossy = links come and go), it is right to somehow take them into account in the = cost propagated to Y. >=20 > * answer 3)=20 > This decision is left to the implementer. >=20 > I couldn't find in RPL -11 any text providing an answer to this = question.=20 > I'm curious to hear opinions from the Working Group, notably those who = have implemented RPL?=20 > Note that in RPL-11, _the_ preferred parent can actually be a set of = parents [2].=20 > Thanks, I think the correct answer is 1). Note that the transmission-side damping is RECOMMENDED: a receiver can = simply defer decisions, e.g., using hysteresis. Phil= From ietf@thomasclausen.org Mon Aug 2 13:48:57 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 00D993A694E for ; Mon, 2 Aug 2010 13:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_37=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDpB+5jqIOCE for ; Mon, 2 Aug 2010 13:48:55 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by core3.amsl.com (Postfix) with ESMTP id 9121F3A69DC for ; Mon, 2 Aug 2010 13:48:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id C58EA3236DBC; Mon, 2 Aug 2010 13:49:23 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [192.168.147.110] (AMontsouris-552-1-5-123.w86-212.abo.wanadoo.fr [86.212.72.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTPSA id 183223236DBB; Mon, 2 Aug 2010 13:49:22 -0700 (PDT) References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> <4C543BB7.4010200@gmail.com> <2815B6B7-1F49-4AA5-9509-A82C9695FAB0@cisco.com> <4C567B53.302@gmail.com> <4C568B6C.5070501@gmail.com> <4C56E3D6.7050305@gmail.com> <788B1A64-E953-47C5-9E84-74234AB5D425@thomasclausen.org> <4C5716FC.7060806@gmail.com> Message-Id: <701FE52C-41C2-45EF-A931-B87EB3388D63@thomasclausen.org> From: Thomas Heide Clausen To: Alexandru Petrescu In-Reply-To: <4C5716FC.7060806@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailer: iPad Mail (7B405) Mime-Version: 1.0 (iPad Mail 7B405) Date: Mon, 2 Aug 2010 22:49:28 +0200 Cc: ROLL WG Subject: Re: [Roll] what is a downref and LC for Trickle? (was: Status change on Trickle I-D) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:48:57 -0000 Dear Alex, You are asking me about the strategy for the documents in the wg. I = believe that i cannot answer that, as I am not the wg chair. I do, however, have full confidence that the roll chairs are "doing the = sensible thing" - they have thus far - and I suggest that as attitude = until evidence to the contrary. Thomas =20 --=20 Thomas Heide Clausen http://www.thomasclausen.org On 2 Aug 2010, at 21:05, Alexandru Petrescu = wrote: > Le 02/08/2010 17:43, Thomas Heide Clausen a =C3=A9crit : >> Dear Alex, >>=20 >> 1) A downref is if a document has a normative reference to a >> document at a lower maturity level, e.g. a std. track document >> referencing an experimental or informational RFC normatively. >>=20 >> A "proposed standard" referencing another "proposed standard" is not >> a downref, ever. >=20 > Thomas - where is "downref" defined that way? >=20 > I see the "down-ref" RFC3967 to mean "downward" reference as you say - > towards INFORMATIONAL or EXPERIMENTAL. >=20 > I see however "downward" reference in RFC4897 to be "[...] a = normative > downward reference to a Standards-Track RFC" - this seems to = contradict > what you say (PS ref'ing another PS can't be a downref.) >=20 >> I believe that what the WG chairs were suggesting was for RPL and >> TRICKLE to both be published as "proposed standard", i.e. no >> downref. >=20 > Ok, that's a good suggestion, provided we see LC on Trickle, no? >=20 >> 2) Observing what I have seen in the RTG area, most ADs have IETF >> LCed also experimental and informational documents in the past >> years. This is a healthy thing to do. >=20 > I think so too. >=20 >> I believe that, therefore, the choice of maturity level (exp., inf, >> PS, DS, ...) would not impact the publication timing. >>=20 >> (In general, choosing the "maturity level" of the document based on >> "how to publish it fast" would be a bad strategy). >>=20 >> 3) I believe that it is not unheard of to move several documents >> forward together, i.e. to WGLC, LC them together >=20 > Right, I agree. However the LC was _only_ on the RPL doc. >=20 > If by 'RPL' Chairs meant actually RPL+Trickle + probably RH... then = that > LC was different indeed. >=20 >> - if they have mutual reference, or if they happen to be ready at >> the same time. In general, the IETF and even the IESG seems to be >> rather good at multitasking, and it may even be an advantage to get >> both to review concurrently. >>=20 >> 4) Downref's, as in the case where RPL would be on std. track and >> TRICKLE as informational, tends to require explanations to the ADs. >=20 > Right... >=20 > But forwarding a draft to IESG which has't been LC'ed would also = require > explanations to ADs I believe. >=20 >> Reasonably so, I would say. However often to more than one AD ;) I'm >> speaking from experience in saying that. >=20 > :-) >=20 >> 5) My conclusion is, that the most smooth sailing would ensure by >> having the TRICKLE document at the same maturity level as RPL. Which >> means publishing both as std. track or both as informational. >=20 > Ok, I read that. In this case, smooth sailing would be ensured _if_ = we > had a LC on Trickle I-D. >=20 >> 6) My personal recommendation is to aim to move both forward on = std. >> track. If TRICKLE is considered "ready" by the WG, nothing prevents >> the chairs to consult with the ADs and progress the document, with >> RPL following shortly (possibly in part in parallel). >>=20 >> So, while I am not Phil, I will give you my opinion: the maturity >> level chosen for TRICKLE will neither slow down nor speed up the >> document progress, and the maturity level for publication should be >> chosen according to (shocking, I know) the actual maturity of the >> specification. >>=20 >> For the below..... >>=20 >>>>> I think if one puts Trickle on Stds Track then there should be >>>>> a note in RPL saying Trickle is "lower maturity", as RFC4897 >>>>> recommends. >>>>>=20 >>>>>> Otherwise, we have a downref issue, >>>>=20 >>=20 >>=20 >> I do not think that your reading and understanding of 4897 is >> accurate. If RPL and Trickle are both on std. track and being >> forwarded as PS, then there is no downref issue. >=20 > I see what you mean - you propose to forward Trickle I-D together with > the RPL I-D simultaneously to IESG - makes some sense if the last LC > covered it too. >=20 > And by logical extension, was the RPL LC actually about all these = documents: > draft-ietf-roll-rpl-10 > draft-ietf-6man-rpl-option-00 > draft-ietf-6man-rpl-routing-header-00 > draft-ietf-roll-routing-metrics-08 > draft-ietf-roll-trickle-02 >=20 > (the last 4 are all Normative references and on the StdsTrack) >=20 > Alex >=20 >>=20 >> Thomas >>=20 >> On Aug 2, 2010, at 17:27 , Alexandru Petrescu wrote: >>=20 >>> Le 02/08/2010 16:25, Philip Levis a =C3=A9crit : >>>>=20 >>>> On Aug 2, 2010, at 2:10 AM, Alexandru Petrescu wrote: >>>>=20 >>>>> Le 02/08/2010 10:19, JP Vasseur a =C3=A9crit : >>>>>> Hi Alex, >>>>>>=20 >>>>>> OK I'll try to call you to explain ... >>>>>>=20 >>>>>> If Trickle moves to Std track, the problem is solved. >>>>>=20 >>>>> I think if one puts Trickle on Stds Track then there should be >>>>> a note in RPL saying Trickle is "lower maturity", as RFC4897 >>>>> recommends. >>>>>=20 >>>>>> Otherwise, we have a downref issue, >>>>>=20 >>>>> No, you have a downref (or downward) issue _only_ if you put >>>>> Trickle on Stds Track. If you keep Trickle on INFORMATIONAL, >>>>> and make the reference "Informative" then you have no problem. >>>>>=20 >>>>> If you keep Trickle on INFORMATIONAL and keep Trickle referred >>>>> as "Normative Reference" then you simply have a wrong document, >>>>> not necessarily a "downref". It becomes a downref or downward >>>>> problem when you put it on StdsTrack. >>>>>=20 >>>>>> which is solvable. >>>>>=20 >>>>> There exist a solution to the downref problem. >>>>>=20 >>>>> But here we don't have a downref problem, I believe. You are >>>>> about to transform the "wrong document" problem (Normative >>>>> reference pointing to an INFORMATIONAL document) into a >>>>> downref problem. >>>>=20 >>>> It's worth noting that Trickle used to be part of the RPL draft. >>>> The WG agreed that moving Trickle into a separate draft was a >>>> good idea because it would allow simpler references in future >>>> drafts (e.g., Jonathan and Richard's Trickle-based multicast). >>>> This happened in version -08. I am amazed that my accidentally >>>> marking the draft as Informational (due to being an IETF >>>> neophyte) could cause such a disagreement. >>>>=20 >>>> A cursory reading of the draft text would show that Trickle is a >>>> normative reference (Section 8.3 in -11). >>>=20 >>> Yes, Trickle I-D is a Normative reference in RPL -11. >>>=20 >>>> Changing fundamental technical features of RPL for easily solved >>>> procedural reasons seems like terrible engineering and design, >>>> IMHO. >>>=20 >>> Philip: do you think RPL draft would go faster to IESG if Trickle >>> Normative ref were on StdsTrack? >>>=20 >>> I believe it would be slower than if it were INFORMATIONAL. (an LC >>> for Trickle would be needed, etc.) >>>=20 >>> IMHO >>>=20 >>> Alex >>>=20 >>> _______________________________________________ Roll mailing list >>> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 >=20 From alexandru.petrescu@gmail.com Mon Aug 2 13:55:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D08E3A69D6 for ; Mon, 2 Aug 2010 13:55:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.315 X-Spam-Level: X-Spam-Status: No, score=-0.315 tagged_above=-999 required=5 tests=[AWL=-0.666, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6X-Zk0CtFyq5 for ; Mon, 2 Aug 2010 13:55:33 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 5E4213A681E for ; Mon, 2 Aug 2010 13:55:31 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 3EA6B94007C; Mon, 2 Aug 2010 22:55:53 +0200 (CEST) Message-ID: <4C5730D6.60500@gmail.com> Date: Mon, 02 Aug 2010 22:55:50 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Thomas Heide Clausen References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <6B740DB5-856C-4498-A1C5-81DE3C27A1FF@cisco.com> <4C543BB7.4010200@gmail.com> <2815B6B7-1F49-4AA5-9509-A82C9695FAB0@cisco.com> <4C567B53.302@gmail.com> <4C568B6C.5070501@gmail.com> <4C56E3D6.7050305@gmail.com> <788B1A64-E953-47C5-9E84-74234AB5D425@thomasclausen.org> <4C5716FC.7060806@gmail.com> <701FE52C-41C2-45EF-A931-B87EB3388D63@thomasclausen.org> In-Reply-To: <701FE52C-41C2-45EF-A931-B87EB3388D63@thomasclausen.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100802-1, 02/08/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] what is a downref and LC for Trickle? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:55:34 -0000 Le 02/08/2010 22:49, Thomas Heide Clausen a écrit : > Dear Alex, > > You are asking me about the strategy for the documents in the wg. I > believe that i cannot answer that, as I am not the wg chair. > > I do, however, have full confidence that the roll chairs are "doing > the sensible thing" - they have thus far - and I suggest that as > attitude until evidence to the contrary. Sure Thomas - everyone does best to advance. Alex > > Thomas > From alexandru.petrescu@gmail.com Mon Aug 2 13:58:21 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8DCF3A6C6B for ; Mon, 2 Aug 2010 13:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.305 X-Spam-Level: X-Spam-Status: No, score=-0.305 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yTeHKgtyKsWH for ; Mon, 2 Aug 2010 13:58:20 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id C7CA83A6BC9 for ; Mon, 2 Aug 2010 13:58:18 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id EEC78940041 for ; Mon, 2 Aug 2010 22:58:41 +0200 (CEST) Message-ID: <4C57317E.3070900@gmail.com> Date: Mon, 02 Aug 2010 22:58:38 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100802-1, 02/08/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Some comments on Trickle I-D as response to Trickle LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 20:58:21 -0000 Hello, I respond to the Trickle LC. Although I missed the LC email. Hence I owe you Phil comments :-) The Trickle I-D I am looking at is http://tools.ietf.org/html/draft-ietf-roll-trickle-02 The document is short - 11 pages long, that is excellent! > Trickle sends all messages to the local broadcast address. In IPv6 no broadcast... so probably a multicast address with link-local scope would be better appropriated? Maybe the same used by RPL? Maybe the all-nodes multicast address with link scope? > 1. When an interval begins, Trickle resets c to 0 and sets t to a > random point in the interval I think it would be good to refer to a randomness thought, like when random is not as random as one would expect - if all nodes use the same randomness algorithm there may be a risk that all nodes have same 't' at powerup - risking all transmitters to send simultaneously at time t, making noise. It may not have occured in practice though. > 3. At time t, Trickle transmits if and only if counter c is less > than the redundancy constant k. Advice to set k follows, but it would have been good to see it near here prior to its use. > In general, it is much more desirable to set k to a high value (e.g., > 5 or 10) than infinity. Hmmm... sounds as if infinity was not 'high'. > a specification should say "the default value of Imin is 4 times the > worst case link layer latency" But RPL puts Imin as (2^DIOIntervalMin)ms, which is an exponential, which may lead to very large spaces near the max. Would the algorithm still work if DIOIntervalMin were 254 and Imin 2^254? And Imax 2^255, or so. Probably yes, just a comment. These are my comments, I hope useful. Alex From yoav@yitran.com Mon Aug 2 14:15:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 517893A6C7E for ; Mon, 2 Aug 2010 14:15:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.902 X-Spam-Level: X-Spam-Status: No, score=-5.902 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lTH4HsziqMSZ for ; Mon, 2 Aug 2010 14:15:33 -0700 (PDT) Received: from na3sys009aog112.obsmtp.com (na3sys009aog112.obsmtp.com [74.125.149.207]) by core3.amsl.com (Postfix) with SMTP id DB1E33A6C78 for ; Mon, 2 Aug 2010 14:15:31 -0700 (PDT) Received: from source ([74.125.82.50]) by na3sys009aob112.postini.com ([74.125.148.12]) with SMTP ID DSNKTFc1jUptW0Kl9t5I9gGKr8+2qndenuH1@postini.com; Mon, 02 Aug 2010 14:16:01 PDT Received: by mail-ww0-f50.google.com with SMTP id 36so2502076wwa.7 for ; Mon, 02 Aug 2010 14:15:57 -0700 (PDT) Received: by 10.227.141.138 with SMTP id m10mr5577821wbu.20.1280783756881; Mon, 02 Aug 2010 14:15:56 -0700 (PDT) From: Yoav Ben-Yehezkel References: <4C57317E.3070900@gmail.com> In-Reply-To: <4C57317E.3070900@gmail.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcsyhYOX2ZCDBboGTp6rTilsGeCuOwAAfb0g Date: Tue, 3 Aug 2010 00:15:54 +0300 Message-ID: To: Alexandru Petrescu , ROLL WG Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 21:15:34 -0000 Hi, I'd like to support and add to Alex's note on link local broadcast (that appears in many places in the trickle draft). To emphasize the problem with this, in RPL trickle timer messages are sent to All-RPL-Nodes multicast group, which is not a broadcast. I suggest to clarify this issue. Thanks, Yoav -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Alexandru Petrescu Sent: Monday, August 02, 2010 11:59 PM To: ROLL WG Subject: [Roll] Some comments on Trickle I-D as response to Trickle LC Hello, I respond to the Trickle LC. Although I missed the LC email. Hence I owe you Phil comments :-) The Trickle I-D I am looking at is http://tools.ietf.org/html/draft-ietf-roll-trickle-02 The document is short - 11 pages long, that is excellent! > Trickle sends all messages to the local broadcast address. In IPv6 no broadcast... so probably a multicast address with link-local scope would be better appropriated? Maybe the same used by RPL? Maybe the all-nodes multicast address with link scope? > 1. When an interval begins, Trickle resets c to 0 and sets t to a > random point in the interval I think it would be good to refer to a randomness thought, like when random is not as random as one would expect - if all nodes use the same randomness algorithm there may be a risk that all nodes have same 't' at powerup - risking all transmitters to send simultaneously at time t, making noise. It may not have occured in practice though. > 3. At time t, Trickle transmits if and only if counter c is less > than the redundancy constant k. Advice to set k follows, but it would have been good to see it near here prior to its use. > In general, it is much more desirable to set k to a high value (e.g., > 5 or 10) than infinity. Hmmm... sounds as if infinity was not 'high'. > a specification should say "the default value of Imin is 4 times the > worst case link layer latency" But RPL puts Imin as (2^DIOIntervalMin)ms, which is an exponential, which may lead to very large spaces near the max. Would the algorithm still work if DIOIntervalMin were 254 and Imin 2^254? And Imax 2^255, or so. Probably yes, just a comment. These are my comments, I hope useful. Alex _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Mon Aug 2 16:01:05 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB64E3A69FF for ; Mon, 2 Aug 2010 16:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.342 X-Spam-Level: X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hl0AeF7xlxX9 for ; Mon, 2 Aug 2010 16:01:04 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 502163A694D for ; Mon, 2 Aug 2010 16:01:04 -0700 (PDT) Received: from [172.27.75.91] by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Og40h-0002Yz-J3; Mon, 02 Aug 2010 16:01:31 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Mon, 2 Aug 2010 16:01:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> References: <4C57317E.3070900@gmail.com> To: Yoav Ben-Yehezkel X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 5e15904e367bf57319d290d73554c551 Cc: ROLL WG Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Aug 2010 23:01:05 -0000 On Aug 2, 2010, at 2:15 PM, Yoav Ben-Yehezkel wrote: > Hi, >=20 > I'd like to support and add to Alex's note on link local broadcast = (that > appears in many places in the trickle draft). >=20 > To emphasize the problem with this, in RPL trickle timer messages are = sent > to All-RPL-Nodes multicast group, which is not a broadcast. >=20 > I suggest to clarify this issue. This text came from descriptions where Trickle ran directly on top of a = link layer: hence broadcast rather than multicast.=20 I agree that "broadcast" is the wrong term to use. I don't think = All-RPL-Nodes multicast group is the right answer, though: we don't want = to bind Trickle to RPL. I can add some descriptive text on what the = destination address should be. In short, it should be a suitable address = for the set of link-local nodes that care about the message. This could = be the All-RPL-Nodes address, the link local multicast address, a = broadcast address (e.g., for IPv4), etc. Do you agree? Phil= From yoav@yitran.com Mon Aug 2 21:26:26 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B13C3A67A7 for ; Mon, 2 Aug 2010 21:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.912 X-Spam-Level: X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GU+bbRSQWmHF for ; Mon, 2 Aug 2010 21:26:24 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by core3.amsl.com (Postfix) with SMTP id C33103A6781 for ; Mon, 2 Aug 2010 21:26:23 -0700 (PDT) Received: from source ([74.125.82.173]) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKTFeailTM47pvbptQMR8PowilNRBZF4Rw@postini.com; Mon, 02 Aug 2010 21:26:52 PDT Received: by mail-wy0-f173.google.com with SMTP id 11so4274439wyi.4 for ; Mon, 02 Aug 2010 21:26:50 -0700 (PDT) Received: by 10.227.128.4 with SMTP id i4mr5846045wbs.106.1280809609958; Mon, 02 Aug 2010 21:26:49 -0700 (PDT) From: Yoav Ben-Yehezkel References: <4C57317E.3070900@gmail.com> <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> In-Reply-To: <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcsylqevOTSGiFjxQ56b7AXMtUOR6wALRrgw Date: Tue, 3 Aug 2010 07:26:47 +0300 Message-ID: To: Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Cc: ROLL WG Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 04:26:26 -0000 Thanks Phil, I wasn't intending to say trickle only works for All-RPL-nodes... I meant this as an example where trickle is not used for broadcast. I completely agree with you. Regards, Yoav -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: Tuesday, August 03, 2010 2:02 AM To: Yoav Ben-Yehezkel Cc: Alexandru Petrescu; ROLL WG Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC On Aug 2, 2010, at 2:15 PM, Yoav Ben-Yehezkel wrote: > Hi, > > I'd like to support and add to Alex's note on link local broadcast (that > appears in many places in the trickle draft). > > To emphasize the problem with this, in RPL trickle timer messages are sent > to All-RPL-Nodes multicast group, which is not a broadcast. > > I suggest to clarify this issue. This text came from descriptions where Trickle ran directly on top of a link layer: hence broadcast rather than multicast. I agree that "broadcast" is the wrong term to use. I don't think All-RPL-Nodes multicast group is the right answer, though: we don't want to bind Trickle to RPL. I can add some descriptive text on what the destination address should be. In short, it should be a suitable address for the set of link-local nodes that care about the message. This could be the All-RPL-Nodes address, the link local multicast address, a broadcast address (e.g., for IPv4), etc. Do you agree? Phil From yoav@yitran.com Mon Aug 2 22:40:55 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4383D3A6A4D for ; Mon, 2 Aug 2010 22:40:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.921 X-Spam-Level: X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OolZn-fTJUMj for ; Mon, 2 Aug 2010 22:40:51 -0700 (PDT) Received: from na3sys009aog106.obsmtp.com (na3sys009aog106.obsmtp.com [74.125.149.77]) by core3.amsl.com (Postfix) with SMTP id F22373A6A01 for ; Mon, 2 Aug 2010 22:40:36 -0700 (PDT) Received: from source ([74.125.82.48]) by na3sys009aob106.postini.com ([74.125.148.12]) with SMTP ID DSNKTFer2Ek7UKP6AmuBkA+zXvxcq/oFyZFN@postini.com; Mon, 02 Aug 2010 22:41:05 PDT Received: by mail-ww0-f48.google.com with SMTP id 39so715532wwb.17 for ; Mon, 02 Aug 2010 22:40:40 -0700 (PDT) Received: by 10.227.136.146 with SMTP id r18mr5659884wbt.53.1280814040320; Mon, 02 Aug 2010 22:40:40 -0700 (PDT) From: Yoav Ben-Yehezkel References: <4C57317E.3070900@gmail.com> <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> bc58199e3b35de85c3e16aec79b13992@mail.gmail.com In-Reply-To: bc58199e3b35de85c3e16aec79b13992@mail.gmail.com MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: AcsylqevOTSGiFjxQ56b7AXMtUOR6wALRrgwAAKEq9A= Date: Tue, 3 Aug 2010 08:40:37 +0300 Message-ID: <3895b8f23b1fa4216210be0d92c8d064@mail.gmail.com> To: Yoav Ben-Yehezkel , Philip Levis Content-Type: text/plain; charset=ISO-8859-1 Cc: ROLL WG Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 05:40:55 -0000 One more thing - Maybe in your description you should consider also saying that trickle can also be used by link layers when the destination is broadcast or multicast. As you've noted trickle is a mechanism that doesn't really have to be bound to RPL nor to IP. What do you think? Regards, Yoav -----Original Message----- From: Yoav Ben-Yehezkel [mailto:yoav@yitran.com] Sent: Tuesday, August 03, 2010 7:27 AM To: 'Philip Levis' Cc: 'Alexandru Petrescu'; 'ROLL WG' Subject: RE: [Roll] Some comments on Trickle I-D as response to Trickle LC Thanks Phil, I wasn't intending to say trickle only works for All-RPL-nodes... I meant this as an example where trickle is not used for broadcast. I completely agree with you. Regards, Yoav -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: Tuesday, August 03, 2010 2:02 AM To: Yoav Ben-Yehezkel Cc: Alexandru Petrescu; ROLL WG Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC On Aug 2, 2010, at 2:15 PM, Yoav Ben-Yehezkel wrote: > Hi, > > I'd like to support and add to Alex's note on link local broadcast (that > appears in many places in the trickle draft). > > To emphasize the problem with this, in RPL trickle timer messages are sent > to All-RPL-Nodes multicast group, which is not a broadcast. > > I suggest to clarify this issue. This text came from descriptions where Trickle ran directly on top of a link layer: hence broadcast rather than multicast. I agree that "broadcast" is the wrong term to use. I don't think All-RPL-Nodes multicast group is the right answer, though: we don't want to bind Trickle to RPL. I can add some descriptive text on what the destination address should be. In short, it should be a suitable address for the set of link-local nodes that care about the message. This could be the All-RPL-Nodes address, the link local multicast address, a broadcast address (e.g., for IPv4), etc. Do you agree? Phil From jpv@cisco.com Mon Aug 2 23:28:29 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 628EF3A6A4A for ; Mon, 2 Aug 2010 23:28:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.517 X-Spam-Level: X-Spam-Status: No, score=-9.517 tagged_above=-999 required=5 tests=[AWL=-0.878, BAYES_00=-2.599, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZXTgMXyLFOU for ; Mon, 2 Aug 2010 23:28:28 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6C8403A6903 for ; Mon, 2 Aug 2010 23:28:28 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEZUV0yrRN+J/2dsb2JhbACgCHGnRZtVgwMIgi4EiH+CPg X-IronPort-AV: E=Sophos;i="4.55,308,1278288000"; d="scan'208";a="234623062" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 03 Aug 2010 06:28:56 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o736Smqr013957; Tue, 3 Aug 2010 06:28:56 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Aug 2010 08:28:51 +0200 Received: from [192.168.1.10] ([10.61.87.54]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Aug 2010 08:28:51 +0200 Message-Id: From: JP Vasseur To: "dominique.barthel@orange-ftgroup.com> In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Aug 2010 08:28:51 +0200 References: <8E09C72DBC577D489F13A71228C0B7BF017977BD@ftrdmel0.rd.francetelecom.fr> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Aug 2010 06:28:51.0538 (UTC) FILETIME=[2382AB20:01CB32D5] Cc: ROLL WG Subject: Re: [Roll] Question on path cost propagation in the DODAG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 06:28:29 -0000 On Aug 2, 2010, at 10:43 PM, Philip Levis wrote: > > On Aug 2, 2010, at 1:31 PM, > wrote: > >> Hello Phil, all, >> >> Our mutual questions and ensuing discussion at the IETF78 meeting >> in Maastricht uncovered a different understanding of the way path >> costs are propagated in the DODAG. >> >> To the whole Working Group benefit, here's the discussion again. >> >> Let's suppose that node X has selected node A as its preferred >> parent, and nodes B and C as alternate parents. In addition, let's >> suppose node Y is a child for node X. >> >> During the life of the network, path costs propagated by DIOs are >> likely to fluctuate while the ranks and parenthood relationship are >> kept more stable, by only updating them on persistent and >> significant changes in costs (see [1]). >> >> The question is, what metric should X advertise in its own DIOs to Y? >> * answer 1) >> X should always advertize the cost derived from that of node A, no >> matter what B and C advertize, because A is the preferred parent of >> X. >> >> * answer 2) >> X should advertize the best cost derived from its complete current >> parent set, as in a distance vector routing protocol. Because B and >> C are likely to be used as next-hops in addition to A (low-power >> and lossy links come and go), it is right to somehow take them into >> account in the cost propagated to Y. >> >> * answer 3) >> This decision is left to the implementer. >> >> I couldn't find in RPL -11 any text providing an answer to this >> question. >> I'm curious to hear opinions from the Working Group, notably those >> who have implemented RPL? >> Note that in RPL-11, _the_ preferred parent can actually be a set >> of parents [2]. >> Thanks, > > > I think the correct answer is 1). > > Note that the transmission-side damping is RECOMMENDED: a receiver > can simply defer decisions, e.g., using hysteresis. Agree with Phil but RPL is open to this. One may define an OF with a different policy. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Tue Aug 3 00:28:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCF3B3A6A7C for ; Tue, 3 Aug 2010 00:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.595 X-Spam-Level: X-Spam-Status: No, score=-1.595 tagged_above=-999 required=5 tests=[AWL=0.654, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dI3P22cu-akh for ; Tue, 3 Aug 2010 00:28:28 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id DA7613A67FD for ; Tue, 3 Aug 2010 00:28:26 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id BD304940055; Tue, 3 Aug 2010 09:28:48 +0200 (CEST) Message-ID: <4C57C52C.8070007@gmail.com> Date: Tue, 03 Aug 2010 09:28:44 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Philip Levis References: <4C57317E.3070900@gmail.com> <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> In-Reply-To: <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100802-1, 02/08/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 07:28:29 -0000 Le 03/08/2010 01:01, Philip Levis a écrit : > > On Aug 2, 2010, at 2:15 PM, Yoav Ben-Yehezkel wrote: > >> Hi, >> >> I'd like to support and add to Alex's note on link local broadcast >> (that appears in many places in the trickle draft). >> >> To emphasize the problem with this, in RPL trickle timer messages >> are sent to All-RPL-Nodes multicast group, which is not a >> broadcast. >> >> I suggest to clarify this issue. > > This text came from descriptions where Trickle ran directly on top of > a link layer: hence broadcast rather than multicast. > > I agree that "broadcast" is the wrong term to use. I don't think > All-RPL-Nodes multicast group is the right answer, though: we don't > want to bind Trickle to RPL. Ok, but would one want Trickle to send to all-nodes mcast address and RPL to send to all-rpl nodes? - they're different addresses. > I can add some descriptive text on what the destination address > should be. In short, it should be a suitable address for the set of > link-local nodes that care about the message. Sounds reasonable for IPv6 - the nodes interested in the message should join the group, and with MLD. I hope RPL says so, otherwise I'll have to suggest it. (for all-nodes: the nodes join it by default because they run ND, but they don't join by default all-rpl if no spec requires them to.) > This could be the All-RPL-Nodes address, the link local multicast > address, a broadcast address (e.g., for IPv4), etc. Do you agree? I am not sure it is a good idea to talk both IPv4 and IPv6 in the same Trickle draft. I think it is an unnecessary problem to mention IPv4 in this context, right now. Alex > > Phil From alexandru.petrescu@gmail.com Tue Aug 3 00:42:47 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 267FC3A67AF for ; Tue, 3 Aug 2010 00:42:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.86 X-Spam-Level: X-Spam-Status: No, score=-0.86 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_05=-1.11, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BilZUd0I9r49 for ; Tue, 3 Aug 2010 00:42:46 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id DC5983A659C for ; Tue, 3 Aug 2010 00:42:44 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 762B1940091 for ; Tue, 3 Aug 2010 09:43:08 +0200 (CEST) Message-ID: <4C57C888.8060707@gmail.com> Date: Tue, 03 Aug 2010 09:43:04 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: ROLL WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100802-1, 02/08/2010), Outbound message X-Antivirus-Status: Clean Subject: [Roll] Comment about RPL nodes joining the all-rpl multicast address X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 07:42:47 -0000 Comments about RPL nodes joining the all-rpl multicast address Are the RPL nodes in RPL -11 document joining the all-rpl multicast address? I think the spec should say so, otherwise they won't receive the messages sent to it. The closest I could find is this: > As is traditional, a listener uses a protocol such as MLD with a > router to register to a multicast group. Is there some more specific text about joining that group? I think the spec should be clearer and require the node to join this multicast group, with the explicit name of all-rpl nodes. It could leave the method of joining as MAY (e.g. MLD, or setting up local filters). Example text: "all RPL nodes MUST join the multicast group all-rpl nodes. This operation MAY be realized with MLDv2, local filters, or other method". (without joining the group, the message is not delivered to it). ----- In addition, it may be advantageous for an RPL node to join the solicited-node multicast address, and send DIS to it. For example, current text says: > The DODAG Information Solicitation (DIS) message may be used to > solicit a DODAG Information Object from a RPL node. Its use is > analogous to that of a Router Solicitation as specified in IPv6 > Neighbor Discovery Ok, RS is some times sent to the solicited-node multicast address - will the DIS too? Alex From yoav@yitran.com Tue Aug 3 04:22:29 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB6C13A682E for ; Tue, 3 Aug 2010 04:22:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.719 X-Spam-Level: X-Spam-Status: No, score=-4.719 tagged_above=-999 required=5 tests=[AWL=-1.157, BAYES_40=-0.185, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6ygXM+w6ax8 for ; Tue, 3 Aug 2010 04:22:28 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with SMTP id 5FFEC3A695D for ; Tue, 3 Aug 2010 04:22:28 -0700 (PDT) Received: from source ([74.125.82.177]) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKTFf8DxBQ172JztNq06k14MTBdJgLJC39@postini.com; Tue, 03 Aug 2010 04:22:57 PDT Received: by mail-wy0-f177.google.com with SMTP id 19so631563wyf.36 for ; Tue, 03 Aug 2010 04:22:55 -0700 (PDT) Received: by 10.227.20.77 with SMTP id e13mr6224732wbb.12.1280834575577; Tue, 03 Aug 2010 04:22:55 -0700 (PDT) From: Yoav Ben-Yehezkel MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acsy/jcMvZHVG61GQ4OheA2K32Vq+w== Date: Tue, 3 Aug 2010 14:22:53 +0300 Message-ID: <54b97e49bac0f647df2b26346de178e4@mail.gmail.com> To: ROLL WG Content-Type: multipart/alternative; boundary=002215b03aa2e4b27f048ce989a5 Subject: [Roll] small comment on DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 11:22:30 -0000 --002215b03aa2e4b27f048ce989a5 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, In Section 6.5.1 the format of the DAO-ACK BO is given with =93option(s)=94 field. Then in section 6.5.3 it says there are no options supported by DAO-ACK. Is this OK? Are those future options that may be supported? See related text below. Thanks, Yoav =93 6.5.1. Format of the DAO-ACK Base Object 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RPLInstanceID |D| Reserved | DAOSequence | Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + DODAGID* + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Option(s)... +-+-+-+-+-+-+-+-+ =85 6.5.3. DAO-ACK Options This specification does not define any options to be carried by the DAO-ACK message. =93 --002215b03aa2e4b27f048ce989a5 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

In Section 6.5.1 the format of the DAO-ACK BO is giv= en with =93option(s)=94 field. Then in section 6.5.3 it says there are no options supported by DAO-= ACK. Is this OK? Are those future options that may be supported?

=A0

See related text below.

=A0

Thanks,

Yoav

=A0

=A0

=93

6.5.1.=A0 Format of the DAO-ACK Base Object

=A0

=A0=A0=A0=A0=A0=A0=A0 0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 1=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 2=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0 3

=A0=A0=A0=A0=A0=A0=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0=A0=A0=A0=A0=A0 | RPLInstanceID |D|=A0 Reserved=A0=A0 |=A0 DAOSequence=A0 |=A0=A0=A0 Status= =A0=A0=A0=A0 |

=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0|

=A0=A0=A0=A0=A0=A0 +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +

=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |

=A0=A0=A0=A0=A0=A0 +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0 DODAGID*=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 +

=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0|

=A0=A0=A0=A0=A0=A0 +=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +

=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |

=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

=A0=A0=A0=A0=A0=A0 |=A0=A0 Option(s)...

=A0=A0=A0=A0=A0=A0 +-+-+-+-+-+-+-+-+

=85

6.5.3.=A0 DAO-ACK Options
=A0
=A0=A0 This specification does not define any options to be carried b=
y the
=A0=A0 DAO-ACK message.
=93



=A0
--002215b03aa2e4b27f048ce989a5-- From jpv@cisco.com Tue Aug 3 05:26:20 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5AA23A6836 for ; Tue, 3 Aug 2010 05:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.488 X-Spam-Level: X-Spam-Status: No, score=-10.488 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nwt5c+rjtEX2 for ; Tue, 3 Aug 2010 05:26:18 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E2A1B3A67A2 for ; Tue, 3 Aug 2010 05:26:17 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAHqnV0yrR7Hu/2dsb2JhbACBRJ5GcaZ0m1uFOQSJAoJA X-IronPort-AV: E=Sophos;i="4.55,309,1278288000"; d="scan'208,217";a="567792125" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 03 Aug 2010 12:26:46 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o73CQiHf004634; Tue, 3 Aug 2010 12:26:46 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Aug 2010 14:26:42 +0200 Received: from [192.168.1.10] ([10.61.87.54]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Aug 2010 14:26:41 +0200 Message-Id: <5307326E-65DD-415B-B9C8-9884A1E06AA8@cisco.com> From: JP Vasseur To: Yoav Ben-Yehezkel In-Reply-To: <54b97e49bac0f647df2b26346de178e4@mail.gmail.com> Content-Type: multipart/alternative; boundary=Apple-Mail-101--263993261 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Aug 2010 14:26:40 +0200 References: <54b97e49bac0f647df2b26346de178e4@mail.gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Aug 2010 12:26:41.0656 (UTC) FILETIME=[20B2AF80:01CB3307] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17546.007 X-TM-AS-Result: No--30.784000-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] small comment on DAO ACK X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 12:26:20 -0000 --Apple-Mail-101--263993261 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Yoav, What the text says is that options may be defined in the future but no =20= options for DAO-ACK are defined in this document. Thanks. JP. On Aug 3, 2010, at 1:22 PM, Yoav Ben-Yehezkel wrote: > Hi, > > In Section 6.5.1 the format of the DAO-ACK BO is given with =20 > =93option(s)=94 field. Then in section 6.5.3 it says there are no =20 > options supported by DAO-ACK. Is this OK? Are those future options =20 > that may be supported? > > See related text below. > > Thanks, > Yoav > > > =93 > 6.5.1. Format of the DAO-ACK Base Object > > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 =20= > 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > | RPLInstanceID |D| Reserved | DAOSequence | =20 > Status | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > =20 > | | > =20 > + + > =20 > | | > + =20 > DODAGID* + > =20 > | | > =20 > + + > =20 > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-=20= > +-+ > | Option(s)... > +-+-+-+-+-+-+-+-+ > =85 > 6.5.3. DAO-ACK Options > > This specification does not define any options to be carried by the > DAO-ACK message. > =93 > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-101--263993261 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Hi = Yoav,

What the text says is that options may be = defined in the future but no options for DAO-ACK are defined in this = document.

Thanks.

JP.

On Aug 3, 2010, at 1:22 PM, Yoav Ben-Yehezkel = wrote:

Hi,

In Section 6.5.1 the format of the DAO-ACK BO is = given with =93option(s)=94 field. Then in section 6.5.3 it says there = are no options supported by DAO-ACK. Is this OK? Are those future = options that may be supported?

See related text below.

Thanks,

Yoav

 

6.5.1.  Format of the DAO-ACK Base = Object

 

       | RPLInstanceID |D|  = Reserved   |  DAOSequence  |    = Status     |
       = |            &= nbsp;           &nb= sp;            = ;            &= nbsp;    =          |
       = |            &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp; |
       = +            &= nbsp;           &nb= sp;   = DODAGID*           =             &n= bsp;   +
       = |            &= nbsp;     =             &n= bsp;           &nbs= p;            =         |
       = |            &= nbsp;           &nb= sp;            = ;            &= nbsp;           &nb= sp; |
       = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   = Option(s)...
       = +-+-+-+-+-+-+-+-+
=85
6.5.3.  DAO-ACK Options
   This specification does not define any =
options to be carried by the
   DAO-ACK =
message.
=93

Roll@ietf.org
From: JP Vasseur To: JP Vasseur In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-111--259853019 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Aug 2010 15:35:41 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Aug 2010 13:35:41.0556 (UTC) FILETIME=[C4454B40:01CB3310] Cc: ROLL WG Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 13:35:25 -0000 --Apple-Mail-111--259853019 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Please find below comments on draft-ietf-roll-trickle-02 (search for =20 JP>). Co-chair hat on (shepherding the document) Networking Working Group P. Levis Internet-Draft Stanford University Intended status: Informational T. Clausen JP> So far good consensus to move to Std track. Let's wait until end of LC. Expires: January 7, 2011 LIX, Ecole Polytechnique J. =20= Hui Arch Rock =20 Corporation O. =20 Gnawali Stanford =20 University J. =20= Ko Johns Hopkins =20 University July 6, =20 2010 The Trickle Algorithm draft-ietf-roll-trickle-02 Abstract The Trickle algorithm allows wireless nodes to exchange information JP> Not restricted to wireless. Even if we do not use some features, =20 dynamic timer adjustments are still useful in PLC/wired environments. in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour JP> I would suggest to be more generic (not specify "hour", "mn", since that all depends on the parameter settings) when information does not change. A simple suppression mechanism and transmission point selection allows Trickle's communication rate to scale logarithmically with density. This document describes Trickle JP> s/trickle/the trickle algorithm and considerations in its use. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with =20= the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six =20 months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Levis, et al. Expires January 7, 2011 [Page 1] =0C Internet-Draft draft-ietf-roll-trickle-02 July 2010 This Internet-Draft will expire on January 7, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with =20 respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Levis, et al. Expires January 7, 2011 [Page 2] =0C Internet-Draft draft-ietf-roll-trickle-02 July 2010 Table of Contents 1. =20 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. =20 Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Trickle Algorithm =20 Overview . . . . . . . . . . . . . . . . . . 3 4. Trickle =20 Algorithm . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Parameters and =20 Variables . . . . . . . . . . . . . . . . . 4 4.2. Algorithm =20 Description . . . . . . . . . . . . . . . . . . . 5 5. Using =20 Trickle . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Operational =20 Considerations . . . . . . . . . . . . . . . . . . 6 6.1. Mismatched redundancy =20 constants . . . . . . . . . . . . . . 6 6.2. Mismatched =20 Imin . . . . . . . . . . . . . . . . . . . . . . 6 6.3. Mismatched =20 Imax . . . . . . . . . . . . . . . . . . . . . . 7 6.4. Mismatched =20 definitions . . . . . . . . . . . . . . . . . . 7 6.5. Specifying the constant =20 k . . . . . . . . . . . . . . . . . 7 6.6. Relationship between k and =20 Imin . . . . . . . . . . . . . . 7 6.7. Tweaks and improvements to =20 Trickle . . . . . . . . . . . . 8 7. =20 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA =20 Considerations . . . . . . . . . . . . . . . . . . . . . . 8 9. Security =20 Considerations . . . . . . . . . . . . . . . . . . . . 8 10. =20 References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative =20 References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative =20 References . . . . . . . . . . . . . . . . . . 9 Authors' =20 Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Levis, et al. Expires January 7, 2011 [Page 3] =0C Internet-Draft draft-ietf-roll-trickle-02 July 2010 1. Introduction The Trickle algorithm is designed for wireless networks. JP> please use the LLN terminology and point to [I-D-ietf.roll-=20 terminology] ID. It establishes a density-aware local broadcast with an underlying consistency model that guides when a node communicates. When a node's data does not agree JP> you may want to clarify the term "agree" with its neighbors, it communicates quickly to resolve the inconsistency. JP> Please define "inconsistency" (an example should suffice) When nodes agree, they slow their communication rate exponentially, such that nodes send at most a few packets per hour. JP> See comments on "hour" Instead of flooding a network with packets, the algorithm controls the send rate so each node hears a small JP> avoid "small", "large", ... it is all relative. trickle of packets, just enough to stay consistent. Furthermore, by relying only on local broadcasts, JP> broadcast or multicast Trickle handles network re- population, JP> Define "re-population" is robust to network transience, loss, and disconnection, and requires very little state (implementations use 4-11 bytes). JP> Mention that current implementations typically requires .... While Trickle was originally designed for reprogramming protocols (where the data is the code of the program being updated), =20 experience has shown it to be a powerful mechanism that can be applied to wide range of protocol design problems, including control traffic timing, multicast propagation, and route discovery. This document describes the Trickle algorithm and provides =20 guidelines for its use. It also states requirements for protocol =20 specifications that use Trickle. This document does not provide results on Trickle's performance or behavior, nor does it explain the algorithm's design in detail: interested readers should refer to [Levis04] and [Levis08]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in =20= RFC 2119 [RFC2119]. 3. Trickle Algorithm Overview Trickle's basic primitive is simple: every so often, a node =20 transmits code metadata JP> s/code metadata/information (e.g. routing protocol, software =20 updates, ...) if it has not heard a few other nodes transmit the same thing. JP> s/thing/information This allows Trickle to scale to thousand-fold variations in network density, quickly propagate updates, distribute transmission load evenly, be robust to transient disconnections, handle network repopulations, and impose a maintenance overhead on the order of a few packets per hour. JP> same comment about "hour" Trickle sends all messages to the local broadcast address. JP> or multicast (to be updated throughout the document) There are Levis, et al. Expires January 7, 2011 [Page 4] =0C Internet-Draft draft-ietf-roll-trickle-02 July 2010 two possible results to a Trickle broadcast: either every node that hears the message is up to date, or a recipient detects the need for an update. Detection can be the result of either an out-of-date =20 node hearing someone has new code, or an updated node hearing someone has old code. JP> this comes from one application of trickle (code update), could =20 you make it more general (e.g. fresher information) As long as every node communicates somehow - either receives or transmits - the need for an update will be detected. For example, consider a simple case where "up to date" is defined by version numbers (e.g., network configuration). If node A broadcasts that it has version V, but B has version V+1, then B knows that A needs an update. Similarly, if B broadcasts that it has V+1 JP> s/V+1/version V+1 , A knows that it needs an update. If B broadcasts updates, then all of its neighbors can receive them without having to advertise their need. Some of these recipients might not even have heard A's transmission. In this example, it does not matter who first transmits, A or B; either case will detect the inconsistency. All that matters is that some nodes communicate with one another at some nonzero rate. As long as the network is connected and there is some minimum communication rate for each node, the network will reach eventual consistency. The fact that communication can be either transmission or reception enables Trickle JP> s/Trickle/the Trickle algorithm to operate in sparse as well as dense networks. A single, disconnected node must transmit at the communication rate. In a lossless, single-hop network of size n, the sum of =20 transmissions over the network is the communication rate, so for each node it is 1/n. Sparser networks require more transmissions per node, but utilization of the radio channel over space will not increase. This is an important property in wireless networks, JP> and other shared media where the channel is a valuable shared resource. Additionally, reducing transmissions in dense networks conserves system energy. 4. Trickle Algorithm This section describes the Trickle algorithm. 4.1. Parameters and Variables A Trickle timer has three configuration parameters: the minimum interval size Imin, the maximum interval size Imax, and a redundancy constant k: o The minimum interval size is defined in units of time (e.g., milliseconds, seconds). For example, a protocol might define the minimum interval as 100 milliseconds. Levis, et al. Expires January 7, 2011 [Page 5] =0C Internet-Draft draft-ietf-roll-trickle-02 July 2010 o The maximum interval size is described as a number of doublings =20= of the minimum interval size (the base-2 log(max/min)). For =20 example, a protocol might define the maximum interval as 16. If the minimum interval is 100ms, then the maximum interval is 100ms * 65536, 6,553.6 seconds, or approximately 109 minutes. o The redundancy constant is a natural number (an integer greater than zero). JP> Could be equal to infinity (and encoded as 0) =3D> no suppression. In addition to these three parameters, Trickle maintains three variables: o I, the current interval size o t, a time within the current interval, and o c, a counter. 4.2. Algorithm Description The Trickle algorithm has five rules: 1. When an interval begins, Trickle resets c to 0 and sets t to a random point in the interval, taken from the range [I/2, I). JP> s/I)/I] 2. Whenever Trickle hears a transmission that is "consistent," it increments counter c. 3. At time t, Trickle transmits if and only if counter c is less than the redundancy constant k. 4. When an interval expires, JP> this may not be obvious first time you read it. interval=3Dt or I =20= (question was asked on the mailing list in the past). Trickle doubles the interval length. If this new interval length would be longer than Imax, Trickle sets the interval length I to be Imax. 5. If Trickle hears a transmission that is "inconsistent," the Trickle timer resets. If I is greater than Imin, JP> how could that happen that I < Imin? resetting a Trickle timer sets I to Imin and begins a new interval. If I is equal to Imin, resetting a Trickle timer does nothing. Trickle may also reset the timer in response to external "events." The terms consistent, inconsistent and event are in quotes because their meaning depends on the use of Trickle. 5. Using Trickle A protocol specification that uses Trickle MUST specify: Levis, et al. Expires January 7, 2011 [Page 6] =0C Internet-Draft draft-ietf-roll-trickle-02 July 2010 o Default values for Imin, Imax, and k. JP> s/Default values/Value Because link layers can vary widely in their properties, the default JP> remove "default" value of Imin should be specified in terms of the worst-case latency of a link layer transmission. For example, a specification should say "the default value of Imin is 4 times the worst case link layer latency" JP> may be worth how you define "latency" and should not say "the default value of Imin is 500 milliseconds." Worst case latency is the time until the first link-layer transmission of the frame assuming an idle channel (does not include backoff, virtual carrier sense, etc.). o What constitutes a "consistent" transmission. o What constitutes an "inconsistent" transmission. o What "events," if any, besides inconsistent transmissions that reset the Trickle timer. 6. Operational Considerations It is RECOMMENDED that a protocol which uses Trickle include mechanisms to inform nodes of configuration parameters at runtime. However, it is not always possible to do so. In the cases where different nodes have different configuration parameters, Trickle may have unintended behaviors. This section outlines some of those behaviors and operational considerations as educational exercises. 6.1. Mismatched redundancy constants If nodes do not agree on the redundancy constant k, then nodes with higher values of k will transmit more often than nodes with lower values of k. In some cases, this increased load can be independent of the density. For example, consider a network where all nodes but one have k=3D1, and this one node has k=3D2. The different node can = end up transmitting on every interval: it is maintaining a communication rate of 2 with only itself. Hence, the danger of mismatched k =20 values is uneven transmission load that can deplete the energy of some nodes. JP> Still this does not lead to interoperability issues. Don't we want to recommend consistent configuration ? If you agree, then these comments should go at the end of this section (or beginning) but =20= they apply to several kind of mismatches 6.2. Mismatched Imin If nodes do not agree on Imin, then some nodes, on hearing inconsistent messages, will transmit sooner than others. These faster nodes will have their intervals grow to similar size as the slower nodes within a single slow interval time, but in that period may suppress the slower nodes. However, such suppression will end after the first slow interval, when the nodes generally agree on the interval size. Hence, mismatched Imin values are usually not a Levis, et al. Expires January 7, 2011 [Page 7] =0C Internet-Draft draft-ietf-roll-trickle-02 July 2010 significant concern. 6.3. Mismatched Imax If nodes do not agree on Imax, then this can cause long-term =20 problems with transmission load. Nodes with small Imax values will transmit faster, suppressing those with larger Imax values. The nodes with larger Imax values, always suppressed, will never transmit. In the base case, when the network is consistent, this can cause long-term inequities in energy cost. 6.4. Mismatched definitions If nodes do not agree on what constitutes a consistent or inconsistent transmission, then Trickle may fail to operate =20 properly. For example, if a receiver thinks a transmission is consistent, but the transmitter (if in the receivers situation) would have thought =20= it inconsistent, then the receiver will not respond properly and inform the transmitter. This can lead the network to not reach a =20 consistent state. For this reason, unlike the configuration constants k, Imin, and Imax, consistency definitions should be clearly stated in the protocol and should not be configured at runtime. JP> I would suggest a MUST instead of a should in the sentence above. 6.5. Specifying the constant k There are some edge cases where a protocol may wish to use Trickle with its suppression disabled (k is set to infinity). In general, this approach is highly dangerous and it is NOT RECOMMENDED. JP> I would strongly suggest to soften this statement. Just explain the consequences. Disabling suppression means that every node will always send on =20 every interval, and can lead to congestion in dense networks. This approach is especially dangerous JP> same comment if many nodes reset their intervals at the same time. In general, it is much more desirable to set k to a high value (e.g., 5 or 10) than infinity. Typical values for k =20= are 1-5: these achieve a good balance between redundancy and low cost. JP> I would suggest to add refs here. Nevertheless, there are situations where a protocol may wish to turn off Trickle suppression. Because k is a natural number (Section 4.1), c=3D0 has no useful meaning. If a protocol allows k = to be dynamically configured, a value of 0 remains unused. For ease of debugging and packet inspection, having the parameter describe (c-1) JP> c-1 ? can be counter-productive. Instead, it is RECOMMENDED that =20 protocols which require turning off suppression reserve c=3D0 to mean =20 c=3Dinfinity. 6.6. Relationship between k and Imin Finally, a protocol SHOULD set k and Imin such that Imin is at least two to three as long as it takes to transmit k packets. Otherwise, if more than k nodes reset their intervals to Imin, the resulting Levis, et al. Expires January 7, 2011 [Page 8] =0C Internet-Draft draft-ietf-roll-trickle-02 July 2010 communication will lead to congestion and significant packet loss. Experimental results have shown that packet losses from congestion reduce Trickle's efficiency [Levis04]. JP> Well ... it is true in most networks, but may not be completely =20 applicable to non wireless networks though. You may want to mention it. 6.7. Tweaks and improvements to Trickle Trickle is based on a small number of simple, tightly integrated mechanisms that are highly robust to challenging network environments. >>In our experiences using Trickle, attempts to tweak its behavior are typically not worth the cost. As written, the algorithm is already highly efficient: further reductions in transmissions or response time come at the cost of failures in edge cases. Based on our experiences, we urge protocol designers to suppress the instinct to tweak or improve Trickle without a great deal of experimental evidence that the change does not violate its assumptions and break the algorithm in edge cases.<< JP> You may want to soften this statement. This warning in mind, Trickle is far from perfect. JP> nobody's perfect. Not needed in the document. For example, Trickle suppression typically leads sparser nodes to transmit more than denser ones; it is far from the optimal computation of a =20 minimum cover. However, in dynamic network environments such as wireless, the coordination needed to compute the optimal set of transmissions is typically much greater than the benefits it provides. One of the benefits of Trickle JP> s/Trickle/the Trickle algorithm is that it is so simple to implement and requires so little state yet operates so efficiently. Efforts to improve it should be weighed against the cost of increased complexity. 7. Acknowledgements JP> to be done 8. IANA Considerations This document has no IANA considerations. 9. Security Considerations This document has no security considerations. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Levis, et al. Expires January 7, 2011 [Page 9] =0C Internet-Draft draft-ietf-roll-trickle-02 July 2010 10.2. Informative References [Levis04] Levis, P., Patel, N., Culler, D., and S. Shenker, "Trickle: A Self-Regulating Algorithm for Code =20 Propagation and Maintenance in Wireless Sensor Networks"", =20 Proceedings of the First USENIX/ACM Symposium on Networked Systems Design and Implementation NSDI 2004, March 2004, . [Levis08] Levis, P., Brewer, E., Culler, D., Gay, D., Madden, S., Patel, N., Polastre, J., Shenker, S., Szewczyk, R., and =20= A. Woo, "The Emergence of a Networking Primitive in Wireless Sensor Networks", Communications of the ACM, v.51 n.7, July 2008, . Authors' Addresses Philip Levis Stanford University 358 Gates Hall, Stanford University Stanford, CA 94305 USA Phone: +1 650 725 9064 Email: pal@cs.stanford.edu Thomas Heide Clausen LIX, Ecole Polytechnique Phone: +33 6 6058 9349 Email: T.Clausen@computer.org Jonathan Hui Arch Rock Corporation 501 Snd St., Suite 410 San Francisco, CA 94107 USA Email: jhui@archrock.com Levis, et al. Expires January 7, 2011 [Page 10] =0C Internet-Draft draft-ietf-roll-trickle-02 July 2010 Omprakash Gnawali Stanford University S255 Clark Center, 318 Campus Drive Stanford, CA 94305 USA Phone: +1 650 725 6086 Email: gnawali@cs.stanford.edu JeongGil Ko Johns Hopkins University 3400 N. Charles St., 224 New Engineering Building Baltimore, MD 21218 USA Phone: +1 410 516 4312 Email: jgko@cs.jhu.edu Levis, et al. Expires January 7, 2011 [Page 11] =0C Thanks. JP. On Jul 28, 2010, at 10:05 AM, JP Vasseur wrote: > Dear WG, > > draft-ietf-roll-trickle-02 is stable and now ready for WG Last Call. > > This starts a 2-week Working Group last call ending on August 11 at =20= > 9:00am ET. > > Please send your comments to the authors and the list. > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-111--259853019 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Please find below comments = on draft-ietf-roll-trickle-02 (search for JP>).

Co-chair hat on = (shepherding the document)

Networking =
Working Group                                        P. Levis
Internet-Draft                                       Stanford University
Intended status: Informational                                T. =
Clausen
JP> So far good =
consensus to move to Std track. Let's wait until
end of LC.
Expires: January 7, 2011                        LIX, Ecole Polytechnique
                                                                  J. Hui
                                                   Arch Rock Corporation
                                                              O. Gnawali
                                                     Stanford University
                                                                   J. Ko
                                                Johns Hopkins University
                                                            July 6, 2010


                         The Trickle Algorithm
                       draft-ietf-roll-trickle-02

Abstract

   The Trickle algorithm allows wireless nodes to exchange information

JP> Not =
restricted to wireless. Even if we do not use some features, =
dynamic
timer =
adjustments are still useful in PLC/wired =
environments.
   in a highly robust, energy =
efficient, simple, and scalable manner.
   Dynamically adjusting transmission windows allows Trickle to spread
   new information on the scale of link-layer transmission times while
   sending only a few messages per hour 
JP> I would suggest to =
be more generic (not specify "hour", "mn", since 
that all depends on the parameter =
settings)
when information does not
   change.  A simple suppression mechanism and transmission point
   selection allows Trickle's communication rate to scale
   logarithmically with density.  This document describes =
Trickle 
JP> s/trickle/the trickle =
algorithm
and
   considerations in its use.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ie=
tf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.



Levis, et al.            Expires January 7, 2011                [Page 1]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


   This Internet-Draft will expire on January 7, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/lice=
nse-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.



































Levis, et al.            Expires January 7, 2011                [Page 2]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Trickle Algorithm Overview  . . . . . . . . . . . . . . . . . . 3
   4.  Trickle Algorithm . . . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  Parameters and Variables  . . . . . . . . . . . . . . . . . 4
     4.2.  Algorithm Description . . . . . . . . . . . . . . . . . . . 5
   5.  Using Trickle . . . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Operational Considerations  . . . . . . . . . . . . . . . . . . 6
     6.1.  Mismatched redundancy constants . . . . . . . . . . . . . . 6
     6.2.  Mismatched Imin . . . . . . . . . . . . . . . . . . . . . . 6
     6.3.  Mismatched Imax . . . . . . . . . . . . . . . . . . . . . . 7
     6.4.  Mismatched definitions  . . . . . . . . . . . . . . . . . . 7
     6.5.  Specifying the constant k . . . . . . . . . . . . . . . . . 7
     6.6.  Relationship between k and Imin . . . . . . . . . . . . . . 7
     6.7.  Tweaks and improvements to Trickle  . . . . . . . . . . . . 8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9



























Levis, et al.            Expires January 7, 2011                [Page 3]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


1.  Introduction

   The Trickle algorithm is designed for wireless networks. =
 
JP> please =
use the LLN terminology and point to [I-D-ietf.roll-terminology] =
ID.
It
   establishes a density-aware local broadcast with an underlying
   consistency model that guides when a node communicates.  When a
   node's data does not agree 
JP> you may want to clarify the =
term "agree"
with its neighbors, it communicates
   quickly to resolve the inconsistency.  
JP> Please define =
"inconsistency" (an example should =
suffice)
When nodes agree, they slow
   their communication rate exponentially, such that nodes send at most
   a few packets per hour.  
JP> See comments on =
"hour"
Instead of flooding a network with packets,
   the algorithm controls the send rate so each node hears a =
small
JP> avoid =
"small", "large", ... it is all relative.
   trickle of packets, just enough to stay consistent.  Furthermore, by
   relying only on local broadcasts, 
JP> broadcast or =
multicast
Trickle handles network re-
   population, 
JP> Define =
"re-population"
is robust to network transience, =
loss, and disconnection,
   and requires very little state (implementations use 4-11 bytes).

JP> Mention =
that current implementations typically requires =
.... 
   While Trickle was originally designed for reprogramming protocols
   (where the data is the code of the program being updated), experience
   has shown it to be a powerful mechanism that can be applied to wide
   range of protocol design problems, including control traffic timing,
   multicast propagation, and route discovery.

   This document describes the Trickle algorithm and provides guidelines
   for its use.  It also states requirements for protocol specifications
   that use Trickle.  This document does not provide results on
   Trickle's performance or behavior, nor does it explain the
   algorithm's design in detail: interested readers should refer to
   [Levis04] and [Levis08].


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].


3.  Trickle Algorithm Overview

   Trickle's basic primitive is simple: every so often, a node transmits
   code metadata 
JP> s/code metadata/information =
(e.g. routing protocol, software updates, =
...)

if it has not heard a few other nodes transmit =
the same
   thing.  
JP> s/thing/information
This allows =
Trickle to scale to thousand-fold variations in
   network density, quickly propagate updates, distribute transmission
   load evenly, be robust to transient disconnections, handle network
   repopulations, and impose a maintenance overhead on the order of a
   few packets per hour.
JP> same comment about =
"hour"
   Trickle sends all messages to the local broadcast address. =
 
JP> or =
multicast (to be updated throughout the =
document)

There are



Levis, et al.            Expires January 7, 2011                [Page 4]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


   two possible results to a Trickle broadcast: either every node that
   hears the message is up to date, or a recipient detects the need for
   an update.  Detection can be the result of either an out-of-date node
   hearing someone has new code, or an updated node hearing someone has
   old code.  
JP> this comes from one application =
of trickle (code update), could you make it
more general (e.g. fresher =
information)
As long as every node communicates =
somehow - either
   receives or transmits - the need for an update will be detected.

   For example, consider a simple case where "up to date" is defined by
   version numbers (e.g., network configuration).  If node A broadcasts
   that it has version V, but B has version V+1, then B knows that A
   needs an update.  Similarly, if B broadcasts that it has =
V+1
JP> =
s/V+1/version V+1
, A knows
   that it needs an update.  If B broadcasts updates, then all of its
   neighbors can receive them without having to advertise their need.
   Some of these recipients might not even have heard A's transmission.

   In this example, it does not matter who first transmits, A or B;
   either case will detect the inconsistency.  All that matters is that
   some nodes communicate with one another at some nonzero rate.  As
   long as the network is connected and there is some minimum
   communication rate for each node, the network will reach eventual
   consistency.

   The fact that communication can be either transmission or reception
   enables Trickle 
JP> s/Trickle/the Trickle =
algorithm
to operate in sparse as well as dense networks. =
 A
   single, disconnected node must transmit at the communication rate.
   In a lossless, single-hop network of size n, the sum of transmissions
   over the network is the communication rate, so for each node it is
   1/n.  Sparser networks require more transmissions per node, but
   utilization of the radio channel over space will not increase.  This
   is an important property in wireless networks, 
JP> and other shared =
media
where the channel is a
   valuable shared resource.  Additionally, reducing transmissions in
   dense networks conserves system energy.


4.  Trickle Algorithm

   This section describes the Trickle algorithm.

4.1.  Parameters and Variables

   A Trickle timer has three configuration parameters: the minimum
   interval size Imin, the maximum interval size Imax, and a redundancy
   constant k:

   o  The minimum interval size is defined in units of time (e.g.,
      milliseconds, seconds).  For example, a protocol might define the
      minimum interval as 100 milliseconds.




Levis, et al.            Expires January 7, 2011                [Page 5]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


   o  The maximum interval size is described as a number of doublings of
      the minimum interval size (the base-2 log(max/min)).  For example,
      a protocol might define the maximum interval as 16.  If the
      minimum interval is 100ms, then the maximum interval is 100ms *
      65536, 6,553.6 seconds, or approximately 109 minutes.

   o  The redundancy constant is a natural number (an integer greater
      than zero).
JP> Could be equal to infinity (and encoded as 0) =3D> no =
suppression.

   In addition to these three parameters, Trickle maintains three
   variables:

   o  I, the current interval size

   o  t, a time within the current interval, and

   o  c, a counter.

4.2.  Algorithm Description

   The Trickle algorithm has five rules:

   1.  When an interval begins, Trickle resets c to 0 and sets t to a
       random point in the interval, taken from the range [I/2, I).

JP> =
s/I)/I]
   2.  Whenever Trickle hears a transmission that is "consistent," it
       increments counter c.

   3.  At time t, Trickle transmits if and only if counter c is less
       than the redundancy constant k.

   4.  When an interval expires, 
JP> this may not be obvious first =
time you read it. interval=3Dt or I (question
was asked on the mailing list in the =
past).
Trickle doubles the interval length.
       If this new interval length would be longer than Imax, Trickle
       sets the interval length I to be Imax.

   5.  If Trickle hears a transmission that is "inconsistent," the
       Trickle timer resets.  If I is greater than Imin, 
JP> how could that =
happen that I <  Imin?
resetting a
       Trickle timer sets I to Imin and begins a new interval.  If I is
       equal to Imin, resetting a Trickle timer does nothing.  Trickle
       may also reset the timer in response to external "events."

   The terms consistent, inconsistent and event are in quotes because
   their meaning depends on the use of Trickle.


5.  Using Trickle

   A protocol specification that uses Trickle MUST specify:



Levis, et al.            Expires January 7, 2011                [Page 6]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


   o  Default values for Imin, Imax, and k.  
JP> s/Default =
values/Value
Because link layers can
      vary widely in their properties, the default 
JP> remove =
"default"
value of Imin should
      be specified in terms of the worst-case latency of a link layer
      transmission.  For example, a specification should say "the
      default value of Imin is 4 times the worst case link layer
      latency" 
JP> may be worth how you define =
"latency"
and should not say "the default value of Imin =
is 500
      milliseconds."  Worst case latency is the time until the first
      link-layer transmission of the frame assuming an idle channel
      (does not include backoff, virtual carrier sense, etc.).

   o  What constitutes a "consistent" transmission.

   o  What constitutes an "inconsistent" transmission.

   o  What "events," if any, besides inconsistent transmissions that
      reset the Trickle timer.


6.  Operational Considerations

   It is RECOMMENDED that a protocol which uses Trickle include
   mechanisms to inform nodes of configuration parameters at runtime.
   However, it is not always possible to do so.  In the cases where
   different nodes have different configuration parameters, Trickle may
   have unintended behaviors.  This section outlines some of those
   behaviors and operational considerations as educational exercises.

6.1.  Mismatched redundancy constants

   If nodes do not agree on the redundancy constant k, then nodes with
   higher values of k will transmit more often than nodes with lower
   values of k.  In some cases, this increased load can be independent
   of the density.  For example, consider a network where all nodes but
   one have k=3D1, and this one node has k=3D2.  The different node can =
end
   up transmitting on every interval: it is maintaining a communication
   rate of 2 with only itself.  Hence, the danger of mismatched k values
   is uneven transmission load that can deplete the energy of some
   nodes.
JP> Still this does not lead to interoperability =
issues.
Don't we want to recommend consistent configuration ? If you =
agree, then
these comments should go at the end of =
this section (or beginning) but they
apply to =
several kind of mismatches

6.2.  Mismatched Imin

   If nodes do not agree on Imin, then some nodes, on hearing
   inconsistent messages, will transmit sooner than others.  These
   faster nodes will have their intervals grow to similar size as the
   slower nodes within a single slow interval time, but in that period
   may suppress the slower nodes.  However, such suppression will end
   after the first slow interval, when the nodes generally agree on the
   interval size.  Hence, mismatched Imin values are usually not a



Levis, et al.            Expires January 7, 2011                [Page 7]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


   significant concern.

6.3.  Mismatched Imax

   If nodes do not agree on Imax, then this can cause long-term problems
   with transmission load.  Nodes with small Imax values will transmit
   faster, suppressing those with larger Imax values.  The nodes with
   larger Imax values, always suppressed, will never transmit.  In the
   base case, when the network is consistent, this can cause long-term
   inequities in energy cost.

6.4.  Mismatched definitions

   If nodes do not agree on what constitutes a consistent or
   inconsistent transmission, then Trickle may fail to operate properly.
   For example, if a receiver thinks a transmission is consistent, but
   the transmitter (if in the receivers situation) would have thought it
   inconsistent, then the receiver will not respond properly and inform
   the transmitter.  This can lead the network to not reach a consistent
   state.  For this reason, unlike the configuration constants k, Imin,
   and Imax, consistency definitions should be clearly stated in the
   protocol and should not be configured at runtime.

JP> I would =
suggest a MUST instead of a should in the sentence =
above.
6.5.  Specifying the constant k

   There are some edge cases where a protocol may wish to use Trickle
   with its suppression disabled (k is set to infinity).  In general,
   this approach is highly dangerous and it is NOT =
RECOMMENDED.
JP> I would strongly suggest to soften this statement. Just =
explain the
consequences.
   Disabling suppression means that every node will always send on every
   interval, and can lead to congestion in dense networks.  This
   approach is especially dangerous 
JP> same =
comment
if many nodes reset their intervals
   at the same time.  In general, it is much more desirable to set k to
   a high value (e.g., 5 or 10) than infinity.  Typical values for k are
   1-5: these achieve a good balance between redundancy and low cost.

JP> I would =
suggest to add refs here.
   =
Nevertheless, there are situations where a protocol may wish to turn
   off Trickle suppression.  Because k is a natural number
   (Section 4.1), c=3D0 has no useful meaning.  If a protocol allows k =
to
   be dynamically configured, a value of 0 remains unused.  For ease of
   debugging and packet inspection, having the parameter describe =
(c-1)
JP> c-1 =
?

   can be counter-productive.  Instead, it is RECOMMENDED that protocols
   which require turning off suppression reserve c=3D0 to mean =
c=3Dinfinity.

6.6.  Relationship between k and Imin

   Finally, a protocol SHOULD set k and Imin such that Imin is at least
   two to three as long as it takes to transmit k packets.  Otherwise,
   if more than k nodes reset their intervals to Imin, the resulting



Levis, et al.            Expires January 7, 2011                [Page 8]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


   communication will lead to congestion and significant packet loss.
   Experimental results have shown that packet losses from congestion
   reduce Trickle's efficiency [Levis04].
JP> Well =
... it is true in most networks, but may not be completely applicable =
to
non wireless =
networks though. You may want to mention =
it.


6.7.  Tweaks and improvements to Trickle

   Trickle is based on a small number of simple, tightly integrated
   mechanisms that are highly robust to challenging network
   environments.  

   >>In our experiences using Trickle, =
attempts to tweak
   its behavior are typically not worth the cost.  As written, the
   algorithm is already highly efficient: further reductions in
   transmissions or response time come at the cost of failures in edge
   cases.  Based on our experiences, we urge protocol designers to
   suppress the instinct to tweak or improve Trickle without a great
   deal of experimental evidence that the change does not violate its
   assumptions and break the algorithm in edge cases.<<
JP> You may want to =
soften this statement.
   This warning in mind, Trickle is far from perfect.  
JP> nobody's perfect. =
Not needed in the document.
For example,
   Trickle suppression typically leads sparser nodes to transmit more
   than denser ones; it is far from the optimal computation of a minimum
   cover.  However, in dynamic network environments such as wireless,
   the coordination needed to compute the optimal set of transmissions
   is typically much greater than the benefits it provides.  One of the
   benefits of Trickle 
JP> s/Trickle/the Trickle =
algorithm
is that it is so simple to implement and =
requires
   so little state yet operates so efficiently.  Efforts to improve it
   should be weighed against the cost of increased complexity.


7.  Acknowledgements

JP> to be =
done


8.  IANA Considerations

   This document has no IANA considerations.


9.  Security Considerations

   This document has no security considerations.


10.  References

10.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.




Levis, et al.            Expires January 7, 2011                [Page 9]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


10.2.  Informative References

   [Levis04]  Levis, P., Patel, N., Culler, D., and S. Shenker,
              "Trickle: A Self-Regulating Algorithm for Code Propagation
              and Maintenance in Wireless Sensor Networks"", Proceedings
              of the First USENIX/ACM Symposium on Networked Systems
              Design and Implementation NSDI 2004, March 2004,
              <http://portal.acm=
.org/citation.cfm?id=3D1251177>.

   [Levis08]  Levis, P., Brewer, E., Culler, D., Gay, D., Madden, S.,
              Patel, N., Polastre, J., Shenker, S., Szewczyk, R., and A.
              Woo, "The Emergence of a Networking Primitive in Wireless
              Sensor Networks", Communications of the ACM, v.51 n.7,
              July 2008,
              <http://portal.acm=
.org/citation.cfm?id=3D1364804>.


Authors' Addresses

   Philip Levis
   Stanford University
   358 Gates Hall, Stanford University
   Stanford, CA  94305
   USA

   Phone: +1 650 725 9064
   Email: pal@cs.stanford.edu


   Thomas Heide Clausen
   LIX, Ecole Polytechnique

   Phone: +33 6 6058 9349
   Email: T.Clausen@computer.org


   Jonathan Hui
   Arch Rock Corporation
   501 Snd St., Suite 410
   San Francisco, CA  94107
   USA

   Email: jhui@archrock.com








Levis, et al.            Expires January 7, 2011               [Page 10]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


   Omprakash Gnawali
   Stanford University
   S255 Clark Center, 318 Campus Drive
   Stanford, CA  94305
   USA

   Phone: +1 650 725 6086
   Email: gnawali@cs.stanford.edu


   JeongGil Ko
   Johns Hopkins University
   3400 N. Charles St., 224 New Engineering Building
   Baltimore, MD  21218
   USA

   Phone: +1 410 516 4312
   Email: jgko@cs.jhu.edu

































Levis, et al.            Expires January 7, 2011               [Page 11]
=0C=

Thanks.

JP= .

On Jul 28, 2010, at 10:05 AM, JP Vasseur = wrote:

Dear WG,

draft-ietf-roll-trickle-02 is stable and now ready = for WG Last Call.

This starts a 2-week Working Group last call = ending on August 11 at 9:00am ET.

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

Thanks.

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

= --Apple-Mail-111--259853019-- From jpv@cisco.com Tue Aug 3 06:35:44 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 097013A69E3 for ; Tue, 3 Aug 2010 06:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.872 X-Spam-Level: X-Spam-Status: No, score=-9.872 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, J_CHICKENPOX_81=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bj+9GKYWO7Gm for ; Tue, 3 Aug 2010 06:35:40 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 3B2173A6862 for ; Tue, 3 Aug 2010 06:35:39 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApQFAKa3V0yrR7Hu/2dsb2JhbACBRIRFmgFxp0ebUwKDCIIvBIkCgkA X-IronPort-AV: E=Sophos;i="4.55,309,1278288000"; d="scan'208,217";a="567822372" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 03 Aug 2010 13:36:07 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o73Da5K8024955 for ; Tue, 3 Aug 2010 13:36:06 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Aug 2010 15:36:05 +0200 Received: from [192.168.1.10] ([10.61.87.54]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Aug 2010 15:36:04 +0200 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-112--259829512 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 3 Aug 2010 15:36:04 +0200 References: <5FB5C986-D72B-41D9-A193-275DEB1D71A3@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 03 Aug 2010 13:36:04.0962 (UTC) FILETIME=[D238C420:01CB3310] Subject: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 13:35:44 -0000 --Apple-Mail-112--259829512 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Begin forwarded message: > From: JP Vasseur > Date: August 3, 2010 3:35:41 PM CEDT > To: JP Vasseur > Cc: ROLL WG > Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 > > Please find below comments on draft-ietf-roll-trickle-02 (search for =20= > JP>). > Co-chair hat on (shepherding the document) > > Networking Working Group P. =20 > Levis > Internet-Draft Stanford =20 > University > Intended status: Informational T. =20 > Clausen > JP> So far good consensus to move to Std track. Let's wait until > end of LC. > Expires: January 7, 2011 LIX, Ecole =20 > Polytechnique > J. =20= > Hui > Arch Rock =20 > Corporation > O. =20 > Gnawali > Stanford =20 > University > =20 > J. Ko > Johns Hopkins =20 > University > July 6, =20= > 2010 > > > The Trickle Algorithm > draft-ietf-roll-trickle-02 > > Abstract > > The Trickle algorithm allows wireless nodes to exchange information > > JP> Not restricted to wireless. Even if we do not use some features, =20= > dynamic > timer adjustments are still useful in PLC/wired environments. > in a highly robust, energy efficient, simple, and scalable manner. > Dynamically adjusting transmission windows allows Trickle to spread > new information on the scale of link-layer transmission times while > sending only a few messages per hour > JP> I would suggest to be more generic (not specify "hour", "mn", =20 > since > that all depends on the parameter settings) > when information does not > change. A simple suppression mechanism and transmission point > selection allows Trickle's communication rate to scale > logarithmically with density. This document describes Trickle > JP> s/trickle/the trickle algorithm > and > considerations in its use. > > Status of this Memo > > This Internet-Draft is submitted to IETF in full conformance with =20= > the > provisions of BCP 78 and BCP 79. > > Internet-Drafts are working documents of the Internet Engineering > Task Force (IETF), its areas, and its working groups. Note that > other groups may also distribute working documents as Internet- > Drafts. > > Internet-Drafts are draft documents valid for a maximum of six =20 > months > and may be updated, replaced, or obsoleted by other documents at =20= > any > time. It is inappropriate to use Internet-Drafts as reference > material or to cite them other than as "work in progress." > > The list of current Internet-Drafts can be accessed at > http://www.ietf.org/ietf/1id-abstracts.txt. > > The list of Internet-Draft Shadow Directories can be accessed at > http://www.ietf.org/shadow.html. > > > > Levis, et al. Expires January 7, 2011 =20 > [Page 1] > =0C > Internet-Draft draft-ietf-roll-trickle-02 July =20= > 2010 > > > This Internet-Draft will expire on January 7, 2011. > > Copyright Notice > > Copyright (c) 2010 IETF Trust and the persons identified as the > document authors. All rights reserved. > > This document is subject to BCP 78 and the IETF Trust's Legal > Provisions Relating to IETF Documents > (http://trustee.ietf.org/license-info) in effect on the date of > publication of this document. Please review these documents > carefully, as they describe your rights and restrictions with =20 > respect > to this document. Code Components extracted from this document =20 > must > include Simplified BSD License text as described in Section 4.e of > the Trust Legal Provisions and are provided without warranty as > described in the BSD License. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Levis, et al. Expires January 7, 2011 =20 > [Page 2] > =0C > Internet-Draft draft-ietf-roll-trickle-02 July =20= > 2010 > > > Table of Contents > > 1. =20 > Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 2. =20 > Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 > 3. Trickle Algorithm =20 > Overview . . . . . . . . . . . . . . . . . . 3 > 4. Trickle =20 > Algorithm . . . . . . . . . . . . . . . . . . . . . . . 4 > 4.1. Parameters and =20 > Variables . . . . . . . . . . . . . . . . . 4 > 4.2. Algorithm =20 > Description . . . . . . . . . . . . . . . . . . . 5 > 5. Using =20 > Trickle . . . . . . . . . . . . . . . . . . . . . . . . . 5 > 6. Operational =20 > Considerations . . . . . . . . . . . . . . . . . . 6 > 6.1. Mismatched redundancy =20 > constants . . . . . . . . . . . . . . 6 > 6.2. Mismatched =20 > Imin . . . . . . . . . . . . . . . . . . . . . . 6 > 6.3. Mismatched =20 > Imax . . . . . . . . . . . . . . . . . . . . . . 7 > 6.4. Mismatched =20 > definitions . . . . . . . . . . . . . . . . . . 7 > 6.5. Specifying the constant =20 > k . . . . . . . . . . . . . . . . . 7 > 6.6. Relationship between k and =20 > Imin . . . . . . . . . . . . . . 7 > 6.7. Tweaks and improvements to =20 > Trickle . . . . . . . . . . . . 8 > 7. =20 > Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 > 8. IANA =20 > Considerations . . . . . . . . . . . . . . . . . . . . . . 8 > 9. Security =20 > Considerations . . . . . . . . . . . . . . . . . . . . 8 > 10. =20 > References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 > 10.1. Normative =20 > References . . . . . . . . . . . . . . . . . . . 8 > 10.2. Informative =20 > References . . . . . . . . . . . . . . . . . . 9 > Authors' =20 > Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 > > > > > > > > > > > > > > > > > > > > > > > > > > > > Levis, et al. Expires January 7, 2011 =20 > [Page 3] > =0C > Internet-Draft draft-ietf-roll-trickle-02 July =20= > 2010 > > > 1. Introduction > > The Trickle algorithm is designed for wireless networks. > JP> please use the LLN terminology and point to [I-D-ietf.roll-=20 > terminology] ID. > It > establishes a density-aware local broadcast with an underlying > consistency model that guides when a node communicates. When a > node's data does not agree > JP> you may want to clarify the term "agree" > with its neighbors, it communicates > quickly to resolve the inconsistency. > JP> Please define "inconsistency" (an example should suffice) > When nodes agree, they slow > their communication rate exponentially, such that nodes send at =20 > most > a few packets per hour. > JP> See comments on "hour" > Instead of flooding a network with packets, > the algorithm controls the send rate so each node hears a small > JP> avoid "small", "large", ... it is all relative. > trickle of packets, just enough to stay consistent. Furthermore, =20= > by > relying only on local broadcasts, > JP> broadcast or multicast > Trickle handles network re- > population, > JP> Define "re-population" > is robust to network transience, loss, and disconnection, > and requires very little state (implementations use 4-11 bytes). > > JP> Mention that current implementations typically requires .... > While Trickle was originally designed for reprogramming protocols > (where the data is the code of the program being updated), =20 > experience > has shown it to be a powerful mechanism that can be applied to wide > range of protocol design problems, including control traffic =20 > timing, > multicast propagation, and route discovery. > > This document describes the Trickle algorithm and provides =20 > guidelines > for its use. It also states requirements for protocol =20 > specifications > that use Trickle. This document does not provide results on > Trickle's performance or behavior, nor does it explain the > algorithm's design in detail: interested readers should refer to > [Levis04] and [Levis08]. > > > 2. Terminology > > The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", > "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", =20= > and > "OPTIONAL" in this document are to be interpreted as described in =20= > RFC > 2119 [RFC2119]. > > > 3. Trickle Algorithm Overview > > Trickle's basic primitive is simple: every so often, a node =20 > transmits > code metadata > JP> s/code metadata/information (e.g. routing protocol, software =20 > updates, ...) > > if it has not heard a few other nodes transmit the same > thing. > JP> s/thing/information > This allows Trickle to scale to thousand-fold variations in > network density, quickly propagate updates, distribute transmission > load evenly, be robust to transient disconnections, handle network > repopulations, and impose a maintenance overhead on the order of a > few packets per hour. > JP> same comment about "hour" > Trickle sends all messages to the local broadcast address. > JP> or multicast (to be updated throughout the document) > > There are > > > > Levis, et al. Expires January 7, 2011 =20 > [Page 4] > =0C > Internet-Draft draft-ietf-roll-trickle-02 July =20= > 2010 > > > two possible results to a Trickle broadcast: either every node that > hears the message is up to date, or a recipient detects the need =20= > for > an update. Detection can be the result of either an out-of-date =20= > node > hearing someone has new code, or an updated node hearing someone =20= > has > old code. > JP> this comes from one application of trickle (code update), could =20= > you make it > more general (e.g. fresher information) > As long as every node communicates somehow - either > receives or transmits - the need for an update will be detected. > > For example, consider a simple case where "up to date" is defined =20= > by > version numbers (e.g., network configuration). If node A =20 > broadcasts > that it has version V, but B has version V+1, then B knows that A > needs an update. Similarly, if B broadcasts that it has V+1 > JP> s/V+1/version V+1 > , A knows > that it needs an update. If B broadcasts updates, then all of its > neighbors can receive them without having to advertise their need. > Some of these recipients might not even have heard A's =20 > transmission. > > In this example, it does not matter who first transmits, A or B; > either case will detect the inconsistency. All that matters is =20 > that > some nodes communicate with one another at some nonzero rate. As > long as the network is connected and there is some minimum > communication rate for each node, the network will reach eventual > consistency. > > The fact that communication can be either transmission or reception > enables Trickle > JP> s/Trickle/the Trickle algorithm > to operate in sparse as well as dense networks. A > single, disconnected node must transmit at the communication rate. > In a lossless, single-hop network of size n, the sum of =20 > transmissions > over the network is the communication rate, so for each node it is > 1/n. Sparser networks require more transmissions per node, but > utilization of the radio channel over space will not increase. =20 > This > is an important property in wireless networks, > JP> and other shared media > where the channel is a > valuable shared resource. Additionally, reducing transmissions in > dense networks conserves system energy. > > > 4. Trickle Algorithm > > This section describes the Trickle algorithm. > > 4.1. Parameters and Variables > > A Trickle timer has three configuration parameters: the minimum > interval size Imin, the maximum interval size Imax, and a =20 > redundancy > constant k: > > o The minimum interval size is defined in units of time (e.g., > milliseconds, seconds). For example, a protocol might define =20= > the > minimum interval as 100 milliseconds. > > > > > Levis, et al. Expires January 7, 2011 =20 > [Page 5] > =0C > Internet-Draft draft-ietf-roll-trickle-02 July =20= > 2010 > > > o The maximum interval size is described as a number of =20 > doublings of > the minimum interval size (the base-2 log(max/min)). For =20 > example, > a protocol might define the maximum interval as 16. If the > minimum interval is 100ms, then the maximum interval is 100ms * > 65536, 6,553.6 seconds, or approximately 109 minutes. > > o The redundancy constant is a natural number (an integer greater > than zero). > JP> Could be equal to infinity (and encoded as 0) =3D> no suppression. > In addition to these three parameters, Trickle maintains three =20= > variables: o I, the current interval size o t, a time within =20= > the current interval, and o c, a counter. > > 4.2. Algorithm Description > > The Trickle algorithm has five rules: > > 1. When an interval begins, Trickle resets c to 0 and sets t to a > random point in the interval, taken from the range [I/2, I). > JP> s/I)/I] > 2. Whenever Trickle hears a transmission that is "consistent," it > increments counter c. > > 3. At time t, Trickle transmits if and only if counter c is less > than the redundancy constant k. > > 4. When an interval expires, > JP> this may not be obvious first time you read it. interval=3Dt or I =20= > (question > was asked on the mailing list in the past). > Trickle doubles the interval length. > If this new interval length would be longer than Imax, Trickle > sets the interval length I to be Imax. > > 5. If Trickle hears a transmission that is "inconsistent," the > Trickle timer resets. If I is greater than Imin, > JP> how could that happen that I < Imin? > resetting a > Trickle timer sets I to Imin and begins a new interval. If I =20= > is > equal to Imin, resetting a Trickle timer does nothing. Trickle > may also reset the timer in response to external "events." > > The terms consistent, inconsistent and event are in quotes because > their meaning depends on the use of Trickle. > > > 5. Using Trickle > > A protocol specification that uses Trickle MUST specify: > > > > Levis, et al. Expires January 7, 2011 =20 > [Page 6] > =0C > Internet-Draft draft-ietf-roll-trickle-02 July =20= > 2010 > > > o Default values for Imin, Imax, and k. > JP> s/Default values/Value > Because link layers can > vary widely in their properties, the default > JP> remove "default" > value of Imin should > be specified in terms of the worst-case latency of a link layer > transmission. For example, a specification should say "the > default value of Imin is 4 times the worst case link layer > latency" > JP> may be worth how you define "latency" > and should not say "the default value of Imin is 500 > milliseconds." Worst case latency is the time until the first > link-layer transmission of the frame assuming an idle channel > (does not include backoff, virtual carrier sense, etc.). > > o What constitutes a "consistent" transmission. > > o What constitutes an "inconsistent" transmission. > > o What "events," if any, besides inconsistent transmissions that > reset the Trickle timer. > > > 6. Operational Considerations > > It is RECOMMENDED that a protocol which uses Trickle include > mechanisms to inform nodes of configuration parameters at runtime. > However, it is not always possible to do so. In the cases where > different nodes have different configuration parameters, Trickle =20= > may > have unintended behaviors. This section outlines some of those > behaviors and operational considerations as educational exercises. > > 6.1. Mismatched redundancy constants > > If nodes do not agree on the redundancy constant k, then nodes with > higher values of k will transmit more often than nodes with lower > values of k. In some cases, this increased load can be independent > of the density. For example, consider a network where all nodes =20= > but > one have k=3D1, and this one node has k=3D2. The different node = can =20 > end > up transmitting on every interval: it is maintaining a =20 > communication > rate of 2 with only itself. Hence, the danger of mismatched k =20 > values > is uneven transmission load that can deplete the energy of some > nodes. > JP> Still this does not lead to interoperability issues. > Don't we want to recommend consistent configuration ? If you agree, =20= > then > these comments should go at the end of this section (or beginning) =20 > but they > apply to several kind of mismatches > 6.2. Mismatched Imin If nodes do not agree on Imin, then some =20 > nodes, on hearing inconsistent messages, will transmit sooner than =20= > others. These faster nodes will have their intervals grow to =20 > similar size as the slower nodes within a single slow interval =20 > time, but in that period may suppress the slower nodes. However, =20= > such suppression will end after the first slow interval, when the =20= > nodes generally agree on the interval size. Hence, mismatched =20 > Imin values are usually not a Levis, et al. Expires =20 > January 7, 2011 [Page 7] =0C Internet-Draft = draft=20 > -ietf-roll-trickle-02 July 2010 significant concern. =20= > 6.3. Mismatched Imax If nodes do not agree on Imax, then this =20 > can cause long-term problems with transmission load. Nodes with =20 > small Imax values will transmit faster, suppressing those with =20 > larger Imax values. The nodes with larger Imax values, always =20 > suppressed, will never transmit. In the base case, when the =20 > network is consistent, this can cause long-term inequities in =20 > energy cost. 6.4. Mismatched definitions If nodes do not agree =20 > on what constitutes a consistent or inconsistent transmission, =20 > then Trickle may fail to operate properly. For example, if a =20 > receiver thinks a transmission is consistent, but the transmitter =20= > (if in the receivers situation) would have thought it =20 > inconsistent, then the receiver will not respond properly and =20 > inform the transmitter. This can lead the network to not reach a =20= > consistent state. For this reason, unlike the configuration =20 > constants k, Imin, and Imax, consistency definitions should be =20 > clearly stated in the protocol and should not be configured at =20 > runtime. > JP> I would suggest a MUST instead of a should in the sentence above. > 6.5. Specifying the constant k > > There are some edge cases where a protocol may wish to use Trickle > with its suppression disabled (k is set to infinity). In general, > this approach is highly dangerous and it is NOT RECOMMENDED. > JP> I would strongly suggest to soften this statement. Just explain =20= > the > consequences. > Disabling suppression means that every node will always send on =20 > every > interval, and can lead to congestion in dense networks. This > approach is especially dangerous > JP> same comment > if many nodes reset their intervals > at the same time. In general, it is much more desirable to set k =20= > to > a high value (e.g., 5 or 10) than infinity. Typical values for k =20= > are > 1-5: these achieve a good balance between redundancy and low cost. > > JP> I would suggest to add refs here. > Nevertheless, there are situations where a protocol may wish to =20 > turn > off Trickle suppression. Because k is a natural number > (Section 4.1), c=3D0 has no useful meaning. If a protocol allows k = =20 > to > be dynamically configured, a value of 0 remains unused. For ease =20= > of > debugging and packet inspection, having the parameter describe =20 > (c-1) > JP> c-1 ? > can be counter-productive. Instead, it is RECOMMENDED that =20 > protocols which require turning off suppression reserve c=3D0 to =20 > mean c=3Dinfinity. 6.6. Relationship between k and Imin Finally, a = =20 > protocol SHOULD set k and Imin such that Imin is at least two to =20 > three as long as it takes to transmit k packets. Otherwise, if =20 > more than k nodes reset their intervals to Imin, the resulting =20 > Levis, et al. Expires January 7, 2011 =20 > [Page 8] =0C Internet-Draft draft-ietf-roll-trickle-02 = =20 > July 2010 communication will lead to congestion and =20 > significant packet loss. Experimental results have shown that =20 > packet losses from congestion reduce Trickle's efficiency [Levis04]. > JP> Well ... it is true in most networks, but may not be completely =20= > applicable to > non wireless networks though. You may want to mention it. > 6.7. Tweaks and improvements to Trickle Trickle is based on a =20 > small number of simple, tightly integrated mechanisms that are =20 > highly robust to challenging network environments. > > >>In our experiences using Trickle, attempts to tweak > its behavior are typically not worth the cost. As written, the > algorithm is already highly efficient: further reductions in > transmissions or response time come at the cost of failures in edge > cases. Based on our experiences, we urge protocol designers to > suppress the instinct to tweak or improve Trickle without a great > deal of experimental evidence that the change does not violate its > assumptions and break the algorithm in edge cases.<< > JP> You may want to soften this statement. > This warning in mind, Trickle is far from perfect. > JP> nobody's perfect. Not needed in the document. > For example, > Trickle suppression typically leads sparser nodes to transmit more > than denser ones; it is far from the optimal computation of a =20 > minimum > cover. However, in dynamic network environments such as wireless, > the coordination needed to compute the optimal set of transmissions > is typically much greater than the benefits it provides. One of =20= > the > benefits of Trickle > JP> s/Trickle/the Trickle algorithm > is that it is so simple to implement and requires > so little state yet operates so efficiently. Efforts to improve it > should be weighed against the cost of increased complexity. > > > 7. Acknowledgements > > JP> to be done > 8. IANA Considerations This document has no IANA =20 > considerations. 9. Security Considerations This document has no =20= > security considerations. 10. References 10.1. Normative =20 > References [RFC2119] Bradner, S., "Key words for use in RFCs to =20= > Indicate Requirement Levels", BCP 14, RFC 2119, March =20 > 1997. Levis, et al. Expires January 7, =20 > 2011 [Page 9] =0C Internet-Draft = draft-ietf-roll-=20 > trickle-02 July 2010 10.2. Informative References =20 > [Levis04] Levis, P., Patel, N., Culler, D., and S. =20 > Shenker, "Trickle: A Self-Regulating Algorithm for Code =20= > Propagation and Maintenance in Wireless Sensor =20 > Networks"", Proceedings of the First USENIX/ACM =20 > Symposium on Networked Systems Design and =20 > Implementation NSDI 2004, March 2004, = >. [Levis08] Levis, P., Brewer, E., Culler, D., Gay, D., Madden, =20= > S., Patel, N., Polastre, J., Shenker, S., Szewczyk, R., =20= > and A. Woo, "The Emergence of a Networking Primitive in =20= > Wireless Sensor Networks", Communications of the ACM, v.=20= > 51 n.7, July 2008, = >. Authors' Addresses Philip Levis Stanford University 358 =20 > Gates Hall, Stanford University Stanford, CA 94305 USA =20 > Phone: +1 650 725 9064 Email: pal@cs.stanford.edu Thomas Heide =20= > Clausen LIX, Ecole Polytechnique Phone: +33 6 6058 9349 =20 > Email: T.Clausen@computer.org Jonathan Hui Arch Rock =20 > Corporation 501 Snd St., Suite 410 San Francisco, CA 94107 =20 > USA Email: jhui@archrock.com Levis, et al. Expires =20 > January 7, 2011 [Page 10] =0C Internet-Draft = draft=20 > -ietf-roll-trickle-02 July 2010 Omprakash Gnawali =20= > Stanford University S255 Clark Center, 318 Campus Drive =20 > Stanford, CA 94305 USA Phone: +1 650 725 6086 Email: = gnawali@cs.stanford.edu=20 > JeongGil Ko Johns Hopkins University 3400 N. Charles St., =20 > 224 New Engineering Building Baltimore, MD 21218 USA Phone: =20= > +1 410 516 4312 Email: jgko@cs.jhu.edu Levis, et al. =20 > Expires January 7, 2011 [Page 11] =0C > > Thanks. > > JP. > > On Jul 28, 2010, at 10:05 AM, JP Vasseur wrote: > >> Dear WG, >> >> draft-ietf-roll-trickle-02 is stable and now ready for WG Last Call. >> >> This starts a 2-week Working Group last call ending on August 11 at =20= >> 9:00am ET. >> >> Please send your comments to the authors and the list. >> >> Thanks. >> >> JP. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > --Apple-Mail-112--259829512 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable

Begin = forwarded message:

From: = JP Vasseur <jpv@cisco.com>
Date: = August 3, 2010 3:35:41 PM CEDT
To: JP = Vasseur <jpv@cisco.com>
Cc: ROLL WG = <roll@ietf.org>
Subject: = Re: [Roll] WG Last Call on = draft-ietf-roll-trickle-02

Please find below comments = on draft-ietf-roll-trickle-02 (search for JP>).
Co-chair hat on = (shepherding the document)

Networking =
Working Group                                        P. Levis
Internet-Draft                                       Stanford University
Intended status: Informational                                T. =
Clausen
JP> So far good =
consensus to move to Std track. Let's wait until
end of LC.
Expires: =
January 7, 2011                        LIX, Ecole Polytechnique
                                                                  J. Hui
                                                   Arch Rock Corporation
                                                              O. Gnawali
                                                     Stanford University
                                                                   J. Ko
                                                Johns Hopkins University
                                                            July 6, 2010


                         The Trickle Algorithm
                       draft-ietf-roll-trickle-02

Abstract

   The Trickle algorithm allows wireless nodes to exchange information

JP> Not =
restricted to wireless. Even if we do not use some features, =
dynamic
timer =
adjustments are still useful in PLC/wired =
environments.
   in a highly robust, energy =
efficient, simple, and scalable manner.
   Dynamically adjusting transmission windows allows Trickle to spread
   new information on the scale of link-layer transmission times while
   sending only a few messages per hour 
JP> I would suggest to =
be more generic (not specify "hour", "mn", since 
that all depends on the parameter =
settings)
when information does not
   change.  A simple suppression mechanism and transmission point
   selection allows Trickle's communication rate to scale
   logarithmically with density.  This document describes =
Trickle 
JP> s/trickle/the trickle =
algorithm
and
   considerations in its use.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ie=
tf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.



Levis, et al.            Expires January 7, 2011                [Page 1]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


   This Internet-Draft will expire on January 7, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/lice=
nse-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.



































Levis, et al.            Expires January 7, 2011                [Page 2]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Trickle Algorithm Overview  . . . . . . . . . . . . . . . . . . 3
   4.  Trickle Algorithm . . . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  Parameters and Variables  . . . . . . . . . . . . . . . . . 4
     4.2.  Algorithm Description . . . . . . . . . . . . . . . . . . . 5
   5.  Using Trickle . . . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Operational Considerations  . . . . . . . . . . . . . . . . . . 6
     6.1.  Mismatched redundancy constants . . . . . . . . . . . . . . 6
     6.2.  Mismatched Imin . . . . . . . . . . . . . . . . . . . . . . 6
     6.3.  Mismatched Imax . . . . . . . . . . . . . . . . . . . . . . 7
     6.4.  Mismatched definitions  . . . . . . . . . . . . . . . . . . 7
     6.5.  Specifying the constant k . . . . . . . . . . . . . . . . . 7
     6.6.  Relationship between k and Imin . . . . . . . . . . . . . . 7
     6.7.  Tweaks and improvements to Trickle  . . . . . . . . . . . . 8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9



























Levis, et al.            Expires January 7, 2011                [Page 3]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


1.  Introduction

   The Trickle algorithm is designed for wireless networks. =
 
JP> please =
use the LLN terminology and point to [I-D-ietf.roll-terminology] =
ID.
It
   establishes a density-aware local broadcast with an underlying
   consistency model that guides when a node communicates.  When a
   node's data does not agree 
JP> you may want to clarify the =
term "agree"
with its neighbors, it communicates
   quickly to resolve the inconsistency.  
JP> Please define =
"inconsistency" (an example should =
suffice)
When nodes agree, they slow
   their communication rate exponentially, such that nodes send at most
   a few packets per hour.  
JP> See comments on =
"hour"
Instead of flooding a network with packets,
   the algorithm controls the send rate so each node hears a =
small
JP> avoid =
"small", "large", ... it is all relative.
   trickle of =
packets, just enough to stay consistent.  Furthermore, by
   relying only on local broadcasts, 
JP> broadcast or =
multicast
Trickle handles network re-
   population, 
JP> Define =
"re-population"
is robust to network transience, =
loss, and disconnection,
   and requires very little state (implementations use 4-11 bytes).

JP> Mention =
that current implementations typically requires =
.... 
   While Trickle was originally designed for =
reprogramming protocols
   (where the data is the code of the program being updated), experience
   has shown it to be a powerful mechanism that can be applied to wide
   range of protocol design problems, including control traffic timing,
   multicast propagation, and route discovery.

   This document describes the Trickle algorithm and provides guidelines
   for its use.  It also states requirements for protocol specifications
   that use Trickle.  This document does not provide results on
   Trickle's performance or behavior, nor does it explain the
   algorithm's design in detail: interested readers should refer to
   [Levis04] and [Levis08].


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].


3.  Trickle Algorithm Overview

   Trickle's basic primitive is simple: every so often, a node transmits
   code metadata 
JP> s/code metadata/information =
(e.g. routing protocol, software updates, =
...)

if it has not heard a few other nodes transmit =
the same
   thing.  
JP> s/thing/information
This allows =
Trickle to scale to thousand-fold variations in
   network density, quickly propagate updates, distribute transmission
   load evenly, be robust to transient disconnections, handle network
   repopulations, and impose a maintenance overhead on the order of a
   few packets per hour.
JP> same comment about =
"hour"
   Trickle sends all messages to the local =
broadcast address.  
JP> or multicast (to be updated =
throughout the document)

There are



Levis, et al.            Expires January 7, 2011                [Page 4]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


   two possible results to a Trickle broadcast: either every node that
   hears the message is up to date, or a recipient detects the need for
   an update.  Detection can be the result of either an out-of-date node
   hearing someone has new code, or an updated node hearing someone has
   old code.  
JP> this comes from one application =
of trickle (code update), could you make it
more general (e.g. fresher =
information)
As long as every node communicates =
somehow - either
   receives or transmits - the need for an update will be detected.

   For example, consider a simple case where "up to date" is defined by
   version numbers (e.g., network configuration).  If node A broadcasts
   that it has version V, but B has version V+1, then B knows that A
   needs an update.  Similarly, if B broadcasts that it has =
V+1
JP> =
s/V+1/version V+1
, A knows
   that it needs an update.  If B broadcasts updates, then all of its
   neighbors can receive them without having to advertise their need.
   Some of these recipients might not even have heard A's transmission.

   In this example, it does not matter who first transmits, A or B;
   either case will detect the inconsistency.  All that matters is that
   some nodes communicate with one another at some nonzero rate.  As
   long as the network is connected and there is some minimum
   communication rate for each node, the network will reach eventual
   consistency.

   The fact that communication can be either transmission or reception
   enables Trickle 
JP> s/Trickle/the Trickle =
algorithm
to operate in sparse as well as dense networks. =
 A
   single, disconnected node must transmit at the communication rate.
   In a lossless, single-hop network of size n, the sum of transmissions
   over the network is the communication rate, so for each node it is
   1/n.  Sparser networks require more transmissions per node, but
   utilization of the radio channel over space will not increase.  This
   is an important property in wireless networks, 
JP> and other shared =
media
where the channel is a
   valuable shared resource.  Additionally, reducing transmissions in
   dense networks conserves system energy.


4.  Trickle Algorithm

   This section describes the Trickle algorithm.

4.1.  Parameters and Variables

   A Trickle timer has three configuration parameters: the minimum
   interval size Imin, the maximum interval size Imax, and a redundancy
   constant k:

   o  The minimum interval size is defined in units of time (e.g.,
      milliseconds, seconds).  For example, a protocol might define the
      minimum interval as 100 milliseconds.




Levis, et al.            Expires January 7, 2011                [Page 5]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


   o  The maximum interval size is described as a number of doublings of
      the minimum interval size (the base-2 log(max/min)).  For example,
      a protocol might define the maximum interval as 16.  If the
      minimum interval is 100ms, then the maximum interval is 100ms *
      65536, 6,553.6 seconds, or approximately 109 minutes.

   o  The redundancy constant is a natural number (an integer greater
      than zero).
JP> Could be equal to infinity (and encoded as 0) =3D> no =
suppression.
   In addition to these three =
parameters, Trickle maintains three   variables:    o  I, the current =
interval size    o  t, a time within the current interval, and    o  c, =
a counter.

4.2.  Algorithm Description

   The Trickle algorithm has five rules:

   1.  When an interval begins, Trickle resets c to 0 and sets t to a
       random point in the interval, taken from the range [I/2, I).

JP> =
s/I)/I]
   2.  Whenever Trickle hears a transmission =
that is "consistent," it
       increments counter c.

   3.  At time t, Trickle transmits if and only if counter c is less
       than the redundancy constant k.

   4.  When an interval expires, 
JP> this may not be obvious first =
time you read it. interval=3Dt or I (question
was asked on the mailing list in the =
past).
Trickle doubles the interval length.
       If this new interval length would be longer than Imax, Trickle
       sets the interval length I to be Imax.

   5.  If Trickle hears a transmission that is "inconsistent," the
       Trickle timer resets.  If I is greater than Imin, 
JP> how could that =
happen that I <  Imin?
resetting a
       Trickle timer sets I to Imin and begins a new interval.  If I is
       equal to Imin, resetting a Trickle timer does nothing.  Trickle
       may also reset the timer in response to external "events."

   The terms consistent, inconsistent and event are in quotes because
   their meaning depends on the use of Trickle.


5.  Using Trickle

   A protocol specification that uses Trickle MUST specify:



Levis, et al.            Expires January 7, 2011                [Page 6]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


   o  Default values for Imin, Imax, and k.  
JP> s/Default =
values/Value
Because link layers can
      vary widely in their properties, the default 
JP> remove =
"default"
value of Imin should
      be specified in terms of the worst-case latency of a link layer
      transmission.  For example, a specification should say "the
      default value of Imin is 4 times the worst case link layer
      latency" 
JP> may be worth how you define =
"latency"
and should not say "the default value of Imin =
is 500
      milliseconds."  Worst case latency is the time until the first
      link-layer transmission of the frame assuming an idle channel
      (does not include backoff, virtual carrier sense, etc.).

   o  What constitutes a "consistent" transmission.

   o  What constitutes an "inconsistent" transmission.

   o  What "events," if any, besides inconsistent transmissions that
      reset the Trickle timer.


6.  Operational Considerations

   It is RECOMMENDED that a protocol which uses Trickle include
   mechanisms to inform nodes of configuration parameters at runtime.
   However, it is not always possible to do so.  In the cases where
   different nodes have different configuration parameters, Trickle may
   have unintended behaviors.  This section outlines some of those
   behaviors and operational considerations as educational exercises.

6.1.  Mismatched redundancy constants

   If nodes do not agree on the redundancy constant k, then nodes with
   higher values of k will transmit more often than nodes with lower
   values of k.  In some cases, this increased load can be independent
   of the density.  For example, consider a network where all nodes but
   one have k=3D1, and this one node has k=3D2.  The different node can =
end
   up transmitting on every interval: it is maintaining a communication
   rate of 2 with only itself.  Hence, the danger of mismatched k values
   is uneven transmission load that can deplete the energy of some
   nodes.
JP> Still this does not lead to interoperability =
issues.
Don't we want to recommend consistent configuration ? If you =
agree, then
these comments should go at the end of =
this section (or beginning) but they
apply to =
several kind of mismatches
 6.2.  Mismatched =
Imin    If nodes do not agree on Imin, then some nodes, on hearing   =
inconsistent messages, will transmit sooner than others.  These   faster =
nodes will have their intervals grow to similar size as the   slower =
nodes within a single slow interval time, but in that period   may =
suppress the slower nodes.  However, such suppression will end   after =
the first slow interval, when the nodes generally agree on the   =
interval size.  Hence, mismatched Imin values are usually not a Levis, =
et al.            Expires January 7, 2011                [Page 7] =0C =
Internet-Draft         draft-ietf-roll-trickle-02              July 2010 =
   significant concern. 6.3.  Mismatched Imax    If nodes do not agree =
on Imax, then this can cause long-term problems   with transmission =
load.  Nodes with small Imax values will transmit   faster, suppressing =
those with larger Imax values.  The nodes with   larger Imax values, =
always suppressed, will never transmit.  In the   base case, when the =
network is consistent, this can cause long-term   inequities in energy =
cost. 6.4.  Mismatched definitions    If nodes do not agree on what =
constitutes a consistent or   inconsistent transmission, then Trickle =
may fail to operate properly.   For example, if a receiver thinks a =
transmission is consistent, but   the transmitter (if in the receivers =
situation) would have thought it   inconsistent, then the receiver will =
not respond properly and inform   the transmitter.  This can lead the =
network to not reach a consistent   state.  For this reason, unlike the =
configuration constants k, Imin,   and Imax, consistency definitions =
should be clearly stated in the   protocol and should not be configured =
at runtime. 
JP> I would suggest a MUST instead of a should in the =
sentence above.
6.5.  Specifying the constant k

   There are some edge cases where a protocol may wish to use Trickle
   with its suppression disabled (k is set to infinity).  In general,
   this approach is highly dangerous and it is NOT =
RECOMMENDED.
JP> I would strongly suggest to soften this statement. Just =
explain the
consequences.
   Disabling suppression means that =
every node will always send on every
   interval, and can lead to congestion in dense networks.  This
   approach is especially dangerous 
JP> same =
comment
if many nodes reset their intervals
   at the same time.  In general, it is much more desirable to set k to
   a high value (e.g., 5 or 10) than infinity.  Typical values for k are
   1-5: these achieve a good balance between redundancy and low cost.

JP> I would =
suggest to add refs here.
   =
Nevertheless, there are situations where a protocol may wish to turn
   off Trickle suppression.  Because k is a natural number
   (Section 4.1), c=3D0 has no useful meaning.  If a protocol allows k =
to
   be dynamically configured, a value of 0 remains unused.  For ease of
   debugging and packet inspection, having the parameter describe =
(c-1)
JP> c-1 =
?
   can be counter-productive.  Instead, it is =
RECOMMENDED that protocols   which require turning off suppression =
reserve c=3D0 to mean c=3Dinfinity. 6.6.  Relationship between k and =
Imin    Finally, a protocol SHOULD set k and Imin such that Imin is at =
least   two to three as long as it takes to transmit k packets.  =
Otherwise,   if more than k nodes reset their intervals to Imin, the =
resulting Levis, et al.            Expires January 7, 2011               =
 [Page 8] =0C Internet-Draft         draft-ietf-roll-trickle-02          =
    July 2010    communication will lead to congestion and significant =
packet loss.   Experimental results have shown that packet losses from =
congestion   reduce Trickle's efficiency [Levis04].
JP> Well ... it is true in most networks, but may not be =
completely applicable to
non wireless networks though. You may want to mention =
it.
 6.7.  =
Tweaks and improvements to Trickle    Trickle is based on a small number =
of simple, tightly integrated   mechanisms that are highly robust to =
challenging network   environments.  

   >>In our experiences using =
Trickle, attempts to tweak
   its behavior are typically not worth the cost.  As written, the
   algorithm is already highly efficient: further reductions in
   transmissions or response time come at the cost of failures in edge
   cases.  Based on our experiences, we urge protocol designers to
   suppress the instinct to tweak or improve Trickle without a great
   deal of experimental evidence that the change does not violate its
   assumptions and break the algorithm in edge cases.<<
JP> You may want to =
soften this statement.
   This warning in mind, Trickle is =
far from perfect.  
JP> nobody's perfect. Not needed in =
the document.
For example,
   Trickle suppression typically leads sparser nodes to transmit more
   than denser ones; it is far from the optimal computation of a minimum
   cover.  However, in dynamic network environments such as wireless,
   the coordination needed to compute the optimal set of transmissions
   is typically much greater than the benefits it provides.  One of the
   benefits of Trickle 
JP> s/Trickle/the Trickle =
algorithm
is that it is so simple to implement and =
requires
   so little state yet operates so efficiently.  Efforts to improve it
   should be weighed against the cost of increased complexity.


7.  Acknowledgements

JP> to be =
done
 8.  IANA Considerations    This document has no =
IANA considerations. 9.  Security Considerations    This document has no =
security considerations. 10.  References 10.1.  Normative References    =
[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate           =
   Requirement Levels", BCP 14, RFC 2119, March 1997. Levis, et al.      =
      Expires January 7, 2011                [Page 9] =0C Internet-Draft =
        draft-ietf-roll-trickle-02              July 2010 10.2.  =
Informative References    [Levis04]  Levis, P., Patel, N., Culler, D., =
and S. Shenker,              "Trickle: A Self-Regulating Algorithm for =
Code Propagation              and Maintenance in Wireless Sensor =
Networks"", Proceedings              of the First USENIX/ACM Symposium =
on Networked Systems              Design and Implementation NSDI 2004, =
March 2004,              <http://portal.acm=
.org/citation.cfm?id=3D1251177>.    [Levis08]  Levis, P., Brewer, =
E., Culler, D., Gay, D., Madden, S.,              Patel, N., Polastre, =
J., Shenker, S., Szewczyk, R., and A.              Woo, "The Emergence =
of a Networking Primitive in Wireless              Sensor Networks", =
Communications of the ACM, v.51 n.7,              July 2008,             =
 <http://portal.acm=
.org/citation.cfm?id=3D1364804>. Authors' Addresses    Philip =
Levis   Stanford University   358 Gates Hall, Stanford University   =
Stanford, CA  94305   USA    Phone: +1 650 725 9064   Email: pal@cs.stanford.edu    Thomas =
Heide Clausen   LIX, Ecole Polytechnique    Phone: +33 6 6058 9349   =
Email: T.Clausen@computer.org    =
Jonathan Hui   Arch Rock Corporation   501 Snd St., Suite 410   San =
Francisco, CA  94107   USA    Email: jhui@archrock.com Levis, et al.    =
        Expires January 7, 2011               [Page 10] =0C =
Internet-Draft         draft-ietf-roll-trickle-02              July 2010 =
   Omprakash Gnawali   Stanford University   S255 Clark Center, 318 =
Campus Drive   Stanford, CA  94305   USA    Phone: +1 650 725 6086   =
Email: gnawali@cs.stanford.edu    =
JeongGil Ko   Johns Hopkins University   3400 N. Charles St., 224 New =
Engineering Building   Baltimore, MD  21218   USA    Phone: +1 410 516 =
4312   Email: jgko@cs.jhu.edu =
Levis, et al.            Expires January 7, 2011               [Page 11] =
=0C=

Thanks.

JP= .

On Jul 28, 2010, at 10:05 AM, JP Vasseur = wrote:

Dear WG,

draft-ietf-roll-trickle-02 is stable and now ready = for WG Last Call.

This starts a 2-week Working Group last call = ending on August 11 at 9:00am ET.

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

Thanks.

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


= --Apple-Mail-112--259829512-- From mdurvy@cisco.com Tue Aug 3 08:31:42 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D22973A6966 for ; Tue, 3 Aug 2010 08:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.282 X-Spam-Level: X-Spam-Status: No, score=-10.282 tagged_above=-999 required=5 tests=[AWL=0.317, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxozetTwtaA8 for ; Tue, 3 Aug 2010 08:31:37 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 49BA03A6900 for ; Tue, 3 Aug 2010 08:31:37 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: smime.p7s : 4100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABLTV0yrR7H+/2dsb2JhbACgEXGoH5tShTkEi04 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 03 Aug 2010 15:32:01 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o73FVrNj020634; Tue, 3 Aug 2010 15:32:01 GMT Received: from xmb-ams-103.cisco.com ([144.254.74.78]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Aug 2010 17:31:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 3 Aug 2010 17:31:57 +0200 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00CE_01CB3331.C596CE80" Message-ID: <8A977BDC5A7B0E429B0F521E8D6F91EE02A603B6@XMB-AMS-103.cisco.com> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF017977C0@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Status change on Trickle I-D (was: DraftROLLWG minutesposted) Thread-Index: AcsyYkbcyo56YH8sSzqtWl9H7BDCZQAIGkHwACeQB2A= References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com><4C56F61E.1020808@eecs.berkeley.edu> <8E09C72DBC577D489F13A71228C0B7BF017977C0@ftrdmel0.rd.francetelecom.fr> From: "Mathilde Durvy (mdurvy)" To: , X-OriginalArrivalTime: 03 Aug 2010 15:31:59.0393 (UTC) FILETIME=[0362B910:01CB3321] Subject: Re: [Roll] Status change on Trickle I-D (was: DraftROLLWG minutesposted) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 15:31:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CE_01CB3331.C596CE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 Mathilde -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of dominique.barthel@orange-ftgroup.com Sent: lundi, 2. ao=FBt 2010 22:41 To: roll@ietf.org Subject: Re: [Roll] Status change on Trickle I-D (was: DraftROLLWG minutesposted) Moving Trickle to Std Track seems the most sensible move to me. Trickle seems to be applicable to a wide sprectrum of protocols, = therefore is likely to be referenced as Normative in several future Std Track documents. Dominique -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = Kris Pister Envoy=E9 : lundi 2 ao=FBt 2010 18:45 =C0 : Pascal Thubert (pthubert) Cc : roll@ietf.org Objet : Re: [Roll] Status change on Trickle I-D (was: Draft ROLLWG minutesposted) I agree that trickle should move to standards track. ksjp Pascal Thubert (pthubert) wrote: > Alex: > > We need to be very clear that the WG is chartered for Standard Track,=20 > not Informational. So RPL is and will stay on that track. > Moving Trickle to standard track is a good move, highly deserved for a = > method that's well understood and proven, and I support it 100%. > > Safe trip back, > > Pascal > > =20 >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> =20 > Of > =20 >> Alexandru Petrescu >> Sent: Friday, July 30, 2010 8:19 AM >> To: roll@ietf.org >> Subject: [Roll] Status change on Trickle I-D (was: Draft ROLL WG >> minutesposted) >> >> =20 >>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02 (Phil - 5mn) = >>> [160] Quick update on the changes in -02. Currently in LC. >>> >>> JP> ID is a normative reference in RPL core spec (thus we have a >>> downref). Discussion on ID status JP> Will come back to the list to=20 >>> consider status change (informational to standard track) >>> =20 >> Just a quick note to consider more ways to solve this problem (RPL >> =20 > spec > =20 >> 'downref'erencing a draft it fully relies on): >> >> -move draft-ietf-roll-trickle in the Informative References section. >> This implies making Trickle parameters less mandatory in RPL. >> -change the track of the base spec to Informational (this implies >> =20 > change to > =20 >> communication to SDO requiring this RP, I suppose). >> >> Also worth mentioning the use of BCP tag on the Trickle draft... >> =20 > Trickle being > =20 >> common practice in widespread use yet not really a protocol (timer=20 >> management). >> >> These may have already been considered, >> >> Alex >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> =20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > =20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_00CE_01CB3331.C596CE80 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUzCCAjww ggGlAhA/aR6BnPCaSvNz/7lIouTdMA0GCSqGSIb3DQEBBQUAMF8xCzAJBgNVBAYTAlVTMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJsaWMgUHJpbWFyeSBDZXJ0 aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05NjAxMjkwMDAwMDBaFw0yODA4MDIyMzU5NTlaMF8xCzAJ BgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTCBnzANBgkqhkiG9w0BAQEFAAOBjQAw gYkCgYEA5Rm/baNWYS2ZSHH2Z965jeu3noaACpEO+jglr0aIguVzqKCbJF0NH8xlbgyw0FaEGIea BpsQoXPftFg5a27B9hXVqKg/qhIGjTGsf7A01480Z4gJzRQR4k5FVmkfeAKA2txHkSm7NsljXMXg 1y2He6G3MrB7MLoqLzGq7qNn2tsCAwEAATANBgkqhkiG9w0BAQUFAAOBgQBYFSk5PHej2lwlA3xg +u4JmTwnEHDIDAnms4fPCuIYljVizL+bJ3mJX8nECfTOtR3fKr3l24acaCXlMHy2iRX+Z9Gt4VCs PHxiS4+6hNcSFRsfyl0PwVKUKhGZ2nvPDDYT1TXcEBlZ6pTBAL91j9n6/XYE22K7kGoD2UY12fh8 WzCCBEYwggOvoAMCAQICEGb9R+PCGeToms2Z3fU6yyQwDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQ cmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIz NTk1OVowgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXL wKuMPRyVzm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi 8mD81zplYu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3 otdzzwFBL2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZ iHWcec5gJ925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8f ef/btLUCAwEAAaOB/zCB/DASBgNVHRMBAf8ECDAGAQH/AgEAMEQGA1UdIAQ9MDswOQYLYIZIAYb4 RQEHFwEwKjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYTALBgNVHQ8E BAMCAQYwEQYJYIZIAYb4QgEBBAQDAgEGMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWwzLTIwNDgtMTU1MB0GA1UdDgQWBBQRfV4ZfTwE32ps1qKKGj8x2DuUUjAxBgNVHR8EKjAo MCagJKAihiBodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9wY2ExLmNybDANBgkqhkiG9w0BAQUFAAOB gQA8o9oCYzrEk6qrctPcrVA4HgyeFkqIt+7r2f8PjZWg1rv6aguuYYTYaEeJ70+ssh9JQZtJM3aT i55uuUMcYL3C3Ioth8FFwBFyBBprJCpsb+f8BxMp0Hc6I+f1wYVoGb/GAVQgGa41gsxiPGEJxvTV 67APpp8zhZrTcY5Qj5ndYjCCBMUwggOtoAMCAQICEAEaKIsmZ7dNiOdEe0XWpM0wDQYJKoZIhvcN AQEFBQAwgd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRl ZDE3MDUGA1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBH MjAeFw0wOTExMjYwMDAwMDBaFw0xMDExMjYyMzU5NTlaMIIBEjEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJp c2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAc BgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE0MDIGA1UECxMrRGlnaXRhbCBJRCBDbGFzcyAx IC0gTWljcm9zb2Z0IEZ1bGwgU2VydmljZTEXMBUGA1UEAxQOTWF0aGlsZGUgRHVydnkxHzAdBgkq hkiG9w0BCQEWEG1kdXJ2eUBjaXNjby5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBANH2 hVIDPpOW3vFS8Bv4gqlqop27V2HRyKGmM03Od0jOK35lamLENny1YG2lntPaMEL5KLKq6oiuKf9M PiOWTrTLg4EF4XbOUlpzo/QDLyDhaMNGe8k/3dbP3dbfZuCO1XVHsVGVZTE+Of1BQNyrg8gd3ioU pKI4x8qTU6KNh5ZFAgMBAAGjgcwwgckwCQYDVR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD AgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRw Oi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlzaWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJ KoZIhvcNAQEFBQADggEBAD0jYXBaNYYw1qke8wVjYtk36qvdxfogsFRnUDHKkCmvkHYeXxhcMwDq jwa13knbDGQmYQBupdPOShVaymKCxyUVJsYO7lXQhMstnPMJe/Cel5pQPgX0aeCp2Q1RmSpeKupo xnFBOJojke57ZFfd/tsTDgapT4oyDqZ6ivmIyjIaX+a1nQtI+PpmW01obsSVCjJNd90EZeUSbzPa 4mG1vjZizY5Sm0/W/fGOHFPaeO/00xwEfirtLrL6inRoWtWw0s/v6pw9IFmURxq/e/I1LKDGerLH 6kwmaBYf79V3CxtIgMEUCjgOgj597alQh6pHHrI/2z57bUFGJI/G8G1V74kxggRzMIIEbwIBATCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEw HAYJKoZIhvcNAQkFMQ8XDTEwMDgwMzE1MzE1N1owIwYJKoZIhvcNAQkEMRYEFEauO/oK2zXb25nl oVCgrTOA1suIMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0G CCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIF MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s IEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9m IHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJz b25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBT dWJzY3JpYmVyIENBIC0gRzICEAEaKIsmZ7dNiOdEe0XWpM0wggEFBgsqhkiG9w0BCRACCzGB9aCB 8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAB GiiLJme3TYjnRHtF1qTNMA0GCSqGSIb3DQEBAQUABIGATSfSq/pD3hu6NPUAtyQSE+Gf4+8JD5rg Lv2Zdm5SEmu1bnL2MyGf5dmvYfJurM8gxJzi4kbg+91vOKYHIXc5Gx2R97FdF0zIPU2h5FJDfAi7 8o4munzss6ht7twH44jUcHKY5KHR6bWLuKrLNt34F+Noj5/W17yZ6RQHT6U9U2oAAAAAAAA= ------=_NextPart_000_00CE_01CB3331.C596CE80-- From c.chauvenet@watteco.com Tue Aug 3 09:05:13 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7047C3A69D0 for ; Tue, 3 Aug 2010 09:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.152 X-Spam-Level: X-Spam-Status: No, score=0.152 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_18=0.6, J_CHICKENPOX_74=0.6, J_CHICKENPOX_81=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pCeSbQPDNX3M for ; Tue, 3 Aug 2010 09:05:09 -0700 (PDT) Received: from mail.abrisite.fr (mx197.abrisite.fr [85.31.209.197]) by core3.amsl.com (Postfix) with ESMTP id 3B2D83A69F8 for ; Tue, 3 Aug 2010 09:05:07 -0700 (PDT) Received: from PCdePoste9 ([82.241.54.131]) by mail.abrisite.fr (POL Mail Securise v2.0) with ASMTP id LYI35833; Tue, 03 Aug 2010 18:05:33 +0200 Message-ID: <5BEE6FEFE7164A199FA0B64D7EDC4E1F@PCdePoste9> From: "Cedric Chauvenet" To: "JP Vasseur" , "ROLL WG" References: <5FB5C986-D72B-41D9-A193-275DEB1D71A3@cisco.com> In-Reply-To: Date: Tue, 3 Aug 2010 18:06:13 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0180_01CB3336.8F279E60" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18197 Subject: Re: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 16:05:13 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0180_01CB3336.8F279E60 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I vote for moving trickle to Std track. ----- Original Message -----=20 From: JP Vasseur=20 To: ROLL WG=20 Sent: Tuesday, August 03, 2010 3:36 PM Subject: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 Begin forwarded message: From: JP Vasseur Date: August 3, 2010 3:35:41 PM CEDT To: JP Vasseur Cc: ROLL WG Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 Please find below comments on draft-ietf-roll-trickle-02 (search for = JP>). Co-chair hat on (shepherding the document) Networking Working Group P. Levis Internet-Draft Stanford University Intended status: Informational T. = ClausenJP> So far good consensus to move to Std track. Let's wait = untilend of LC.Expires: January 7, 2011 LIX, = Ecole Polytechnique J. Hui Arch Rock Corporation O. Gnawali Stanford University J. Ko Johns Hopkins University July 6, 2010 The Trickle Algorithm draft-ietf-roll-trickle-02 Abstract The Trickle algorithm allows wireless nodes to exchange information JP> Not restricted to wireless. Even if we do not use some features, = dynamictimer adjustments are still useful in PLC/wired environments. = in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour JP> I would suggest to be more = generic (not specify "hour", "mn", since that all depends on the = parameter settings)when information does not change. A simple suppression mechanism and transmission point selection allows Trickle's communication rate to scale logarithmically with density. This document describes Trickle JP> = s/trickle/the trickle algorithmand considerations in its use. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Levis, et al. Expires January 7, 2011 [Page 1] =0C Internet-Draft draft-ietf-roll-trickle-02 July 2010 This Internet-Draft will expire on January 7, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Levis, et al. Expires January 7, 2011 [Page 2] =0C Internet-Draft draft-ietf-roll-trickle-02 July 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Trickle Algorithm Overview . . . . . . . . . . . . . . . . . . 3 4. Trickle Algorithm . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Parameters and Variables . . . . . . . . . . . . . . . . . 4 4.2. Algorithm Description . . . . . . . . . . . . . . . . . . . 5 5. Using Trickle . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Operational Considerations . . . . . . . . . . . . . . . . . . 6 6.1. Mismatched redundancy constants . . . . . . . . . . . . . . 6 6.2. Mismatched Imin . . . . . . . . . . . . . . . . . . . . . . 6 6.3. Mismatched Imax . . . . . . . . . . . . . . . . . . . . . . 7 6.4. Mismatched definitions . . . . . . . . . . . . . . . . . . 7 6.5. Specifying the constant k . . . . . . . . . . . . . . . . . 7 6.6. Relationship between k and Imin . . . . . . . . . . . . . . 7 6.7. Tweaks and improvements to Trickle . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Levis, et al. Expires January 7, 2011 [Page 3] =0C Internet-Draft draft-ietf-roll-trickle-02 July 2010 1. Introduction The Trickle algorithm is designed for wireless networks. JP> please = use the LLN terminology and point to [I-D-ietf.roll-terminology] ID.It establishes a density-aware local broadcast with an underlying consistency model that guides when a node communicates. When a node's data does not agree JP> you may want to clarify the term = "agree"with its neighbors, it communicates quickly to resolve the inconsistency. JP> Please define = "inconsistency" (an example should suffice)When nodes agree, they slow their communication rate exponentially, such that nodes send at most a few packets per hour. JP> See comments on "hour"Instead of = flooding a network with packets, the algorithm controls the send rate so each node hears a smallJP> = avoid "small", "large", ... it is all relative. trickle of packets, = just enough to stay consistent. Furthermore, by relying only on local broadcasts, JP> broadcast or multicastTrickle = handles network re- population, JP> Define "re-population"is robust to network = transience, loss, and disconnection, and requires very little state (implementations use 4-11 bytes). JP> Mention that current implementations typically requires .... = While Trickle was originally designed for reprogramming protocols (where the data is the code of the program being updated), experience has shown it to be a powerful mechanism that can be applied to wide range of protocol design problems, including control traffic timing, multicast propagation, and route discovery. This document describes the Trickle algorithm and provides guidelines for its use. It also states requirements for protocol specifications that use Trickle. This document does not provide results on Trickle's performance or behavior, nor does it explain the algorithm's design in detail: interested readers should refer to [Levis04] and [Levis08]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Trickle Algorithm Overview Trickle's basic primitive is simple: every so often, a node transmits code metadata JP> s/code metadata/information (e.g. routing protocol, = software updates, ...)if it has not heard a few other nodes transmit the = same thing. JP> s/thing/informationThis allows Trickle to scale to = thousand-fold variations in network density, quickly propagate updates, distribute transmission load evenly, be robust to transient disconnections, handle network repopulations, and impose a maintenance overhead on the order of a few packets per hour.JP> same comment about "hour" Trickle sends = all messages to the local broadcast address. JP> or multicast (to be = updated throughout the document)There are Levis, et al. Expires January 7, 2011 [Page 4] =0C Internet-Draft draft-ietf-roll-trickle-02 July 2010 two possible results to a Trickle broadcast: either every node that hears the message is up to date, or a recipient detects the need for an update. Detection can be the result of either an out-of-date node hearing someone has new code, or an updated node hearing someone has old code. JP> this comes from one application of trickle (code = update), could you make itmore general (e.g. fresher information)As long = as every node communicates somehow - either receives or transmits - the need for an update will be detected. For example, consider a simple case where "up to date" is defined by version numbers (e.g., network configuration). If node A broadcasts that it has version V, but B has version V+1, then B knows that A needs an update. Similarly, if B broadcasts that it has V+1JP> = s/V+1/version V+1, A knows that it needs an update. If B broadcasts updates, then all of its neighbors can receive them without having to advertise their need. Some of these recipients might not even have heard A's transmission. In this example, it does not matter who first transmits, A or B; either case will detect the inconsistency. All that matters is that some nodes communicate with one another at some nonzero rate. As long as the network is connected and there is some minimum communication rate for each node, the network will reach eventual consistency. The fact that communication can be either transmission or reception enables Trickle JP> s/Trickle/the Trickle algorithmto operate in = sparse as well as dense networks. A single, disconnected node must transmit at the communication rate. In a lossless, single-hop network of size n, the sum of transmissions over the network is the communication rate, so for each node it is 1/n. Sparser networks require more transmissions per node, but utilization of the radio channel over space will not increase. This is an important property in wireless networks, JP> and other shared = mediawhere the channel is a valuable shared resource. Additionally, reducing transmissions in dense networks conserves system energy. 4. Trickle Algorithm This section describes the Trickle algorithm. 4.1. Parameters and Variables A Trickle timer has three configuration parameters: the minimum interval size Imin, the maximum interval size Imax, and a redundancy constant k: o The minimum interval size is defined in units of time (e.g., milliseconds, seconds). For example, a protocol might define the minimum interval as 100 milliseconds. Levis, et al. Expires January 7, 2011 [Page 5] =0C Internet-Draft draft-ietf-roll-trickle-02 July 2010 o The maximum interval size is described as a number of doublings of the minimum interval size (the base-2 log(max/min)). For example, a protocol might define the maximum interval as 16. If the minimum interval is 100ms, then the maximum interval is 100ms * 65536, 6,553.6 seconds, or approximately 109 minutes. o The redundancy constant is a natural number (an integer greater than zero).JP> Could be equal to infinity (and encoded as 0) =3D> = no suppression. In addition to these three parameters, Trickle = maintains three variables: o I, the current interval size o t, = a time within the current interval, and o c, a counter.4.2. = Algorithm Description The Trickle algorithm has five rules: 1. When an interval begins, Trickle resets c to 0 and sets t to a random point in the interval, taken from the range [I/2, I). JP> s/I)/I] 2. Whenever Trickle hears a transmission that is = "consistent," it increments counter c. 3. At time t, Trickle transmits if and only if counter c is less than the redundancy constant k. 4. When an interval expires, JP> this may not be obvious first time = you read it. interval=3Dt or I (questionwas asked on the mailing list in = the past).Trickle doubles the interval length. If this new interval length would be longer than Imax, Trickle sets the interval length I to be Imax. 5. If Trickle hears a transmission that is "inconsistent," the Trickle timer resets. If I is greater than Imin, JP> how could = that happen that I < Imin?resetting a Trickle timer sets I to Imin and begins a new interval. If I is equal to Imin, resetting a Trickle timer does nothing. Trickle may also reset the timer in response to external "events." The terms consistent, inconsistent and event are in quotes because their meaning depends on the use of Trickle. 5. Using Trickle A protocol specification that uses Trickle MUST specify: Levis, et al. Expires January 7, 2011 [Page 6] =0C Internet-Draft draft-ietf-roll-trickle-02 July 2010 o Default values for Imin, Imax, and k. JP> s/Default = values/ValueBecause link layers can vary widely in their properties, the default JP> remove = "default"value of Imin should be specified in terms of the worst-case latency of a link layer transmission. For example, a specification should say "the default value of Imin is 4 times the worst case link layer latency" JP> may be worth how you define "latency"and should not = say "the default value of Imin is 500 milliseconds." Worst case latency is the time until the first link-layer transmission of the frame assuming an idle channel (does not include backoff, virtual carrier sense, etc.). o What constitutes a "consistent" transmission. o What constitutes an "inconsistent" transmission. o What "events," if any, besides inconsistent transmissions that reset the Trickle timer. 6. Operational Considerations It is RECOMMENDED that a protocol which uses Trickle include mechanisms to inform nodes of configuration parameters at runtime. However, it is not always possible to do so. In the cases where different nodes have different configuration parameters, Trickle may have unintended behaviors. This section outlines some of those behaviors and operational considerations as educational exercises. 6.1. Mismatched redundancy constants If nodes do not agree on the redundancy constant k, then nodes with higher values of k will transmit more often than nodes with lower values of k. In some cases, this increased load can be independent of the density. For example, consider a network where all nodes but one have k=3D1, and this one node has k=3D2. The different node can = end up transmitting on every interval: it is maintaining a communication rate of 2 with only itself. Hence, the danger of mismatched k values is uneven transmission load that can deplete the energy of some nodes.JP> Still this does not lead to interoperability issues.Don't = we want to recommend consistent configuration ? If you agree, thenthese = comments should go at the end of this section (or beginning) but = theyapply to several kind of mismatches 6.2. Mismatched Imin If = nodes do not agree on Imin, then some nodes, on hearing inconsistent = messages, will transmit sooner than others. These faster nodes will = have their intervals grow to similar size as the slower nodes within a = single slow interval time, but in that period may suppress the slower = nodes. However, such suppression will end after the first slow = interval, when the nodes generally agree on the interval size. Hence, = mismatched Imin values are usually not a Levis, et al. = Expires January 7, 2011 [Page 7] =0C Internet-Draft = draft-ietf-roll-trickle-02 July 2010 significant = concern. 6.3. Mismatched Imax If nodes do not agree on Imax, then = this can cause long-term problems with transmission load. Nodes with = small Imax values will transmit faster, suppressing those with larger = Imax values. The nodes with larger Imax values, always suppressed, = will never transmit. In the base case, when the network is = consistent, this can cause long-term inequities in energy cost. 6.4. = Mismatched definitions If nodes do not agree on what constitutes a = consistent or inconsistent transmission, then Trickle may fail to = operate properly. For example, if a receiver thinks a transmission is = consistent, but the transmitter (if in the receivers situation) would = have thought it inconsistent, then the receiver will not respond = properly and inform the transmitter. This can lead the network to not = reach a consistent state. For this reason, unlike the configuration = constants k, Imin, and Imax, consistency definitions should be clearly = stated in the protocol and should not be configured at runtime. JP> I = would suggest a MUST instead of a should in the sentence above.6.5. = Specifying the constant k There are some edge cases where a protocol may wish to use Trickle with its suppression disabled (k is set to infinity). In general, this approach is highly dangerous and it is NOT RECOMMENDED.JP> I = would strongly suggest to soften this statement. Just explain = theconsequences. Disabling suppression means that every node will = always send on every interval, and can lead to congestion in dense networks. This approach is especially dangerous JP> same commentif many nodes reset = their intervals at the same time. In general, it is much more desirable to set k to a high value (e.g., 5 or 10) than infinity. Typical values for k are 1-5: these achieve a good balance between redundancy and low cost. JP> I would suggest to add refs here. Nevertheless, there are = situations where a protocol may wish to turn off Trickle suppression. Because k is a natural number (Section 4.1), c=3D0 has no useful meaning. If a protocol allows k = to be dynamically configured, a value of 0 remains unused. For ease of debugging and packet inspection, having the parameter describe = (c-1)JP> c-1 ? can be counter-productive. Instead, it is RECOMMENDED = that protocols which require turning off suppression reserve c=3D0 to = mean c=3Dinfinity. 6.6. Relationship between k and Imin Finally, a = protocol SHOULD set k and Imin such that Imin is at least two to three = as long as it takes to transmit k packets. Otherwise, if more than k = nodes reset their intervals to Imin, the resulting Levis, et al. = Expires January 7, 2011 [Page 8] =0C Internet-Draft = draft-ietf-roll-trickle-02 July 2010 communication = will lead to congestion and significant packet loss. Experimental = results have shown that packet losses from congestion reduce Trickle's = efficiency [Levis04].JP> Well ... it is true in most networks, but may = not be completely applicable tonon wireless networks though. You may = want to mention it. 6.7. Tweaks and improvements to Trickle Trickle = is based on a small number of simple, tightly integrated mechanisms = that are highly robust to challenging network environments. >>In = our experiences using Trickle, attempts to tweak its behavior are typically not worth the cost. As written, the algorithm is already highly efficient: further reductions in transmissions or response time come at the cost of failures in edge cases. Based on our experiences, we urge protocol designers to suppress the instinct to tweak or improve Trickle without a great deal of experimental evidence that the change does not violate its assumptions and break the algorithm in edge cases.< You may want = to soften this statement. This warning in mind, Trickle is far from = perfect. JP> nobody's perfect. Not needed in the document.For example, Trickle suppression typically leads sparser nodes to transmit more than denser ones; it is far from the optimal computation of a minimum cover. However, in dynamic network environments such as wireless, the coordination needed to compute the optimal set of transmissions is typically much greater than the benefits it provides. One of the benefits of Trickle JP> s/Trickle/the Trickle algorithmis that it is = so simple to implement and requires so little state yet operates so efficiently. Efforts to improve it should be weighed against the cost of increased complexity. 7. Acknowledgements JP> to be done 8. IANA Considerations This document has no IANA = considerations. 9. Security Considerations This document has no = security considerations. 10. References 10.1. Normative References = [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate = Requirement Levels", BCP 14, RFC 2119, March 1997. Levis, et al. = Expires January 7, 2011 [Page 9] =0C Internet-Draft = draft-ietf-roll-trickle-02 July 2010 10.2. = Informative References [Levis04] Levis, P., Patel, N., Culler, D., = and S. Shenker, "Trickle: A Self-Regulating Algorithm for = Code Propagation and Maintenance in Wireless Sensor = Networks"", Proceedings of the First USENIX/ACM Symposium = on Networked Systems Design and Implementation NSDI 2004, = March 2004, = . [Levis08] Levis, = P., Brewer, E., Culler, D., Gay, D., Madden, S., Patel, N., = Polastre, J., Shenker, S., Szewczyk, R., and A. Woo, "The = Emergence of a Networking Primitive in Wireless Sensor = Networks", Communications of the ACM, v.51 n.7, July 2008, = . Authors' = Addresses Philip Levis Stanford University 358 Gates Hall, = Stanford University Stanford, CA 94305 USA Phone: +1 650 725 = 9064 Email: pal@cs.stanford.edu Thomas Heide Clausen LIX, Ecole = Polytechnique Phone: +33 6 6058 9349 Email: T.Clausen@computer.org = Jonathan Hui Arch Rock Corporation 501 Snd St., Suite 410 San = Francisco, CA 94107 USA Email: jhui@archrock.com Levis, et al. = Expires January 7, 2011 [Page 10] =0C = Internet-Draft draft-ietf-roll-trickle-02 July 2010 = Omprakash Gnawali Stanford University S255 Clark Center, 318 = Campus Drive Stanford, CA 94305 USA Phone: +1 650 725 6086 = Email: gnawali@cs.stanford.edu JeongGil Ko Johns Hopkins University = 3400 N. Charles St., 224 New Engineering Building Baltimore, MD = 21218 USA Phone: +1 410 516 4312 Email: jgko@cs.jhu.edu Levis, et = al. Expires January 7, 2011 [Page 11] =0C Thanks. JP. On Jul 28, 2010, at 10:05 AM, JP Vasseur wrote: Dear WG, draft-ietf-roll-trickle-02 is stable and now ready for WG Last = Call. This starts a 2-week Working Group last call ending on August 11 = at 9:00am ET. Please send your comments to the authors and the list. Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll -------------------------------------------------------------------------= ----- _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_0180_01CB3336.8F279E60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I vote for moving trickle to Std=20 track.
----- Original Message -----
From:=20 JP Vasseur =
To: ROLL WG
Sent: Tuesday, August 03, 2010 = 3:36=20 PM
Subject: [Roll] Fwd: WG Last = Call on=20 draft-ietf-roll-trickle-02



Begin forwarded message:

From: JP Vasseur = <jpv@cisco.com>
Date: August 3, = 2010 3:35:41 PM=20 CEDT
To: JP Vasseur = <jpv@cisco.com>
Cc: ROLL WG = <roll@ietf.org>
Subject: = Re: = [Roll] WG Last=20 Call on draft-ietf-roll-trickle-02

Please=20 find below comments on draft-ietf-roll-trickle-02 (search for = JP>).
Co-chair hat on (shepherding the document)

Networking Working Group                          =
              P. Levis
Internet-Draft                                       Stanford University
Intended status: Informational                                T. =
Clausen
JP> So far good =
consensus to move to Std track. Let's wait until
end of LC.
Expires: January =
7, 2011                        LIX, Ecole Polytechnique
                                                                  J. Hui
                                                   Arch Rock Corporation
                                                              O. Gnawali
                                                     Stanford University
                                                                   J. Ko
                                                Johns Hopkins University
                                                            July 6, 2010


                         The Trickle Algorithm
                       draft-ietf-roll-trickle-02

Abstract

   The Trickle algorithm allows wireless nodes to exchange information

JP> Not restricted to wireless. Even if we =
do not use some features, dynamic
timer adjustments are still useful in PLC/wired =
environments.
   in a highly robust, energy =
efficient, simple, and scalable manner.
   Dynamically adjusting transmission windows allows Trickle to spread
   new information on the scale of link-layer transmission times while
   sending only a few messages per hour 
JP> I would suggest to be more generic (not =
specify "hour", "mn", since 
that all depends on the parameter =
settings)
when information does not
   change.  A simple suppression mechanism and transmission point
   selection allows Trickle's communication rate to scale
   logarithmically with density.  This document describes =
Trickle 
JP> s/trickle/the trickle =
algorithm
and
   considerations in its use.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/i=
etf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html<=
/A>.



Levis, et al.            Expires January 7, 2011                [Page 1]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


   This Internet-Draft will expire on January 7, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/lic=
ense-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.



































Levis, et al.            Expires January 7, 2011                [Page 2]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Trickle Algorithm Overview  . . . . . . . . . . . . . . . . . . 3
   4.  Trickle Algorithm . . . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  Parameters and Variables  . . . . . . . . . . . . . . . . . 4
     4.2.  Algorithm Description . . . . . . . . . . . . . . . . . . . 5
   5.  Using Trickle . . . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Operational Considerations  . . . . . . . . . . . . . . . . . . 6
     6.1.  Mismatched redundancy constants . . . . . . . . . . . . . . 6
     6.2.  Mismatched Imin . . . . . . . . . . . . . . . . . . . . . . 6
     6.3.  Mismatched Imax . . . . . . . . . . . . . . . . . . . . . . 7
     6.4.  Mismatched definitions  . . . . . . . . . . . . . . . . . . 7
     6.5.  Specifying the constant k . . . . . . . . . . . . . . . . . 7
     6.6.  Relationship between k and Imin . . . . . . . . . . . . . . 7
     6.7.  Tweaks and improvements to Trickle  . . . . . . . . . . . . 8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9



























Levis, et al.            Expires January 7, 2011                [Page 3]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


1.  Introduction

   The Trickle algorithm is designed for wireless networks. =
 
JP> please use the LLN terminology and point =
to [I-D-ietf.roll-terminology] ID.
It
   establishes a density-aware local broadcast with an underlying
   consistency model that guides when a node communicates.  When a
   node's data does not agree 
JP> you may want to clarify the term =
"agree"
with its neighbors, it communicates
   quickly to resolve the inconsistency.  
JP> Please define "inconsistency" (an =
example should suffice)
When nodes agree, =
they slow
   their communication rate exponentially, such that nodes send at most
   a few packets per hour.  
JP> See comments on =
"hour"
Instead of flooding a network with packets,
   the algorithm controls the send rate so each node hears a =
small
JP> avoid "small", "large", ... it is all =
relative.
   trickle of packets, just enough to stay =
consistent.  Furthermore, by
   relying only on local broadcasts, 
JP> broadcast or =
multicast
Trickle handles network re-
   population, 
JP> Define =
"re-population"
is robust to network transience, =
loss, and disconnection,
   and requires very little state (implementations use 4-11 bytes).

JP> Mention that current implementations =
typically requires .... 
   While Trickle =
was originally designed for reprogramming protocols
   (where the data is the code of the program being updated), experience
   has shown it to be a powerful mechanism that can be applied to wide
   range of protocol design problems, including control traffic timing,
   multicast propagation, and route discovery.

   This document describes the Trickle algorithm and provides guidelines
   for its use.  It also states requirements for protocol specifications
   that use Trickle.  This document does not provide results on
   Trickle's performance or behavior, nor does it explain the
   algorithm's design in detail: interested readers should refer to
   [Levis04] and [Levis08].


2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].


3.  Trickle Algorithm Overview

   Trickle's basic primitive is simple: every so often, a node transmits
   code metadata 
JP> s/code metadata/information (e.g. =
routing protocol, software updates, ...)

if it has not =
heard a few other nodes transmit the same
   thing.  
JP> =
s/thing/information
This allows Trickle to scale to =
thousand-fold variations in
   network density, quickly propagate updates, distribute transmission
   load evenly, be robust to transient disconnections, handle network
   repopulations, and impose a maintenance overhead on the order of a
   few packets per hour.
JP> same comment about =
"hour"
   Trickle sends all messages to the local =
broadcast address.  
JP> or multicast (to be updated throughout =
the document)

There are



Levis, et al.            Expires January 7, 2011                [Page 4]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


   two possible results to a Trickle broadcast: either every node that
   hears the message is up to date, or a recipient detects the need for
   an update.  Detection can be the result of either an out-of-date node
   hearing someone has new code, or an updated node hearing someone has
   old code.  
JP> this comes from one application of =
trickle (code update), could you make it
more general (e.g. fresher =
information)
As long as every node communicates =
somehow - either
   receives or transmits - the need for an update will be detected.

   For example, consider a simple case where "up to date" is defined by
   version numbers (e.g., network configuration).  If node A broadcasts
   that it has version V, but B has version V+1, then B knows that A
   needs an update.  Similarly, if B broadcasts that it has =
V+1
JP> s/V+1/version =
V+1
, A knows
   that it needs an update.  If B broadcasts updates, then all of its
   neighbors can receive them without having to advertise their need.
   Some of these recipients might not even have heard A's transmission.

   In this example, it does not matter who first transmits, A or B;
   either case will detect the inconsistency.  All that matters is that
   some nodes communicate with one another at some nonzero rate.  As
   long as the network is connected and there is some minimum
   communication rate for each node, the network will reach eventual
   consistency.

   The fact that communication can be either transmission or reception
   enables Trickle 
JP> s/Trickle/the Trickle =
algorithm
to operate in sparse as well as dense networks.  =
A
   single, disconnected node must transmit at the communication rate.
   In a lossless, single-hop network of size n, the sum of transmissions
   over the network is the communication rate, so for each node it is
   1/n.  Sparser networks require more transmissions per node, but
   utilization of the radio channel over space will not increase.  This
   is an important property in wireless networks, 
JP> and other shared =
media
where the channel is a
   valuable shared resource.  Additionally, reducing transmissions in
   dense networks conserves system energy.


4.  Trickle Algorithm

   This section describes the Trickle algorithm.

4.1.  Parameters and Variables

   A Trickle timer has three configuration parameters: the minimum
   interval size Imin, the maximum interval size Imax, and a redundancy
   constant k:

   o  The minimum interval size is defined in units of time (e.g.,
      milliseconds, seconds).  For example, a protocol might define the
      minimum interval as 100 milliseconds.




Levis, et al.            Expires January 7, 2011                [Page 5]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


   o  The maximum interval size is described as a number of doublings of
      the minimum interval size (the base-2 log(max/min)).  For example,
      a protocol might define the maximum interval as 16.  If the
      minimum interval is 100ms, then the maximum interval is 100ms *
      65536, 6,553.6 seconds, or approximately 109 minutes.

   o  The redundancy constant is a natural number (an integer greater
      than zero).
JP> Could be equal to infinity (and encoded =
as 0) =3D> no suppression.
   In addition to these =
three parameters, Trickle maintains three   variables:    o  I, the =
current interval size    o  t, a time within the current interval, and   =
 o  c, a counter.

4.2.  Algorithm Description

   The Trickle algorithm has five rules:

   1.  When an interval begins, Trickle resets c to 0 and sets t to a
       random point in the interval, taken from the range [I/2, I).

JP> s/I)/I]
   2.  Whenever =
Trickle hears a transmission that is "consistent," it
       increments counter c.

   3.  At time t, Trickle transmits if and only if counter c is less
       than the redundancy constant k.

   4.  When an interval expires, 
JP> this may not be obvious first time you =
read it. interval=3Dt or I (question
was asked on the mailing list in =
the past).
Trickle doubles the interval length.
       If this new interval length would be longer than Imax, Trickle
       sets the interval length I to be Imax.

   5.  If Trickle hears a transmission that is "inconsistent," the
       Trickle timer resets.  If I is greater than Imin, 
JP> how could that happen that I < =
 Imin?
resetting a
       Trickle timer sets I to Imin and begins a new interval.  If I is
       equal to Imin, resetting a Trickle timer does nothing.  Trickle
       may also reset the timer in response to external "events."

   The terms consistent, inconsistent and event are in quotes because
   their meaning depends on the use of Trickle.


5.  Using Trickle

   A protocol specification that uses Trickle MUST specify:



Levis, et al.            Expires January 7, 2011                [Page 6]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


   o  Default values for Imin, Imax, and k.  
JP> s/Default =
values/Value
Because link layers can
      vary widely in their properties, the default 
JP> remove =
"default"
value of Imin should
      be specified in terms of the worst-case latency of a link layer
      transmission.  For example, a specification should say "the
      default value of Imin is 4 times the worst case link layer
      latency" 
JP> may be worth how you define =
"latency"
and should not say "the default value of Imin is =
500
      milliseconds."  Worst case latency is the time until the first
      link-layer transmission of the frame assuming an idle channel
      (does not include backoff, virtual carrier sense, etc.).

   o  What constitutes a "consistent" transmission.

   o  What constitutes an "inconsistent" transmission.

   o  What "events," if any, besides inconsistent transmissions that
      reset the Trickle timer.


6.  Operational Considerations

   It is RECOMMENDED that a protocol which uses Trickle include
   mechanisms to inform nodes of configuration parameters at runtime.
   However, it is not always possible to do so.  In the cases where
   different nodes have different configuration parameters, Trickle may
   have unintended behaviors.  This section outlines some of those
   behaviors and operational considerations as educational exercises.

6.1.  Mismatched redundancy constants

   If nodes do not agree on the redundancy constant k, then nodes with
   higher values of k will transmit more often than nodes with lower
   values of k.  In some cases, this increased load can be independent
   of the density.  For example, consider a network where all nodes but
   one have k=3D1, and this one node has k=3D2.  The different node can =
end
   up transmitting on every interval: it is maintaining a communication
   rate of 2 with only itself.  Hence, the danger of mismatched k values
   is uneven transmission load that can deplete the energy of some
   nodes.
JP> Still this does not lead to =
interoperability issues.
Don't we want to recommend consistent =
configuration ? If you agree, then
these comments =
should go at the end of this section (or beginning) but =
they
apply to several kind of =
mismatches
 6.2.  Mismatched Imin    If nodes =
do not agree on Imin, then some nodes, on hearing   inconsistent =
messages, will transmit sooner than others.  These   faster nodes will =
have their intervals grow to similar size as the   slower nodes within a =
single slow interval time, but in that period   may suppress the slower =
nodes.  However, such suppression will end   after the first slow =
interval, when the nodes generally agree on the   interval size.  Hence, =
mismatched Imin values are usually not a Levis, et al.            =
Expires January 7, 2011                [Page 7] =0C Internet-Draft       =
  draft-ietf-roll-trickle-02              July 2010    significant =
concern. 6.3.  Mismatched Imax    If nodes do not agree on Imax, then =
this can cause long-term problems   with transmission load.  Nodes with =
small Imax values will transmit   faster, suppressing those with larger =
Imax values.  The nodes with   larger Imax values, always suppressed, =
will never transmit.  In the   base case, when the network is =
consistent, this can cause long-term   inequities in energy cost. 6.4.  =
Mismatched definitions    If nodes do not agree on what constitutes a =
consistent or   inconsistent transmission, then Trickle may fail to =
operate properly.   For example, if a receiver thinks a transmission is =
consistent, but   the transmitter (if in the receivers situation) would =
have thought it   inconsistent, then the receiver will not respond =
properly and inform   the transmitter.  This can lead the network to not =
reach a consistent   state.  For this reason, unlike the configuration =
constants k, Imin,   and Imax, consistency definitions should be clearly =
stated in the   protocol and should not be configured at runtime. =

JP> I would suggest a MUST instead of a =
should in the sentence above.
6.5.  Specifying =
the constant k

   There are some edge cases where a protocol may wish to use Trickle
   with its suppression disabled (k is set to infinity).  In general,
   this approach is highly dangerous and it is NOT =
RECOMMENDED.
JP> I would strongly suggest to soften this =
statement. Just explain the
consequences.
   Disabling =
suppression means that every node will always send on every
   interval, and can lead to congestion in dense networks.  This
   approach is especially dangerous 
JP> same =
comment
if many nodes reset their intervals
   at the same time.  In general, it is much more desirable to set k to
   a high value (e.g., 5 or 10) than infinity.  Typical values for k are
   1-5: these achieve a good balance between redundancy and low cost.

JP> I would suggest to add refs =
here.
   Nevertheless, there are situations where a =
protocol may wish to turn
   off Trickle suppression.  Because k is a natural number
   (Section 4.1), c=3D0 has no useful meaning.  If a protocol allows k =
to
   be dynamically configured, a value of 0 remains unused.  For ease of
   debugging and packet inspection, having the parameter describe =
(c-1)
JP> c-1 ?
   can be =
counter-productive.  Instead, it is RECOMMENDED that protocols   which =
require turning off suppression reserve c=3D0 to mean c=3Dinfinity. 6.6. =
 Relationship between k and Imin    Finally, a protocol SHOULD set k and =
Imin such that Imin is at least   two to three as long as it takes to =
transmit k packets.  Otherwise,   if more than k nodes reset their =
intervals to Imin, the resulting Levis, et al.            Expires =
January 7, 2011                [Page 8] =0C Internet-Draft         =
draft-ietf-roll-trickle-02              July 2010    communication will =
lead to congestion and significant packet loss.   Experimental results =
have shown that packet losses from congestion   reduce Trickle's =
efficiency [Levis04].
JP> Well ... it is true in most networks, =
but may not be completely applicable to
non wireless networks though. =
You may want to mention =
it.
 6.7.  =
Tweaks and improvements to Trickle    Trickle is based on a small number =
of simple, tightly integrated   mechanisms that are highly robust to =
challenging network   environments.  

   >>In our experiences using =
Trickle, attempts to tweak
   its behavior are typically not worth the cost.  As written, the
   algorithm is already highly efficient: further reductions in
   transmissions or response time come at the cost of failures in edge
   cases.  Based on our experiences, we urge protocol designers to
   suppress the instinct to tweak or improve Trickle without a great
   deal of experimental evidence that the change does not violate its
   assumptions and break the algorithm in edge cases.<<
JP> You may want to soften this =
statement.
   This warning in mind, Trickle is far from =
perfect.  
JP> nobody's perfect. Not needed in the =
document.
For example,
   Trickle suppression typically leads sparser nodes to transmit more
   than denser ones; it is far from the optimal computation of a minimum
   cover.  However, in dynamic network environments such as wireless,
   the coordination needed to compute the optimal set of transmissions
   is typically much greater than the benefits it provides.  One of the
   benefits of Trickle 
JP> s/Trickle/the Trickle =
algorithm
is that it is so simple to implement and requires
   so little state yet operates so efficiently.  Efforts to improve it
   should be weighed against the cost of increased complexity.


7.  Acknowledgements

JP> to be done
 8.  IANA =
Considerations    This document has no IANA considerations. 9.  Security =
Considerations    This document has no security considerations. 10.  =
References 10.1.  Normative References    [RFC2119]  Bradner, S., "Key =
words for use in RFCs to Indicate              Requirement Levels", BCP =
14, RFC 2119, March 1997. Levis, et al.            Expires January 7, =
2011                [Page 9] =0C Internet-Draft         =
draft-ietf-roll-trickle-02              July 2010 10.2.  Informative =
References    [Levis04]  Levis, P., Patel, N., Culler, D., and S. =
Shenker,              "Trickle: A Self-Regulating Algorithm for Code =
Propagation              and Maintenance in Wireless Sensor Networks"", =
Proceedings              of the First USENIX/ACM Symposium on Networked =
Systems              Design and Implementation NSDI 2004, March 2004,    =
          <http://portal.ac=
m.org/citation.cfm?id=3D1251177>.    [Levis08]  Levis, P., =
Brewer, E., Culler, D., Gay, D., Madden, S.,              Patel, N., =
Polastre, J., Shenker, S., Szewczyk, R., and A.              Woo, "The =
Emergence of a Networking Primitive in Wireless              Sensor =
Networks", Communications of the ACM, v.51 n.7,              July 2008,  =
            <http://portal.ac=
m.org/citation.cfm?id=3D1364804>. Authors' Addresses    Philip =
Levis   Stanford University   358 Gates Hall, Stanford University   =
Stanford, CA  94305   USA    Phone: +1 650 725 9064   Email: pal@cs.stanford.edu    Thomas =
Heide Clausen   LIX, Ecole Polytechnique    Phone: +33 6 6058 9349   =
Email: T.Clausen@computer.org    =
Jonathan Hui   Arch Rock Corporation   501 Snd St., Suite 410   San =
Francisco, CA  94107   USA    Email: jhui@archrock.com Levis, et al.    =
        Expires January 7, 2011               [Page 10] =0C =
Internet-Draft         draft-ietf-roll-trickle-02              July 2010 =
   Omprakash Gnawali   Stanford University   S255 Clark Center, 318 =
Campus Drive   Stanford, CA  94305   USA    Phone: +1 650 725 6086   =
Email: gnawali@cs.stanford.edu    =
JeongGil Ko   Johns Hopkins University   3400 N. Charles St., 224 New =
Engineering Building   Baltimore, MD  21218   USA    Phone: +1 410 516 =
4312   Email: jgko@cs.jhu.edu =
Levis, et al.            Expires January 7, 2011               [Page 11] =
=0C

Thanks.

JP.

On Jul 28, 2010, at 10:05 AM, JP Vasseur wrote:
Dear WG,

draft-ietf-roll-trickle-02 is stable and now = ready for WG=20 Last Call.

This starts a 2-week Working Group last call = ending on=20 August 11 at 9:00am ET.

Please send your comments to the = authors=20 and the=20 = list.

Thanks.

JP.
_______________________= ________________________
Roll=20 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
------=_NextPart_000_0180_01CB3336.8F279E60-- From d.sturek@att.net Tue Aug 3 10:03:18 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D7A13A6AAB for ; Tue, 3 Aug 2010 10:03:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.386 X-Spam-Level: X-Spam-Status: No, score=0.386 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_18=0.6, J_CHICKENPOX_81=0.6, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 45baMIoRO4ty for ; Tue, 3 Aug 2010 10:02:53 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 375A83A6A82 for ; Tue, 3 Aug 2010 10:02:50 -0700 (PDT) Received: (qmail 38382 invoked from network); 3 Aug 2010 17:03:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1280854993; bh=HqvbzuarzHG9QXepF11wOvsFTeukSIldAqjuWWwtitI=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:thread-index:Content-Language; b=yRmdu6ZHMrHr5JH/mTTuDFwbNaeEEZAQyC0BiQGu86bSX6aAoQ98RpWRmnAjUOn6tv9qEqvftd5I69arM1c2+3jZmULUb7eDIXtNF/0OxgBAmVPYMs8ZIovghAhzfZ/BH0aJSaaDjf3oqb1Y3yjf+vgkfEJptqiumtCkoi/Tf0U= Received: from Studio (d.sturek@174.78.56.227 with login) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 03 Aug 2010 10:03:13 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: JwC3oB0VM1k0ac34wNQRKMWBJWG5AGz40MqGIXa1ZXt5wNt P7uYJRfgQQkn4Zr1dSHnIFVwAuJnRVMqNKPaxwvtp1.OxExQp5yI1RATfA24 bCfemB8R9fTi6O16V5e_TL4igPvXlzNGgASJSiInYhNZSjyKlxIkJ481s7tl akNRQYP0TQmfjIcstKi9.SSDWa1eCfk9dBeqWPjaKmXlH5RmhL1DPZa8NE0T Uy.boGabWP8QMmLkNl6ktvVsdK8XBVzZxdILLn08sstwLjh2vl82F0YNbkZb CRPSCkUMTT8UxgTD5w9w- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'JP Vasseur'" , "'ROLL WG'" References: <5FB5C986-D72B-41D9-A193-275DEB1D71A3@cisco.com> In-Reply-To: Date: Tue, 3 Aug 2010 10:03:11 -0700 Message-ID: <008801cb332d$c1870f70$44952e50$@sturek@att.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0089_01CB32F3.15283770" X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcszENvHJMtPauIZRsW6AZ05JaBoHgAHNnXg Content-Language: en-us Subject: Re: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 17:03:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0089_01CB32F3.15283770 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit +1 on making the Trickle draft standards track... Don From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Tuesday, August 03, 2010 6:36 AM To: ROLL WG Subject: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 Begin forwarded message: From: JP Vasseur Date: August 3, 2010 3:35:41 PM CEDT To: JP Vasseur Cc: ROLL WG Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 Please find below comments on draft-ietf-roll-trickle-02 (search for JP>). Co-chair hat on (shepherding the document) Networking Working Group P. Levis Internet-Draft Stanford University Intended status: Informational T. Clausen JP> So far good consensus to move to Std track. Let's wait until end of LC. Expires: January 7, 2011 LIX, Ecole Polytechnique J. Hui Arch Rock Corporation O. Gnawali Stanford University J. Ko Johns Hopkins University July 6, 2010 The Trickle Algorithm draft-ietf-roll-trickle-02 Abstract The Trickle algorithm allows wireless nodes to exchange information JP> Not restricted to wireless. Even if we do not use some features, dynamic timer adjustments are still useful in PLC/wired environments. in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour JP> I would suggest to be more generic (not specify "hour", "mn", since that all depends on the parameter settings) when information does not change. A simple suppression mechanism and transmission point selection allows Trickle's communication rate to scale logarithmically with density. This document describes Trickle JP> s/trickle/the trickle algorithm and considerations in its use. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Levis, et al. Expires January 7, 2011 [Page 1] Internet-Draft draft-ietf-roll-trickle-02 July 2010 This Internet-Draft will expire on January 7, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Levis, et al. Expires January 7, 2011 [Page 2] Internet-Draft draft-ietf-roll-trickle-02 July 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Trickle Algorithm Overview . . . . . . . . . . . . . . . . . . 3 4. Trickle Algorithm . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Parameters and Variables . . . . . . . . . . . . . . . . . 4 4.2. Algorithm Description . . . . . . . . . . . . . . . . . . . 5 5. Using Trickle . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Operational Considerations . . . . . . . . . . . . . . . . . . 6 6.1. Mismatched redundancy constants . . . . . . . . . . . . . . 6 6.2. Mismatched Imin . . . . . . . . . . . . . . . . . . . . . . 6 6.3. Mismatched Imax . . . . . . . . . . . . . . . . . . . . . . 7 6.4. Mismatched definitions . . . . . . . . . . . . . . . . . . 7 6.5. Specifying the constant k . . . . . . . . . . . . . . . . . 7 6.6. Relationship between k and Imin . . . . . . . . . . . . . . 7 6.7. Tweaks and improvements to Trickle . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Levis, et al. Expires January 7, 2011 [Page 3] Internet-Draft draft-ietf-roll-trickle-02 July 2010 1. Introduction The Trickle algorithm is designed for wireless networks. JP> please use the LLN terminology and point to [I-D-ietf.roll-terminology] ID. It establishes a density-aware local broadcast with an underlying consistency model that guides when a node communicates. When a node's data does not agree JP> you may want to clarify the term "agree" with its neighbors, it communicates quickly to resolve the inconsistency. JP> Please define "inconsistency" (an example should suffice) When nodes agree, they slow their communication rate exponentially, such that nodes send at most a few packets per hour. JP> See comments on "hour" Instead of flooding a network with packets, the algorithm controls the send rate so each node hears a small JP> avoid "small", "large", ... it is all relative. trickle of packets, just enough to stay consistent. Furthermore, by relying only on local broadcasts, JP> broadcast or multicast Trickle handles network re- population, JP> Define "re-population" is robust to network transience, loss, and disconnection, and requires very little state (implementations use 4-11 bytes). JP> Mention that current implementations typically requires .... While Trickle was originally designed for reprogramming protocols (where the data is the code of the program being updated), experience has shown it to be a powerful mechanism that can be applied to wide range of protocol design problems, including control traffic timing, multicast propagation, and route discovery. This document describes the Trickle algorithm and provides guidelines for its use. It also states requirements for protocol specifications that use Trickle. This document does not provide results on Trickle's performance or behavior, nor does it explain the algorithm's design in detail: interested readers should refer to [Levis04] and [Levis08]. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. Trickle Algorithm Overview Trickle's basic primitive is simple: every so often, a node transmits code metadata JP> s/code metadata/information (e.g. routing protocol, software updates, ...) if it has not heard a few other nodes transmit the same thing. JP> s/thing/information This allows Trickle to scale to thousand-fold variations in network density, quickly propagate updates, distribute transmission load evenly, be robust to transient disconnections, handle network repopulations, and impose a maintenance overhead on the order of a few packets per hour. JP> same comment about "hour" Trickle sends all messages to the local broadcast address. JP> or multicast (to be updated throughout the document) There are Levis, et al. Expires January 7, 2011 [Page 4] Internet-Draft draft-ietf-roll-trickle-02 July 2010 two possible results to a Trickle broadcast: either every node that hears the message is up to date, or a recipient detects the need for an update. Detection can be the result of either an out-of-date node hearing someone has new code, or an updated node hearing someone has old code. JP> this comes from one application of trickle (code update), could you make it more general (e.g. fresher information) As long as every node communicates somehow - either receives or transmits - the need for an update will be detected. For example, consider a simple case where "up to date" is defined by version numbers (e.g., network configuration). If node A broadcasts that it has version V, but B has version V+1, then B knows that A needs an update. Similarly, if B broadcasts that it has V+1 JP> s/V+1/version V+1 , A knows that it needs an update. If B broadcasts updates, then all of its neighbors can receive them without having to advertise their need. Some of these recipients might not even have heard A's transmission. In this example, it does not matter who first transmits, A or B; either case will detect the inconsistency. All that matters is that some nodes communicate with one another at some nonzero rate. As long as the network is connected and there is some minimum communication rate for each node, the network will reach eventual consistency. The fact that communication can be either transmission or reception enables Trickle JP> s/Trickle/the Trickle algorithm to operate in sparse as well as dense networks. A single, disconnected node must transmit at the communication rate. In a lossless, single-hop network of size n, the sum of transmissions over the network is the communication rate, so for each node it is 1/n. Sparser networks require more transmissions per node, but utilization of the radio channel over space will not increase. This is an important property in wireless networks, JP> and other shared media where the channel is a valuable shared resource. Additionally, reducing transmissions in dense networks conserves system energy. 4. Trickle Algorithm This section describes the Trickle algorithm. 4.1. Parameters and Variables A Trickle timer has three configuration parameters: the minimum interval size Imin, the maximum interval size Imax, and a redundancy constant k: o The minimum interval size is defined in units of time (e.g., milliseconds, seconds). For example, a protocol might define the minimum interval as 100 milliseconds. Levis, et al. Expires January 7, 2011 [Page 5] Internet-Draft draft-ietf-roll-trickle-02 July 2010 o The maximum interval size is described as a number of doublings of the minimum interval size (the base-2 log(max/min)). For example, a protocol might define the maximum interval as 16. If the minimum interval is 100ms, then the maximum interval is 100ms * 65536, 6,553.6 seconds, or approximately 109 minutes. o The redundancy constant is a natural number (an integer greater than zero). JP> Could be equal to infinity (and encoded as 0) => no suppression. In addition to these three parameters, Trickle maintains three variables: o I, the current interval size o t, a time within the current interval, and o c, a counter. 4.2. Algorithm Description The Trickle algorithm has five rules: 1. When an interval begins, Trickle resets c to 0 and sets t to a random point in the interval, taken from the range [I/2, I). JP> s/I)/I] 2. Whenever Trickle hears a transmission that is "consistent," it increments counter c. 3. At time t, Trickle transmits if and only if counter c is less than the redundancy constant k. 4. When an interval expires, JP> this may not be obvious first time you read it. interval=t or I (question was asked on the mailing list in the past). Trickle doubles the interval length. If this new interval length would be longer than Imax, Trickle sets the interval length I to be Imax. 5. If Trickle hears a transmission that is "inconsistent," the Trickle timer resets. If I is greater than Imin, JP> how could that happen that I < Imin? resetting a Trickle timer sets I to Imin and begins a new interval. If I is equal to Imin, resetting a Trickle timer does nothing. Trickle may also reset the timer in response to external "events." The terms consistent, inconsistent and event are in quotes because their meaning depends on the use of Trickle. 5. Using Trickle A protocol specification that uses Trickle MUST specify: Levis, et al. Expires January 7, 2011 [Page 6] Internet-Draft draft-ietf-roll-trickle-02 July 2010 o Default values for Imin, Imax, and k. JP> s/Default values/Value Because link layers can vary widely in their properties, the default JP> remove "default" value of Imin should be specified in terms of the worst-case latency of a link layer transmission. For example, a specification should say "the default value of Imin is 4 times the worst case link layer latency" JP> may be worth how you define "latency" and should not say "the default value of Imin is 500 milliseconds." Worst case latency is the time until the first link-layer transmission of the frame assuming an idle channel (does not include backoff, virtual carrier sense, etc.). o What constitutes a "consistent" transmission. o What constitutes an "inconsistent" transmission. o What "events," if any, besides inconsistent transmissions that reset the Trickle timer. 6. Operational Considerations It is RECOMMENDED that a protocol which uses Trickle include mechanisms to inform nodes of configuration parameters at runtime. However, it is not always possible to do so. In the cases where different nodes have different configuration parameters, Trickle may have unintended behaviors. This section outlines some of those behaviors and operational considerations as educational exercises. 6.1. Mismatched redundancy constants If nodes do not agree on the redundancy constant k, then nodes with higher values of k will transmit more often than nodes with lower values of k. In some cases, this increased load can be independent of the density. For example, consider a network where all nodes but one have k=1, and this one node has k=2. The different node can end up transmitting on every interval: it is maintaining a communication rate of 2 with only itself. Hence, the danger of mismatched k values is uneven transmission load that can deplete the energy of some nodes. JP> Still this does not lead to interoperability issues. Don't we want to recommend consistent configuration ? If you agree, then these comments should go at the end of this section (or beginning) but they apply to several kind of mismatches 6.2. Mismatched Imin If nodes do not agree on Imin, then some nodes, on hearing inconsistent messages, will transmit sooner than others. These faster nodes will have their intervals grow to similar size as the slower nodes within a single slow interval time, but in that period may suppress the slower nodes. However, such suppression will end after the first slow interval, when the nodes generally agree on the interval size. Hence, mismatched Imin values are usually not a Levis, et al. Expires January 7, 2011 [Page 7] Internet-Draft draft-ietf-roll-trickle-02 July 2010 significant concern. 6.3. Mismatched Imax If nodes do not agree on Imax, then this can cause long-term problems with transmission load. Nodes with small Imax values will transmit faster, suppressing those with larger Imax values. The nodes with larger Imax values, always suppressed, will never transmit. In the base case, when the network is consistent, this can cause long-term inequities in energy cost. 6.4. Mismatched definitions If nodes do not agree on what constitutes a consistent or inconsistent transmission, then Trickle may fail to operate properly. For example, if a receiver thinks a transmission is consistent, but the transmitter (if in the receivers situation) would have thought it inconsistent, then the receiver will not respond properly and inform the transmitter. This can lead the network to not reach a consistent state. For this reason, unlike the configuration constants k, Imin, and Imax, consistency definitions should be clearly stated in the protocol and should not be configured at runtime. JP> I would suggest a MUST instead of a should in the sentence above. 6.5. Specifying the constant k There are some edge cases where a protocol may wish to use Trickle with its suppression disabled (k is set to infinity). In general, this approach is highly dangerous and it is NOT RECOMMENDED. JP> I would strongly suggest to soften this statement. Just explain the consequences. Disabling suppression means that every node will always send on every interval, and can lead to congestion in dense networks. This approach is especially dangerous JP> same comment if many nodes reset their intervals at the same time. In general, it is much more desirable to set k to a high value (e.g., 5 or 10) than infinity. Typical values for k are 1-5: these achieve a good balance between redundancy and low cost. JP> I would suggest to add refs here. Nevertheless, there are situations where a protocol may wish to turn off Trickle suppression. Because k is a natural number (Section 4.1), c=0 has no useful meaning. If a protocol allows k to be dynamically configured, a value of 0 remains unused. For ease of debugging and packet inspection, having the parameter describe (c-1) JP> c-1 ? can be counter-productive. Instead, it is RECOMMENDED that protocols which require turning off suppression reserve c=0 to mean c=infinity. 6.6. Relationship between k and Imin Finally, a protocol SHOULD set k and Imin such that Imin is at least two to three as long as it takes to transmit k packets. Otherwise, if more than k nodes reset their intervals to Imin, the resulting Levis, et al. Expires January 7, 2011 [Page 8] Internet-Draft draft-ietf-roll-trickle-02 July 2010 communication will lead to congestion and significant packet loss. Experimental results have shown that packet losses from congestion reduce Trickle's efficiency [Levis04]. JP> Well ... it is true in most networks, but may not be completely applicable to non wireless networks though. You may want to mention it. 6.7. Tweaks and improvements to Trickle Trickle is based on a small number of simple, tightly integrated mechanisms that are highly robust to challenging network environments. >>In our experiences using Trickle, attempts to tweak its behavior are typically not worth the cost. As written, the algorithm is already highly efficient: further reductions in transmissions or response time come at the cost of failures in edge cases. Based on our experiences, we urge protocol designers to suppress the instinct to tweak or improve Trickle without a great deal of experimental evidence that the change does not violate its assumptions and break the algorithm in edge cases.<< JP> You may want to soften this statement. This warning in mind, Trickle is far from perfect. JP> nobody's perfect. Not needed in the document. For example, Trickle suppression typically leads sparser nodes to transmit more than denser ones; it is far from the optimal computation of a minimum cover. However, in dynamic network environments such as wireless, the coordination needed to compute the optimal set of transmissions is typically much greater than the benefits it provides. One of the benefits of Trickle JP> s/Trickle/the Trickle algorithm is that it is so simple to implement and requires so little state yet operates so efficiently. Efforts to improve it should be weighed against the cost of increased complexity. 7. Acknowledgements JP> to be done 8. IANA Considerations This document has no IANA considerations. 9. Security Considerations This document has no security considerations. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Levis, et al. Expires January 7, 2011 [Page 9] Internet-Draft draft-ietf-roll-trickle-02 July 2010 10.2. Informative References [Levis04] Levis, P., Patel, N., Culler, D., and S. Shenker, "Trickle: A Self-Regulating Algorithm for Code Propagation and Maintenance in Wireless Sensor Networks"", Proceedings of the First USENIX/ACM Symposium on Networked Systems Design and Implementation NSDI 2004, March 2004, . [Levis08] Levis, P., Brewer, E., Culler, D., Gay, D., Madden, S., Patel, N., Polastre, J., Shenker, S., Szewczyk, R., and A. Woo, "The Emergence of a Networking Primitive in Wireless Sensor Networks", Communications of the ACM, v.51 n.7, July 2008, . Authors' Addresses Philip Levis Stanford University 358 Gates Hall, Stanford University Stanford, CA 94305 USA Phone: +1 650 725 9064 Email: pal@cs.stanford.edu Thomas Heide Clausen LIX, Ecole Polytechnique Phone: +33 6 6058 9349 Email: T.Clausen@computer.org Jonathan Hui Arch Rock Corporation 501 Snd St., Suite 410 San Francisco, CA 94107 USA Email: jhui@archrock.com Levis, et al. Expires January 7, 2011 [Page 10] Internet-Draft draft-ietf-roll-trickle-02 July 2010 Omprakash Gnawali Stanford University S255 Clark Center, 318 Campus Drive Stanford, CA 94305 USA Phone: +1 650 725 6086 Email: gnawali@cs.stanford.edu JeongGil Ko Johns Hopkins University 3400 N. Charles St., 224 New Engineering Building Baltimore, MD 21218 USA Phone: +1 410 516 4312 Email: jgko@cs.jhu.edu Levis, et al. Expires January 7, 2011 [Page 11] Thanks. JP. On Jul 28, 2010, at 10:05 AM, JP Vasseur wrote: Dear WG, draft-ietf-roll-trickle-02 is stable and now ready for WG Last Call. This starts a 2-week Working Group last call ending on August 11 at 9:00am ET. Please send your comments to the authors and the list. Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_000_0089_01CB32F3.15283770 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 on making the Trickle draft standards = track…….


Don

 

 

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = JP Vasseur
Sent: Tuesday, August 03, 2010 6:36 AM
To: ROLL WG
Subject: [Roll] Fwd: WG Last Call on = draft-ietf-roll-trickle-02

 

 

 

Begin forwarded message:



From: JP Vasseur <jpv@cisco.com>

=

Date: August 3, 2010 3:35:41 PM CEDT

To: JP Vasseur <jpv@cisco.com>

=

Cc: ROLL WG <roll@ietf.org>

=

Subject: Re: [Roll] WG Last Call on = draft-ietf-roll-trickle-02

 

Please find below comments on draft-ietf-roll-trickle-02 (search for JP>).

Co-chair hat on (shepherding the = document)

 

Networking Working =
Group           &n=
bsp;           &nb=
sp;  =
            &=
nbsp; P. =
Levis
Internet-Draft     &n=
bsp;           &nb=
sp;           &nbs=
p;         Stanford =
University
Intended status: =
Informational          =
            &=
nbsp;         T. =
Clausen
JP> So far good consensus to move to Std track. Let's =
wait until
end of LC.
Expires: January 7, =
2011           &nb=
sp;            =
LIX, Ecole =
Polytechnique
      &n=
bsp;           &nb=
sp;           &nbs=
p;            =
;            =
           J. =
Hui
        =
            &=
nbsp;           &n=
bsp;           &nb=
sp;      Arch Rock =
Corporation
      &nbs=
p;            =
;            =
            &=
nbsp;    =
            &=
nbsp; O. =
Gnawali
       &n=
bsp;           &nb=
sp;           &nbs=
p;            =
;         Stanford =
University
       =
;            =
            &=
nbsp;           &n=
bsp;           &nb=
sp;           J. =
Ko
        &=
nbsp;           &n=
bsp;           &nb=
sp;           &nbs=
p;   Johns Hopkins =
University
       =
;     =
            &=
nbsp;           &n=
bsp;           &nb=
sp;           July=
 6, =
2010
 
 
          &nbs=
p;            =
;  The Trickle =
Algorithm
       =
            &=
nbsp;   =
draft-ietf-roll-trickle-02
 
Abstract
 
  =
 The Trickle algorithm allows wireless nodes to exchange =
information
 
JP> Not restricted to wireless. Even if we do not use =
some features, dynamic
timer adjustments are still useful in PLC/wired =
environments.
   in a =
highly robust, energy efficient, simple, and scalable =
manner.
   Dynamically adjusting =
transmission windows allows Trickle to =
spread
   new information on the scale of =
link-layer transmission times while
   =
sending only a few messages per hour 
JP> I would suggest to be more generic (not specify =
"hour", "mn", =
since 
that all depends on the parameter =
settings)
when information =
does not
   change.  A simple =
suppression mechanism and transmission =
point
   selection allows Trickle's =
communication rate to scale
   =
logarithmically with density.  This document describes =
Trickle 
JP> s/trickle/the trickle =
algorithm
and
   =
considerations in its =
use.
 
Status of this =
Memo
 
   This =
Internet-Draft is submitted to IETF in full conformance with =
the
   provisions of BCP 78 and BCP =
79.
 
   =
Internet-Drafts are working documents of the Internet =
Engineering
   Task Force (IETF), its =
areas, and its working groups.  Note =
that
   other groups may also distribute =
working documents as Internet-
   =
Drafts.
 
   =
Internet-Drafts are draft documents valid for a maximum of six =
months
   and may be updated, replaced, =
or obsoleted by other documents at any
   =
time.  It is inappropriate to use Internet-Drafts as =
reference
   material or to cite them =
other than as "work in =
progress."
 
 &n=
bsp; The list of current Internet-Drafts can be accessed =
at
   http://www.ietf.org/i=
etf/1id-abstracts.txt.
 
   The list of Internet-Draft Shadow Directories can be = accessed at
   http://www.ietf.org/shadow.html<=
/a>.
 
 
 
Levis, et =
al.            =
Expires January 7, =
2011           &nb=
sp;    [Page =
1]
 
Internet-Draft &=
nbsp;       =
draft-ietf-roll-trickle-02        =
;      July =
2010
 
 
   This Internet-Draft will expire on January 7, =
2011.
 
Copyright =
Notice
 
   =
Copyright (c) 2010 IETF Trust and the persons identified as =
the
   document authors.  All rights =
reserved.
 
   =
This document is subject to BCP 78 and the IETF Trust's =
Legal
   Provisions Relating to IETF =
Documents
   (http://trustee.ietf.org/lic=
ense-info) in effect on the date =
of
   publication of this document.  =
Please review these documents
   =
carefully, as they describe your rights and restrictions with =
respect
   to this document.  Code =
Components extracted from this document =
must
   include Simplified BSD License =
text as described in Section 4.e of
   =
the Trust Legal Provisions and are provided without warranty =
as
   described in the BSD =
License.
 
 
 
 
 
 
 
 
 
 =
;
 
 
 
 
 
 
 
=
 
 
 
 
 
 =

 
 
=
 
 
 =

 
 
&=
nbsp;
 
 
=

 
 
Levis, et =
al.            =
Expires January 7, =
2011           &nb=
sp;    [Page =
2]
 
Internet-Draft &=
nbsp;       =
draft-ietf-roll-trickle-02        =
;      July =
2010
 
 
Table of =
Contents
 
   =
1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . =
. . . 3
   2.  Terminology . . . . . =
. . . . . . . . . . . . . . . . . . . . . =
3
   3.  Trickle Algorithm =
Overview  . . . . . . . . . . . . . . . . . . =
3
   4.  Trickle Algorithm . . . . . =
. . . . . . . . . . . . . . . . . . =
4
     4.1.  Parameters =
and Variables  . . . . . . . . . . . . . . . . . =
4
     4.2.  Algorithm =
Description . . . . . . . . . . . . . . . . . . . =
5
   5.  Using Trickle . . . . . . . =
. . . . . . . . . . . . . . . . . . 5
   =
6.  Operational Considerations  . . . . . . . . . . . . . . . =
. . . 6
     6.1.  =
Mismatched redundancy constants . . . . . . . . . . . . . . =
6
     6.2.  Mismatched =
Imin . . . . . . . . . . . . . . . . . . . . . . =
6
     6.3.  Mismatched =
Imax . . . . . . . . . . . . . . . . . . . . . . =
7
     6.4.  Mismatched =
definitions  . . . . . . . . . . . . . . . . . . =
7
     6.5.  Specifying =
the constant k . . . . . . . . . . . . . . . . . =
7
     6.6.  Relationship =
between k and Imin . . . . . . . . . . . . . . =
7
     6.7.  Tweaks and =
improvements to Trickle  . . . . . . . . . . . . =
8
   7.  Acknowledgements  . . =
. . . . . . . . . . . . . . . . . . . . . =
8
   8.  IANA Considerations . . . . =
. . . . . . . . . . . . . . . . . . 8
   =
9.  Security Considerations . . . . . . . . . . . . . . . . . . . . =
8
   10. References  . . . . . . . . =
. . . . . . . . . . . . . . . . . . =
8
     10.1. Normative =
References  . . . . . . . . . . . . . . . . . . . =
8
     10.2. Informative =
References  . . . . . . . . . . . . . . . . . . =
9
   Authors' Addresses  . . . . . . =
. . . . . . . . . . . . . . . . . . =
9
 
 
 
 
 =

 
 
=
 
 
 =

 
 
&=
nbsp;
 
 
=

 
 
 <=
/o:p>
 
 
<=
o:p> 
 
 <=
/pre>
 
 
&n=
bsp;
 
Levis, et =
al.          =
  Expires January 7, =
2011           &nb=
sp;    [Page =
3]
 
Internet-Draft &=
nbsp;       =
draft-ietf-roll-trickle-02        =
;      July =
2010
 
 
1.  =
Introduction
 
  =
; The Trickle algorithm is designed for wireless networks. =
 
JP> please use the LLN terminology and point to =
[I-D-ietf.roll-terminology] ID.
It
   =
establishes a density-aware local broadcast with an =
underlying
   consistency model that =
guides when a node communicates.  When =
a
   node's data does not =
agree 
JP> you may want to clarify the term =
"agree"
with its neighbors, =
it communicates
   quickly to resolve the =
inconsistency.  
JP> Please define "inconsistency" (an =
example should suffice)
When nodes agree, =
they slow
   their communication rate =
exponentially, such that nodes send at =
most
   a few packets per hour. =
 
JP> See comments on =
"hour"
Instead of flooding =
a network with packets,
   the algorithm =
controls the send rate so each node hears a small
JP> avoid "small", "large", ... it =
is all relative.
   =
trickle of packets, just enough to stay consistent.  Furthermore, =
by
   relying only on local =
broadcasts, 
JP> broadcast or =
multicast
Trickle handles =
network re-
   =
population, 
JP> Define =
"re-population"
is robust to =
network transience, loss, and =
disconnection,
   and requires very =
little state (implementations use 4-11 =
bytes).
 
JP> Mention that current implementations typically =
requires .... 
   While =
Trickle was originally designed for reprogramming =
protocols
   (where the data is the code =
of the program being updated), =
experience
   has shown it to be a =
powerful mechanism that can be applied to =
wide
   range of protocol design =
problems, including control traffic =
timing,
   multicast propagation, and =
route =
discovery.
 
   =
This document describes the Trickle algorithm and provides =
guidelines
   for its use.  It also =
states requirements for protocol =
specifications
   that use Trickle.  =
This document does not provide results =
on
   Trickle's performance or behavior, =
nor does it explain the
   algorithm's =
design in detail: interested readers should refer =
to
   [Levis04] and =
[Levis08].
 
 
2.  =
Terminology
 
  =
 The key words "MUST", "MUST NOT", =
"REQUIRED", "SHALL", "SHALL =
NOT",
   "SHOULD", =
"SHOULD NOT", "RECOMMENDED", "NOT =
RECOMMENDED", "MAY", =
and
   "OPTIONAL" in this =
document are to be interpreted as described in =
RFC
   2119 =
[RFC2119].
 
 
3.  Trickle Algorithm =
Overview
 
   =
Trickle's basic primitive is simple: every so often, a node =
transmits
   code =
metadata 
JP> s/code metadata/information (e.g. routing =
protocol, software updates, ...)
 
if it has not heard =
a few other nodes transmit the same
   =
thing.  
JP> =
s/thing/information
This allows Trickle =
to scale to thousand-fold variations =
in
   network density, quickly propagate =
updates, distribute transmission
   load =
evenly, be robust to transient disconnections, handle =
network
   repopulations, and impose a =
maintenance overhead on the order of a
   =
few packets per hour.
JP> same comment about =
"hour"
   =
Trickle sends all messages to the local broadcast address. =
 
JP> or multicast (to be updated throughout the =
document)
 
There =
are
 
 
 
Levis, et =
al.            =
Expires January 7, =
2011           &nb=
sp;    [Page =
4]
 
Internet-Draft &=
nbsp;       =
draft-ietf-roll-trickle-02        =
;      July =
2010
 
 
   two possible results to a Trickle broadcast: =
either every node that
   hears the =
message is up to date, or a recipient detects the need =
for
   an update.  Detection can be =
the result of either an out-of-date =
node
   hearing someone has new code, or =
an updated node hearing someone has
   =
old code.  
JP> this comes from one application of trickle (code =
update), could you make it
more general (e.g. fresher =
information)
As long as every =
node communicates somehow - either
   =
receives or transmits - the need for an update will be =
detected.
 
   =
For example, consider a simple case where "up to date" is =
defined by
   version numbers (e.g., =
network configuration).  If node A =
broadcasts
   that it has version V, but =
B has version V+1, then B knows that A
   =
needs an update.  Similarly, if B broadcasts that it has =
V+1
JP> s/V+1/version =
V+1
, A =
knows
   that it needs an update.  =
If B broadcasts updates, then all of =
its
   neighbors can receive them without =
having to advertise their need.
   Some =
of these recipients might not even have heard A's =
transmission.
 
 &nbs=
p; In this example, it does not matter who first transmits, A or =
B;
   either case will detect the =
inconsistency.  All that matters is =
that
   some nodes communicate with one =
another at some nonzero rate.  As
   =
long as the network is connected and there is some =
minimum
   communication rate for each =
node, the network will reach eventual
   =
consistency.
 
  =
; The fact that communication can be either transmission or =
reception
   enables =
Trickle 
JP> s/Trickle/the Trickle =
algorithm
to operate in =
sparse as well as dense networks.  =
A
   single, disconnected node must =
transmit at the communication rate.
   In =
a lossless, single-hop network of size n, the sum of =
transmissions
   over the network is the =
communication rate, so for each node it =
is
   1/n.  Sparser networks require =
more transmissions per node, but
   =
utilization of the radio channel over space will not increase.  =
This
   is an important property in =
wireless networks, 
JP> and other shared =
media
where the channel =
is a
   valuable shared resource.  =
Additionally, reducing transmissions =
in
   dense networks conserves system =
energy.
 
 
4.  Trickle =
Algorithm
 
   =
This section describes the Trickle =
algorithm.
 
4.1.  =
Parameters and =
Variables
 
  =
 A Trickle timer has three configuration parameters: the =
minimum
   interval size Imin, the =
maximum interval size Imax, and a =
redundancy
   constant =
k:
 
   o  =
The minimum interval size is defined in units of time =
(e.g.,
      milliseconds, =
seconds).  For example, a protocol might define =
the
      minimum interval =
as 100 =
milliseconds.
 
 =
;
 
 
Levis, et =
al.            =
Expires January 7, =
2011           &nb=
sp;    [Page =
5]
 
Internet-Draft &=
nbsp;       =
draft-ietf-roll-trickle-02        =
;      July =
2010
 
 
   o  The maximum interval size is described as =
a number of doublings =
of
      the minimum =
interval size (the base-2 log(max/min)).  For =
example,
      a protocol =
might define the maximum interval as 16.  If =
the
      minimum interval =
is 100ms, then the maximum interval is 100ms =
*
      65536, 6,553.6 =
seconds, or approximately 109 =
minutes.
 
   =
o  The redundancy constant is a natural number (an integer =
greater
      than =
zero).
JP> Could be equal to infinity (and encoded as 0) =
=3D> no suppression.
   =
In addition to these three parameters, Trickle maintains =
three   variables:    o  I, the current =
interval size    o  t, a time within the current =
interval, and    o  c, a =
counter.
 
4.2.  =
Algorithm =
Description
 
  =
 The Trickle algorithm has five =
rules:
 
   =
1.  When an interval begins, Trickle resets c to 0 and sets t to =
a
       random point =
in the interval, taken from the range [I/2, I).
JP> s/I)/I]
   =
2.  Whenever Trickle hears a transmission that is =
"consistent," =
it
       increments =
counter c.
 
   =
3.  At time t, Trickle transmits if and only if counter c is =
less
       than the =
redundancy constant =
k.
 
   =
4.  When an interval expires, 
JP> this may not be obvious first time you read it. =
interval=3Dt or I (question
was asked on the mailing list in the =
past).
Trickle doubles the =
interval =
length.
       If =
this new interval length would be longer than Imax, =
Trickle
       sets =
the interval length I to be =
Imax.
 
   =
5.  If Trickle hears a transmission that is =
"inconsistent," =
the
       Trickle =
timer resets.  If I is greater than =
Imin, 
JP> how could that happen that I < =
 Imin?
resetting =
a
       Trickle =
timer sets I to Imin and begins a new interval.  If I =
is
       equal to =
Imin, resetting a Trickle timer does nothing.  =
Trickle
       may =
also reset the timer in response to external =
"events."
 
&nbs=
p;  The terms consistent, inconsistent and event are in quotes =
because
   their meaning depends on the =
use of =
Trickle.
 
 
5.  Using =
Trickle
 
   A =
protocol specification that uses Trickle MUST =
specify:
 
 
 
Levis, et =
al.            =
Expires January 7, =
2011           &nb=
sp;    [Page =
6]
 
Internet-Draft &=
nbsp;       =
draft-ietf-roll-trickle-02        =
;      July =
2010
 
 
   o  Default values for Imin, Imax, and k. =
 
JP> s/Default =
values/Value
Because link layers =
can
      vary widely in =
their properties, the default 
JP> remove =
"default"
value of Imin =
should
      be specified =
in terms of the worst-case latency of a link =
layer
      =
transmission.  For example, a specification should say =
"the
      default =
value of Imin is 4 times the worst case link =
layer
      =
latency" 
JP> may be worth how you define =
"latency"
and should not say =
"the default value of Imin is =
500
      =
milliseconds."  Worst case latency is the time until the =
first
      link-layer =
transmission of the frame assuming an idle =
channel
      (does not =
include backoff, virtual carrier sense, =
etc.).
 
   =
o  What constitutes a "consistent" =
transmission.
 
 &nbs=
p; o  What constitutes an "inconsistent" =
transmission.
 
 &nbs=
p; o  What "events," if any, besides inconsistent =
transmissions that
      =
reset the Trickle =
timer.
 
 =

6.  Operational =
Considerations
 
 &nb=
sp; It is RECOMMENDED that a protocol which uses Trickle =
include
   mechanisms to inform nodes of =
configuration parameters at runtime.
   =
However, it is not always possible to do so.  In the cases =
where
   different nodes have different =
configuration parameters, Trickle may
   =
have unintended behaviors.  This section outlines some of =
those
   behaviors and operational =
considerations as educational =
exercises.
 
6.1.  =
Mismatched redundancy =
constants
 
  =
 If nodes do not agree on the redundancy constant k, then nodes =
with
   higher values of k will transmit =
more often than nodes with lower
   =
values of k.  In some cases, this increased load can be =
independent
   of the density.  For =
example, consider a network where all nodes =
but
   one have k=3D1, and this one node =
has k=3D2.  The different node can =
end
   up transmitting on every interval: =
it is maintaining a communication
   rate =
of 2 with only itself.  Hence, the danger of mismatched k =
values
   is uneven transmission load =
that can deplete the energy of some
   =
nodes.
JP> Still this does not lead to interoperability =
issues.
Don't we want to recommend consistent configuration ? If =
you agree, then
these comments should go at the end of this section (or =
beginning) but they
apply to several kind of =
mismatches
 6.2.  Mismatched =
Imin    If nodes do not agree on Imin, then some nodes, =
on hearing   inconsistent messages, will transmit sooner than =
others.  These   faster nodes will have their intervals =
grow to similar size as the   slower nodes within a single =
slow interval time, but in that period   may suppress the =
slower nodes.  However, such suppression will end   after =
the first slow interval, when the nodes generally agree on =
the   interval size.  Hence, mismatched Imin values are =
usually not a Levis, et =
al.            =
Expires January 7, =
2011           &nb=
sp;    [Page 7] 

 Internet-Draft         =
draft-ietf-roll-trickle-02        =
;      July 2010    significant =
concern. 6.3.  Mismatched Imax    If nodes do not =
agree on Imax, then this can cause long-term problems   with =
transmission load.  Nodes with small Imax values will =
transmit   faster, suppressing those with larger Imax =
values.  The nodes with   larger Imax values, always =
suppressed, will never transmit.  In the   base case, =
when the network is consistent, this can cause long-term   =
inequities in energy cost. 6.4.  Mismatched =
definitions    If nodes do not agree on what constitutes =
a consistent or   inconsistent transmission, then Trickle may =
fail to operate properly.   For example, if a receiver thinks =
a transmission is consistent, but   the transmitter (if in the =
receivers situation) would have thought it   inconsistent, =
then the receiver will not respond properly and inform   the =
transmitter.  This can lead the network to not reach a =
consistent   state.  For this reason, unlike the =
configuration constants k, Imin,   and Imax, consistency =
definitions should be clearly stated in the   protocol and =
should not be configured at runtime. 
JP> I would suggest a MUST instead of a should in the =
sentence above.
6.5.  =
Specifying the constant =
k
 
   There =
are some edge cases where a protocol may wish to use =
Trickle
   with its suppression disabled =
(k is set to infinity).  In =
general,
   this approach is highly =
dangerous and it is NOT RECOMMENDED.
JP> I would strongly suggest to soften this statement. =
Just explain the
consequences.
   =
Disabling suppression means that every node will always send on =
every
   interval, and can lead to =
congestion in dense networks.  =
This
   approach is especially =
dangerous 
JP> same comment
if many nodes reset =
their intervals
   at the same =
time.  In general, it is much more desirable to set k =
to
   a high value (e.g., 5 or 10) than =
infinity.  Typical values for k =
are
   1-5: these achieve a good balance =
between redundancy and low =
cost.
 
JP> I would suggest to add refs =
here.
   =
Nevertheless, there are situations where a protocol may wish to =
turn
   off Trickle suppression.  =
Because k is a natural number
   (Section =
4.1), c=3D0 has no useful meaning.  If a protocol allows k =
to
   be dynamically configured, a value =
of 0 remains unused.  For ease of
   =
debugging and packet inspection, having the parameter describe =
(c-1)
JP> c-1 =
?
   can be =
counter-productive.  Instead, it is RECOMMENDED that =
protocols   which require turning off suppression reserve =
c=3D0 to mean c=3Dinfinity. 6.6.  Relationship between k and =
Imin    Finally, a protocol SHOULD set k and Imin such =
that Imin is at least   two to three as long as it takes to =
transmit k packets.  Otherwise,   if more than k nodes =
reset their intervals to Imin, the resulting Levis, et =
al.            =
Expires January 7, =
2011           &nb=
sp;    [Page 8] 

 Internet-Draft         =
draft-ietf-roll-trickle-02        =
;      July 2010    =
communication will lead to congestion and significant packet =
loss.   Experimental results have shown that packet losses =
from congestion   reduce Trickle's efficiency =
[Levis04].
JP> Well ... it is true in most networks, but may not =
be completely applicable to
non wireless networks though. =
You may want to mention it.
 6.7.  Tweaks =
and improvements to Trickle    Trickle is based on a =
small number of simple, tightly integrated   mechanisms that =
are highly robust to challenging network   environments. =
 
 
   =
>>In our experiences using Trickle, attempts to =
tweak
   its behavior are typically not =
worth the cost.  As written, the
   =
algorithm is already highly efficient: further reductions =
in
   transmissions or response time come =
at the cost of failures in edge
   =
cases.  Based on our experiences, we urge protocol designers =
to
   suppress the instinct to tweak or =
improve Trickle without a great
   deal =
of experimental evidence that the change does not violate =
its
   assumptions and break the =
algorithm in edge cases.<<
JP> You may want to soften this =
statement.
   This =
warning in mind, Trickle is far from perfect. =
 
JP> nobody's perfect. Not needed in the =
document.
For =
example,
   Trickle suppression typically =
leads sparser nodes to transmit more
   =
than denser ones; it is far from the optimal computation of a =
minimum
   cover.  However, in =
dynamic network environments such as =
wireless,
   the coordination needed to =
compute the optimal set of =
transmissions
   is typically much =
greater than the benefits it provides.  One of =
the
   benefits of =
Trickle 
JP> s/Trickle/the Trickle =
algorithm
is that it is so =
simple to implement and requires
   so =
little state yet operates so efficiently.  Efforts to improve =
it
   should be weighed against the cost =
of increased =
complexity.
 
 <=
/o:p>
7.  =
Acknowledgements
 
JP> to be done
 =
8.  IANA Considerations    This document has no IANA =
considerations. 9.  Security Considerations    This =
document has no security considerations. 10.  References =
10.1.  Normative References    [RFC2119]  =
Bradner, S., "Key words for use in RFCs to =
Indicate           =
;   Requirement Levels", BCP 14, RFC 2119, March 1997. =
Levis, et =
al.            =
Expires January 7, =
2011           &nb=
sp;    [Page 9] 

 Internet-Draft         =
draft-ietf-roll-trickle-02        =
;      July 2010 10.2.  Informative =
References    [Levis04]  Levis, P., Patel, N., =
Culler, D., and S. =
Shenker,           =
;   "Trickle: A Self-Regulating Algorithm for Code =
Propagation          &n=
bsp;   and Maintenance in Wireless Sensor =
Networks"", =
Proceedings          &n=
bsp;   of the First USENIX/ACM Symposium on Networked =
Systems           =
   Design and Implementation NSDI 2004, March =
2004,           &n=
bsp;  <http://portal.ac=
m.org/citation.cfm?id=3D1251177>.    =
[Levis08]  Levis, P., Brewer, E., Culler, D., Gay, D., Madden, =
S.,           &nbs=
p;  Patel, N., Polastre, J., Shenker, S., Szewczyk, R., and =
A.            =
;  Woo, "The Emergence of a Networking Primitive in =
Wireless           =
;   Sensor Networks", Communications of the ACM, v.51 =
n.7,           &nb=
sp;  July =
2008,           &n=
bsp;  <http://portal.ac=
m.org/citation.cfm?id=3D1364804>. Authors' =
Addresses    Philip Levis   Stanford =
University   358 Gates Hall, Stanford University   =
Stanford, CA  94305   USA    Phone: +1 650 =
725 9064   Email: pal@cs.stanford.edu  &n=
bsp; Thomas Heide Clausen   LIX, Ecole =
Polytechnique    Phone: +33 6 6058 9349   =
Email: T.Clausen@computer.org &n=
bsp;  Jonathan Hui   Arch Rock Corporation   =
501 Snd St., Suite 410   San Francisco, CA  =
94107   USA    Email: jhui@archrock.com Levis, et =
al.            =
Expires January 7, =
2011           &nb=
sp;   [Page 10] 

 Internet-Draft         =
draft-ietf-roll-trickle-02        =
;      July 2010    Omprakash =
Gnawali   Stanford University   S255 Clark Center, =
318 Campus Drive   Stanford, CA  94305   =
USA    Phone: +1 650 725 6086   Email: gnawali@cs.stanford.edu =
   JeongGil Ko   Johns Hopkins =
University   3400 N. Charles St., 224 New Engineering =
Building   Baltimore, MD  21218   =
USA    Phone: +1 410 516 4312   Email: jgko@cs.jhu.edu Levis, et =
al.            =
Expires January 7, =
2011           &nb=
sp;   [Page 11]

 

Thanks.

 

JP.

 

On Jul 28, 2010, at 10:05 AM, JP Vasseur = wrote:



Dear = WG,

 

draft-ietf-roll-trickle-02 is stable and now ready = for WG Last Call.

This starts a 2-week Working Group last call ending on August 11 at = 9:00am ET.

Please send your comments to the authors and the list.

Thanks.

JP.

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

 

 

------=_NextPart_000_0089_01CB32F3.15283770-- From mcr@sandelman.ca Tue Aug 3 10:04:43 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3786F3A6A9E for ; Tue, 3 Aug 2010 10:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.81 X-Spam-Level: X-Spam-Status: No, score=-1.81 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcwHrCkTjkfE for ; Tue, 3 Aug 2010 10:04:42 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id EBD0D3A6A9A for ; Tue, 3 Aug 2010 10:04:40 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id D27B73462C for ; Tue, 3 Aug 2010 13:05:03 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 199F498A68 for ; Tue, 3 Aug 2010 13:05:03 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <20100723164718.775303A69F0@core3.amsl.com> References: <20100723164718.775303A69F0@core3.amsl.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 03 Aug 2010 13:05:03 -0400 Message-ID: <18937.1280855103@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] IPR Disclosure: Certicom Corp.'s Statement of IPR claimed in draft-ietf-roll-rpl-10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 17:04:43 -0000 > 3. Any public keys utilized in an implementation of ECPVS according to > this IETF specification are extracted from a certificate issued from a > Certicom-licensed Certificate Authority ("CA"); and This completely invalidates the RF RAND of part 1. No open source implementation could "guarantee" this. I'm very happy we have RSA keys. -- ] 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 samitac@ipinfusion.com Tue Aug 3 12:06:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33F003A6AE8 for ; Tue, 3 Aug 2010 12:06:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IliQ+SJvYPQS for ; Tue, 3 Aug 2010 12:06:46 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 6F89A3A6AD9 for ; Tue, 3 Aug 2010 12:06:46 -0700 (PDT) Received: (qmail 89571 invoked from network); 3 Aug 2010 19:07:12 -0000 Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 03 Aug 2010 12:07:12 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: dR7OV6AVM1lRNyPOqVEQfpA30ZoWZ4agKRoJ9vjFfAmxPV3 Lb0Z49vu1UO6gVYmVLkSA0ygGunslA5uEn66NwFvM8fvjAamKi04Sg3MK3FF nl9xakewLBmizJYF8ftAAsGi7kWVTQ8zTFZuskGstrePJbIgc.zowBKzPSYl xoVze8Z0FhtLwgVnrwmmYxQVm87tjBcD9X7MBuN.7BSlMAeZqySBfHdA8BQk 51ZG.I4hcX7pvuOorjMaV0QILzR1QIkLPSca1PqneHzys6VrS6gWlKIEiA7v v X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: , References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <4C56F61E.1020808@eecs.berkeley.edu> <8E09C72DBC577D489F13A71228C0B7BF017977C0@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF017977C0@ftrdmel0.rd.francetelecom.fr> Date: Tue, 3 Aug 2010 12:07:12 -0700 Message-ID: <009d01cb333f$142f6e00$3c8e4a00$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 thread-index: AcsyYkbcyo56YH8sSzqtWl9H7BDCZQAIGkHwAC8SDyA= Content-Language: en-us Subject: Re: [Roll] Status change on Trickle I-D (was: Draft ROLLWG minutesposted) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 19:06:48 -0000 +1 -Samita > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf = Of > dominique.barthel@orange-ftgroup.com > Sent: Monday, August 02, 2010 1:41 PM > To: roll@ietf.org > Subject: Re: [Roll] Status change on Trickle I-D (was: Draft ROLLWG > minutesposted) >=20 > Moving Trickle to Std Track seems the most sensible move to me. > Trickle seems to be applicable to a wide sprectrum of protocols, = therefore > is likely to be referenced as Normative in several future Std Track > documents. >=20 > Dominique >=20 > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part = de Kris > Pister Envoy=E9 : lundi 2 ao=FBt 2010 18:45 =C0 : Pascal Thubert = (pthubert) Cc : > roll@ietf.org Objet : Re: [Roll] Status change on Trickle I-D (was: = Draft > ROLLWG minutesposted) >=20 > I agree that trickle should move to standards track. >=20 > ksjp >=20 > Pascal Thubert (pthubert) wrote: > > Alex: > > > > We need to be very clear that the WG is chartered for Standard = Track, > > not Informational. So RPL is and will stay on that track. > > Moving Trickle to standard track is a good move, highly deserved for = a > > method that's well understood and proven, and I support it 100%. > > > > Safe trip back, > > > > Pascal > > > > > >> -----Original Message----- > >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On = Behalf > >> > > Of > > > >> Alexandru Petrescu > >> Sent: Friday, July 30, 2010 8:19 AM > >> To: roll@ietf.org > >> Subject: [Roll] Status change on Trickle I-D (was: Draft ROLL WG > >> minutesposted) > >> > >> > >>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02 (Phil - = 5mn) > >>> [160] Quick update on the changes in -02. Currently in LC. > >>> > >>> JP> ID is a normative reference in RPL core spec (thus we have a > >>> downref). Discussion on ID status JP> Will come back to the list = to > >>> consider status change (informational to standard track) > >>> > >> Just a quick note to consider more ways to solve this problem (RPL > >> > > spec > > > >> 'downref'erencing a draft it fully relies on): > >> > >> -move draft-ietf-roll-trickle in the Informative References = section. > >> This implies making Trickle parameters less mandatory in RPL. > >> -change the track of the base spec to Informational (this implies > >> > > change to > > > >> communication to SDO requiring this RP, I suppose). > >> > >> Also worth mentioning the use of BCP tag on the Trickle draft... > >> > > Trickle being > > > >> common practice in widespread use yet not really a protocol (timer > >> management). > >> > >> These may have already been considered, > >> > >> Alex > >> _______________________________________________ > >> Roll mailing list > >> Roll@ietf.org > >> https://www.ietf.org/mailman/listinfo/roll > >> > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From wintert@acm.org Tue Aug 3 12:21:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922E23A6ACF for ; Tue, 3 Aug 2010 12:21:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.066 X-Spam-Level: X-Spam-Status: No, score=-102.066 tagged_above=-999 required=5 tests=[AWL=0.533, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id trZOvE7oauAw for ; Tue, 3 Aug 2010 12:21:34 -0700 (PDT) Received: from smtp101.prem.mail.ac4.yahoo.com (smtp101.prem.mail.ac4.yahoo.com [76.13.13.40]) by core3.amsl.com (Postfix) with SMTP id 8E9D63A6AB9 for ; Tue, 3 Aug 2010 12:21:34 -0700 (PDT) Received: (qmail 68829 invoked from network); 3 Aug 2010 19:21:57 -0000 Received: from [10.56.17.107] (wintert@71.178.253.216 with plain) by smtp101.prem.mail.ac4.yahoo.com with SMTP; 03 Aug 2010 12:21:57 -0700 PDT X-Yahoo-SMTP: 30iEHGKswBCbca_Y5pX7d6RVQMoT5Mk- X-YMail-OSG: .H5T4_4VM1n15ud8hk8S5ihAsJu1JCukuEr4jGfOqmIv6rA 5neIgW16xYOcyVTHxAKQXhgRTapYG8ZxoHidoFshTL0_ClpIjNOQKtn9BZy0 dt5gJ7Xx.uPrJ1GdvsutKRn5kbUPAyAKR.DC_GWncJK0z7T92wa41ZT7PVVw nAIM5UM8EoTzGJopJ57S2ICQbGIVmJBF7wKraQ2cUFKUEFDhW5NiaOSlxS93 A3QH0ZpwschxnXBEXjbO.yEcGHDqli_2eWfnXHDz.7LlTsCM.kyptPI_lSTC 5lbeXRbLp2ODJdKs3qRu6mdNzAZaDRCFas6.FDPogHiYgnLYZI.18 X-Yahoo-Newman-Property: ymail-3 Message-ID: <4C586C52.6000303@acm.org> Date: Tue, 03 Aug 2010 15:21:54 -0400 From: Tim Winter User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100713 Thunderbird/3.0.6 MIME-Version: 1.0 To: roll@ietf.org References: <6A2A459175DABE4BB11DE2026AA50A5D02727905@XMB-AMS-107.cisco.com> <4C56F61E.1020808@eecs.berkeley.edu> <8E09C72DBC577D489F13A71228C0B7BF017977C0@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <8E09C72DBC577D489F13A71228C0B7BF017977C0@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] Status change on Trickle I-D (was: Draft ROLLWG minutesposted) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 19:21:35 -0000 I agree with Dominique. -Tim On 08/02/2010 04:40 PM, dominique.barthel@orange-ftgroup.com wrote: > Moving Trickle to Std Track seems the most sensible move to me. > Trickle seems to be applicable to a wide sprectrum of protocols, therefore is likely to be referenced as Normative in several future Std Track documents. > > Dominique > > -----Message d'origine----- > De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de Kris Pister > Envoyé : lundi 2 août 2010 18:45 > À : Pascal Thubert (pthubert) > Cc : roll@ietf.org > Objet : Re: [Roll] Status change on Trickle I-D (was: Draft ROLLWG minutesposted) > > I agree that trickle should move to standards track. > > ksjp > > Pascal Thubert (pthubert) wrote: >> Alex: >> >> We need to be very clear that the WG is chartered for Standard Track, >> not Informational. So RPL is and will stay on that track. >> Moving Trickle to standard track is a good move, highly deserved for a >> method that's well understood and proven, and I support it 100%. >> >> Safe trip back, >> >> Pascal >> >> >>> -----Original Message----- >>> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >>> >> Of >> >>> Alexandru Petrescu >>> Sent: Friday, July 30, 2010 8:19 AM >>> To: roll@ietf.org >>> Subject: [Roll] Status change on Trickle I-D (was: Draft ROLL WG >>> minutesposted) >>> >>> >>>> 5) The Trickle Algorithm - draft-levis-roll-trickle-02 (Phil - 5mn) >>>> [160] Quick update on the changes in -02. Currently in LC. >>>> >>>> JP> ID is a normative reference in RPL core spec (thus we have a >>>> downref). Discussion on ID status JP> Will come back to the list to >>>> consider status change (informational to standard track) >>>> >>> Just a quick note to consider more ways to solve this problem (RPL >>> >> spec >> >>> 'downref'erencing a draft it fully relies on): >>> >>> -move draft-ietf-roll-trickle in the Informative References section. >>> This implies making Trickle parameters less mandatory in RPL. >>> -change the track of the base spec to Informational (this implies >>> >> change to >> >>> communication to SDO requiring this RP, I suppose). >>> >>> Also worth mentioning the use of BCP tag on the Trickle draft... >>> >> Trickle being >> >>> common practice in widespread use yet not really a protocol (timer >>> management). >>> >>> These may have already been considered, >>> >>> Alex >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pal@cs.stanford.edu Tue Aug 3 15:33:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12AE33A6869 for ; Tue, 3 Aug 2010 15:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gc7UEVfRZ-sk for ; Tue, 3 Aug 2010 15:33:47 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 303DA3A6816 for ; Tue, 3 Aug 2010 15:33:47 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OgQ3p-0005Ve-6o; Tue, 03 Aug 2010 15:34:15 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <3895b8f23b1fa4216210be0d92c8d064@mail.gmail.com> Date: Tue, 3 Aug 2010 15:34:12 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C57317E.3070900@gmail.com> <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> bc58199e3b35de85c3e16aec79b13992@mail.gmail.com <3895b8f23b1fa4216210be0d92c8d064@mail.gmail.com> To: Yoav Ben-Yehezkel X-Mailer: Apple Mail (2.1081) X-Scan-Signature: b65b8f26ca423de213f14dca1c6ea011 Cc: ROLL WG Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 22:33:48 -0000 On Aug 2, 2010, at 10:40 PM, Yoav Ben-Yehezkel wrote: > One more thing - >=20 > Maybe in your description you should consider also saying that trickle = can > also be used by link layers when the destination is broadcast or > multicast. As you've noted trickle is a mechanism that doesn't really = have > to be bound to RPL nor to IP. >=20 > What do you think? I agree 100%. The point is that it's to a set of nearby nodes: how this = manifests in terms of addressing greatly depends on what the underlying = technologies are. I'll work on some text to try to communicate this = fact. Phil= From richard.kelsey@ember.com Tue Aug 3 16:33:40 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 543C43A6B6B for ; Tue, 3 Aug 2010 16:33:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-1.145, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h-8SFpVoFR9J for ; Tue, 3 Aug 2010 16:33:39 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id CB74F3A6B61 for ; Tue, 3 Aug 2010 16:33:11 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 3 Aug 2010 19:32:54 -0400 Date: Tue, 03 Aug 2010 19:33:22 -0400 Message-Id: <874ofbff0d.fsf@kelsey-ws.hq.ember.com> To: roll@ietf.org From: Richard Kelsey X-OriginalArrivalTime: 03 Aug 2010 23:32:55.0161 (UTC) FILETIME=[32C37E90:01CB3364] Subject: [Roll] RPL hop-by-hop and source route X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 23:33:40 -0000 A question came up in the planning for the next ZigBeeIP interop. If a packet has a source route, must it also have a RPL hop-by-hop option? What purpose would the hop-by-hop option serve? -Richard Kelsey From pal@cs.stanford.edu Tue Aug 3 16:47:18 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD6D3A6B5A for ; Tue, 3 Aug 2010 16:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.289 X-Spam-Level: X-Spam-Status: No, score=-6.289 tagged_above=-999 required=5 tests=[AWL=0.310, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mmB64ZuyvqhW for ; Tue, 3 Aug 2010 16:47:15 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 3BE473A6B57 for ; Tue, 3 Aug 2010 16:47:13 -0700 (PDT) Received: from c-67-164-98-139.hsd1.ca.comcast.net ([67.164.98.139] helo=[192.168.19.50]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OgRCu-0001Kg-24; Tue, 03 Aug 2010 16:47:43 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <874ofbff0d.fsf@kelsey-ws.hq.ember.com> Date: Tue, 3 Aug 2010 16:47:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <874ofbff0d.fsf@kelsey-ws.hq.ember.com> To: Richard Kelsey X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3 Cc: roll@ietf.org Subject: Re: [Roll] RPL hop-by-hop and source route X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Aug 2010 23:47:19 -0000 On Aug 3, 2010, at 4:33 PM, Richard Kelsey wrote: > A question came up in the planning for the next ZigBeeIP > interop. If a packet has a source route, must it also have > a RPL hop-by-hop option? What purpose would the hop-by-hop > option serve? Good question. My 2 cents: I don't think there's a purpose to having Rank in the hop-by-hop header. There may be a purpose to having the RPLInstanceID, though. E.g., if the = source routed packet results in an ICMP error, which RPLInstance should = the ICMP error use? It would be a bit weird if an error in RPL instance = X resulted in an ICMP error from RPL instance Y. Phil= From mcr@sandelman.ca Tue Aug 3 19:04:51 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64F6F3A6A1D; Tue, 3 Aug 2010 19:04:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.54 X-Spam-Level: X-Spam-Status: No, score=-1.54 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KCL-nR8U2lp8; Tue, 3 Aug 2010 19:04:50 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 148853A6A11; Tue, 3 Aug 2010 19:04:49 -0700 (PDT) Received: from marajade.sandelman.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id 355773470B; Tue, 3 Aug 2010 22:05:18 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id B26CA98A68; Tue, 3 Aug 2010 22:05:15 -0400 (EDT) From: Michael Richardson To: roll@ietf.org, Carsten Bormann In-Reply-To: <80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> References: <4C50463E.7070107@tut.fi> <6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com> <14567.1280409076@marajade.sandelman.ca> <80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 03 Aug 2010 22:05:15 -0400 Message-ID: <11162.1280887515@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: ipv6@ietf.org Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 02:04:51 -0000 {there is a thread which started on roll@ietf.org, and ipv6@ietf.org, and then seemed to have dropped roll@ietf.org. I'm not on ipv6@ietf.org, so there likely are message there I've missed} okay, so I've read Carsen's opinion. I read RFC 3697 (which I didn't know about). draft-hu-flow-label-cases-00 is a very good read. I pull out something from section 4 (Discussion); The other choice, for designers who wish to use the flow label to control switching or QoS directly, is to bypass the rules within a given domain (a set of cooperating nodes) in a way that nodes outside the domain cannot detect. In this case, any deviation from [RFC3697] has no possible effect outside the domain in question. I don't know where this subject line is from: 12 bits/8bits. Is there a draft that explains that idea that I've missed? My claim is that ROLL's RPL is a set of cooperating nodes. But, it's better than that --- it's a set of routers which are tuned to support specific applications, and the applications want in this case to be given information like, "what flow label" to use. RPL's RPLinstanceID has all the properties required of a flow label (or, rather, it has no requirements presently, and therefore can have the flow label requirements imposed upon it, specifically: 2. "Nodes MUST NOT assume any mathematical or other properties of the Flow Label" ) The non-mutability of the label isn't a problem either --- the applications *AT EACH END*, even if one end of the application is several AS's away (a very unusual case for 95% of RPL's target use), that application still needs to know something about what label to use. There are three cases to consider: a) traffic between two RPL nodes b) traffic exiting an RPL c) traffic entering an RPL case (a) -- is the "set of cooperating nodes", and therefore is no problem. case (b) -- the flow label is set to get through the RPL/LLN, and out to the network, and the flow label has done it's job, and the RPL/LLN network could care less what happens to the flow label at that point. The rest of the network might have a problem (i.e. a bug) when RPL networks start sending non-zero flow labels, but that's the rest of the network's problem. case (c) - flow labels of zero are not a problem. There is either a default RPLinstanceID to use (and traffic flows, perhaps not optimally), or there isn't (and ICMP Host unreachable occurs). - non-zero flow labels which do not map to an RPLinstanceID, are simply considered zero, see above. - non-zero flow labels which map to RPLinstanceIDs are used. *If* it is a problem for outsiders to invoke that LLN's DODAG, then there are bigger issues, which the flow label can neither help nor hinder --- the flowlabel is not a magic security cookie. A firewall may still be required. The only real problem I can see is when a packet needs to do (b) and (c). e.g. use label A to exit LLN alpha, and label B to enter LLN beta. I don't have a solution to this. Some have suggested IPIP tunnels, which sound nice in theory, but in practice do not work in the wilderness found behind the walls of walled gardens. -- ] 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 richard.kelsey@ember.com Wed Aug 4 07:41:42 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF4843A6848 for ; Wed, 4 Aug 2010 07:41:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.28 X-Spam-Level: X-Spam-Status: No, score=-2.28 tagged_above=-999 required=5 tests=[AWL=0.319, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEgiyDTCIvXj for ; Wed, 4 Aug 2010 07:41:40 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 5A5E83A685E for ; Wed, 4 Aug 2010 07:41:40 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 4 Aug 2010 10:42:08 -0400 Date: Wed, 04 Aug 2010 10:42:34 -0400 Message-Id: <87ocdicucl.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: (message from Philip Levis on Tue, 3 Aug 2010 16:47:24 -0700) From: Richard Kelsey References: <874ofbff0d.fsf@kelsey-ws.hq.ember.com> X-OriginalArrivalTime: 04 Aug 2010 14:42:08.0936 (UTC) FILETIME=[3758F280:01CB33E3] Cc: roll@ietf.org Subject: Re: [Roll] RPL hop-by-hop and source route X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 14:41:42 -0000 > From: Philip Levis > Date: Tue, 3 Aug 2010 16:47:24 -0700 > On Aug 3, 2010, at 4:33 PM, Richard Kelsey wrote: > > > A question came up in the planning for the next ZigBeeIP > > interop. If a packet has a source route, must it also have > > a RPL hop-by-hop option? What purpose would the hop-by-hop > > option serve? > > Good question. My 2 cents: > > I don't think there's a purpose to having Rank in the > hop-by-hop header. > > There may be a purpose to having the RPLInstanceID, > though. E.g., if the source routed packet results in an > ICMP error, which RPLInstance should the ICMP error use? > It would be a bit weird if an error in RPL instance X > resulted in an ICMP error from RPL instance Y. RPL doesn't require that RPLInstances provide two-way routing, so ICMP errors may need to use some other instance whether or not there is a source route in the packet. -Richard From pal@cs.stanford.edu Wed Aug 4 08:13:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60A963A6B8F for ; Wed, 4 Aug 2010 08:13:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DQsbJsXjT5s for ; Wed, 4 Aug 2010 08:13:22 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id AFE643A6B91 for ; Wed, 4 Aug 2010 08:13:22 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OgffD-0003Jq-0i; Wed, 04 Aug 2010 08:13:52 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <87ocdicucl.fsf@kelsey-ws.hq.ember.com> Date: Wed, 4 Aug 2010 08:13:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7530319E-679C-48A0-9B5A-90AA69961BD1@cs.stanford.edu> References: <874ofbff0d.fsf@kelsey-ws.hq.ember.com> <87ocdicucl.fsf@kelsey-ws.hq.ember.com> To: Richard Kelsey X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 6214ac49f2cb083a0c8190805312a710 Cc: roll@ietf.org Subject: Re: [Roll] RPL hop-by-hop and source route X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 15:13:24 -0000 On Aug 4, 2010, at 7:42 AM, Richard Kelsey wrote: >> From: Philip Levis >> Date: Tue, 3 Aug 2010 16:47:24 -0700 >=20 >> On Aug 3, 2010, at 4:33 PM, Richard Kelsey wrote: >>=20 >>> A question came up in the planning for the next ZigBeeIP >>> interop. If a packet has a source route, must it also have >>> a RPL hop-by-hop option? What purpose would the hop-by-hop >>> option serve? >>=20 >> Good question. My 2 cents: >>=20 >> I don't think there's a purpose to having Rank in the >> hop-by-hop header. >>=20 >> There may be a purpose to having the RPLInstanceID, >> though. E.g., if the source routed packet results in an >> ICMP error, which RPLInstance should the ICMP error use? >> It would be a bit weird if an error in RPL instance X >> resulted in an ICMP error from RPL instance Y. >=20 > RPL doesn't require that RPLInstances provide two-way > routing, so ICMP errors may need to use some other > instance whether or not there is a source route in the > packet. > -Richard All RPLInstances provide upward routes; not all instances provide = downward routes. A source routing header is used for downward routes. = So... or are you thinking about the current proposal for lower stretch = P2P communication? The intent of my reply was *not* to say that there MUST be a hop-by-hop = header when there's a source routed packet. It was to answer the = question "What purpose would the hop-by-hop option serve?" To answer was = "To ensure that a resulting ICMP error uses the same RPLInstance when = possible." It's an open questions whether this is important. Phil From ulrich@herberg.name Wed Aug 4 10:03:48 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83BE73A68F9 for ; Wed, 4 Aug 2010 10:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.149 X-Spam-Level: X-Spam-Status: No, score=-1.149 tagged_above=-999 required=5 tests=[AWL=0.827, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsUKxNSjvFrA for ; Wed, 4 Aug 2010 10:03:47 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 74B9F3A68B8 for ; Wed, 4 Aug 2010 10:03:47 -0700 (PDT) Received: by eyb7 with SMTP id 7so2318224eyb.31 for ; Wed, 04 Aug 2010 10:04:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.37.8 with SMTP id v8mr2236032ebd.1.1280941456215; Wed, 04 Aug 2010 10:04:16 -0700 (PDT) Received: by 10.213.37.69 with HTTP; Wed, 4 Aug 2010 10:04:16 -0700 (PDT) In-Reply-To: <18937.1280855103@marajade.sandelman.ca> References: <20100723164718.775303A69F0@core3.amsl.com> <18937.1280855103@marajade.sandelman.ca> Date: Wed, 4 Aug 2010 19:04:16 +0200 Message-ID: From: Ulrich Herberg To: Michael Richardson Content-Type: multipart/alternative; boundary=001485318cbb79ce3d048d026c1f Cc: roll@ietf.org Subject: Re: [Roll] IPR Disclosure: Certicom Corp.'s Statement of IPR claimed in draft-ietf-roll-rpl-10 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 17:03:48 -0000 --001485318cbb79ce3d048d026c1f Content-Type: text/plain; charset=ISO-8859-1 On Tue, Aug 3, 2010 at 7:05 PM, Michael Richardson wrote: > > > 3. Any public keys utilized in an implementation of ECPVS according to > > this IETF specification are extracted from a certificate issued from a > > Certicom-licensed Certificate Authority ("CA"); and > > This completely invalidates the RF RAND of part 1. > I agree that this completely invalidates the use of that algorithm. > No open source implementation could "guarantee" this. > > I'm very happy we have RSA keys. > Or any other non-encumbered algorithm. Ulrich --001485318cbb79ce3d048d026c1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Aug 3, 2010 at 7:05 PM, Michael = Richardson <mcr@sa= ndelman.ca> wrote:

> 3. Any public keys utilized in an implementation of ECPVS according to=
> this IETF specification are extracted from a certificate issued from a=
> Certicom-licensed Certificate Authority ("CA"); and

This completely invalidates the RF RAND of part 1.
I agree that this completely invalidates the use of that algorithm.
=A0=
No open source implementation could "guarantee" this.

I'm very happy we have RSA keys.

Or any other = non-encumbered algorithm.

Ulrich
--001485318cbb79ce3d048d026c1f-- From ulrich@herberg.name Wed Aug 4 10:08:26 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3FCE43A6980 for ; Wed, 4 Aug 2010 10:08:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.18 X-Spam-Level: X-Spam-Status: No, score=-1.18 tagged_above=-999 required=5 tests=[AWL=0.796, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zLf7O1dWMwat for ; Wed, 4 Aug 2010 10:08:25 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 1875428C0EA for ; Wed, 4 Aug 2010 10:08:24 -0700 (PDT) Received: by eyb7 with SMTP id 7so2320575eyb.31 for ; Wed, 04 Aug 2010 10:08:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.213.25.130 with SMTP id z2mr2260404ebb.55.1280941734223; Wed, 04 Aug 2010 10:08:54 -0700 (PDT) Received: by 10.213.37.69 with HTTP; Wed, 4 Aug 2010 10:08:54 -0700 (PDT) In-Reply-To: <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> References: <4C57317E.3070900@gmail.com> <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> Date: Wed, 4 Aug 2010 19:08:54 +0200 Message-ID: From: Ulrich Herberg To: Philip Levis Content-Type: multipart/alternative; boundary=0015174beaa40be203048d027d3a Cc: ROLL WG Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 17:08:26 -0000 --0015174beaa40be203048d027d3a Content-Type: text/plain; charset=ISO-8859-1 Phil, On Tue, Aug 3, 2010 at 1:01 AM, Philip Levis wrote: > > On Aug 2, 2010, at 2:15 PM, Yoav Ben-Yehezkel wrote: > > > Hi, > > > > I'd like to support and add to Alex's note on link local broadcast (that > > appears in many places in the trickle draft). > > > > To emphasize the problem with this, in RPL trickle timer messages are > sent > > to All-RPL-Nodes multicast group, which is not a broadcast. > > > > I suggest to clarify this issue. > > This text came from descriptions where Trickle ran directly on top of a > link layer: hence broadcast rather than multicast. > > I agree that "broadcast" is the wrong term to use. I don't think > All-RPL-Nodes multicast group is the right answer, though: we don't want to > bind Trickle to RPL. I can add some descriptive text on what the destination > address should be. In short, it should be a suitable address for the set of > link-local nodes that care about the message. This could be the > All-RPL-Nodes address, the link local multicast address, a broadcast address > (e.g., for IPv4), etc. Do you agree? > That sounds reasonable. Would all nodes in the network have to agree (i.e. by preconfiguration) on the same multicast address? I guess so... Ulrich --0015174beaa40be203048d027d3a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Phil,

On Tue, Aug 3, 2010 at 1:01 AM, Phi= lip Levis <pal@= cs.stanford.edu> wrote:

On Aug 2, 2010, at 2:15 PM, Yoav Ben-Yehezkel wrote:

> Hi,
>
> I'd like to support and add to Alex's note on link local broad= cast (that
> appears in many places in the trickle draft).
>
> To emphasize the problem with this, in RPL trickle timer messages are = sent
> to All-RPL-Nodes multicast group, which is not a broadcast.
>
> I suggest to clarify this issue.

This text came from descriptions where Trickle ran directly on top of= a link layer: hence broadcast rather than multicast.

I agree that "broadcast" is the wrong term to use. I don't th= ink All-RPL-Nodes multicast group is the right answer, though: we don't= want to bind Trickle to RPL. I can add some descriptive text on what the d= estination address should be. In short, it should be a suitable address for= the set of link-local nodes that care about the message. This could be the= All-RPL-Nodes address, the link local multicast address, a broadcast addre= ss (e.g., for IPv4), etc. Do you agree?

That sounds reasonable. Would all nodes in the networ= k have to agree (i.e. by preconfiguration) on the same multicast address? I= guess so...

Ulrich
--0015174beaa40be203048d027d3a-- From alexandru.petrescu@gmail.com Wed Aug 4 12:37:42 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 050FC3A68B2 for ; Wed, 4 Aug 2010 12:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.603 X-Spam-Level: X-Spam-Status: No, score=-1.603 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tvAZT4eqWlr5 for ; Wed, 4 Aug 2010 12:37:41 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id B27873A67D3 for ; Wed, 4 Aug 2010 12:37:39 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 8CCB1940113 for ; Wed, 4 Aug 2010 21:38:03 +0200 (CEST) Message-ID: <4C59C196.7020303@gmail.com> Date: Wed, 04 Aug 2010 21:37:58 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: roll@ietf.org References: <4C57317E.3070900@gmail.com> <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> bc58199e3b35de85c3e16aec79b13992@mail.gmail.com <3895b8f23b1fa4216210be0d92c8d064@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100804-1, 04/08/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 19:37:42 -0000 Le 04/08/2010 00:34, Philip Levis a écrit : > > On Aug 2, 2010, at 10:40 PM, Yoav Ben-Yehezkel wrote: > >> One more thing - >> >> Maybe in your description you should consider also saying that >> trickle can also be used by link layers when the destination is >> broadcast or multicast. As you've noted trickle is a mechanism that >> doesn't really have to be bound to RPL nor to IP. >> >> What do you think? > > I agree 100%. The point is that it's to a set of nearby nodes: One would like to make sure _all_ nearby nodes that author needs to receive the Trickle message _will_ receive, otherwise I guess Trickle will fail to maintain consistency, no? (draft Trickle says: > 5. If Trickle hears a transmission that is "inconsistent," the > Trickle timer resets. what if a Trickle nodes does not hear a transmission which it would otherwise qualify as inconsistent.) ("near" is also a hard to define term when we talk IP). Phil said: > how this manifests in terms of addressing greatly depends on what the > underlying technologies are. I'll work on some text to try to > communicate this fact. Phil - just to continue on this discussion. Currently IPv6 isn't specified to run on anything which does not support link layer multicast. (exceptions are point-to-point links such as ppp and or IP-IP or GRE or other IP tunnel interfaces, where the addressing model is very simple: only two points are hearing each other.) IPv6 went to a great deal of effort to specify how the link layer addressing (MAC and such) converts to IPv6 link-local addresses: mapping functions of rfc2464, rfc4191, and more. These cases can be enumerated and implemented, not left to unspecified cases. Trickle not being a protocol, it is supposed to use one. If that protocol is IPv6 (e.g. ND, RPL, DHCP) then it won't work on something not using link layer multicast. Trickle running on something else than IP (i.e. Trickle on top of MAC messages of IEEE.x) is yet another question. It is possible that Trickle-straight-over-MAC may work without link-layer multicast. But not using IP one may wonder about specifying Trickle StdsTrack, or at IETF alltogether. Trickle over the adaptation layer mentioned in 6LoWPAN is probably such an underlying technology one thinks of running Trickle on. 802.15.4 high data rate does use link-layer multicast. IPv4 is indeed another question. Just some thoughts, biased of course :-) Alex > > Phil _______________________________________________ Roll mailing > list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From pal@cs.stanford.edu Wed Aug 4 15:19:46 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F2AD3A68DD for ; Wed, 4 Aug 2010 15:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=0.236, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s-Oa4kfeN-Mi for ; Wed, 4 Aug 2010 15:19:45 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id DA1733A689F for ; Wed, 4 Aug 2010 15:19:44 -0700 (PDT) Received: from dn0a208a13.sunet ([10.32.138.19]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OgmJq-00061u-EN; Wed, 04 Aug 2010 15:20:14 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: <4C59C196.7020303@gmail.com> Date: Wed, 4 Aug 2010 15:20:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C57317E.3070900@gmail.com> <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> bc58199e3b35de85c3e16aec79b13992@mail.gmail.com <3895b8f23b1fa4216210be0d92c8d064@mail.gmail.com> <4C59C196.7020303@gmail.com> To: Alexandru Petrescu X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 0858a923cc4ba3562bb802375c61c59b Cc: roll@ietf.org Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Aug 2010 22:19:46 -0000 On Aug 4, 2010, at 12:37 PM, Alexandru Petrescu wrote: > Le 04/08/2010 00:34, Philip Levis a =E9crit : >>=20 >> On Aug 2, 2010, at 10:40 PM, Yoav Ben-Yehezkel wrote: >>=20 >>> One more thing - >>>=20 >>> Maybe in your description you should consider also saying that >>> trickle can also be used by link layers when the destination is >>> broadcast or multicast. As you've noted trickle is a mechanism that >>> doesn't really have to be bound to RPL nor to IP. >>>=20 >>> What do you think? >>=20 >> I agree 100%. The point is that it's to a set of nearby nodes: >=20 > One would like to make sure _all_ nearby nodes that author needs to > receive the Trickle message _will_ receive, otherwise I guess Trickle > will fail to maintain consistency, no? Sort of. You won't reach consistency in a disconnected neighbor, but the = reliable delivery of individual messages is not that critical. This is = an important consideration, given the lossy nature of wireless. >=20 > (draft Trickle says: >> 5. If Trickle hears a transmission that is "inconsistent," the >> Trickle timer resets. > what if a Trickle nodes does not hear a transmission which it would > otherwise qualify as inconsistent.) >=20 > ("near" is also a hard to define term when we talk IP). >=20 > Phil said: >> how this manifests in terms of addressing greatly depends on what the >> underlying technologies are. I'll work on some text to try to >> communicate this fact. >=20 > Phil - just to continue on this discussion. >=20 > Currently IPv6 isn't specified to run on anything which does not = support > link layer multicast. (exceptions are point-to-point links such as = ppp > and or IP-IP or GRE or other IP tunnel interfaces, where the = addressing > model is very simple: only two points are hearing each other.) >=20 > IPv6 went to a great deal of effort to specify how the link layer > addressing (MAC and such) converts to IPv6 link-local addresses: = mapping > functions of rfc2464, rfc4191, and more. These cases can be = enumerated > and implemented, not left to unspecified cases. >=20 > Trickle not being a protocol, it is supposed to use one. If that > protocol is IPv6 (e.g. ND, RPL, DHCP) then it won't work on something > not using link layer multicast. >=20 > Trickle running on something else than IP (i.e. Trickle on top of MAC > messages of IEEE.x) is yet another question. It is possible that > Trickle-straight-over-MAC may work without link-layer multicast. But > not using IP one may wonder about specifying Trickle StdsTrack, or at > IETF alltogether. >=20 > Trickle over the adaptation layer mentioned in 6LoWPAN is probably = such > an underlying technology one thinks of running Trickle on. 802.15.4 > high data rate does use link-layer multicast. >=20 > IPv4 is indeed another question. >=20 > Just some thoughts, biased of course :-) Given that this is the IETF, I think the right thing is to make sure the = text is in that content. E.g., link-layer broadcast isn't important to = cover. What makes this wording a little complex is the All-RPL-Nodes = multicast address. Phil= From pal@cs.stanford.edu Wed Aug 4 19:09:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37B733A699A for ; Wed, 4 Aug 2010 19:09:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBJMCoIGUNMx for ; Wed, 4 Aug 2010 19:09:02 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 593323A6839 for ; Wed, 4 Aug 2010 19:09:02 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Ogptj-0000d5-Of; Wed, 04 Aug 2010 19:09:31 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Wed, 4 Aug 2010 17:22:05 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <75AAB6AE-B4ED-435E-9F37-5135356165D4@cs.stanford.edu> References: <4C57317E.3070900@gmail.com> <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> To: Ulrich Herberg X-Mailer: Apple Mail (2.1081) X-Scan-Signature: a1ccd6d2fa83ef575f7b7817ead66a1e Cc: ROLL WG Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 02:09:03 -0000 On Aug 4, 2010, at 10:08 AM, Ulrich Herberg wrote: >=20 > That sounds reasonable. Would all nodes in the network have to agree = (i.e. by preconfiguration) on the same multicast address? I guess so... Hm -- I actually think it would be specified by the protocol using = Trickle. E.g., some protocols might just use the link-local multicast = address, while RPL, say, uses the All-RPL-Nodes local multicast address. = It's not inconceivable that a protocol allows this address to be = configured, but my feeling is that such a statement belongs outside this = particular draft. Does that make sense? Phil From pal@cs.stanford.edu Wed Aug 4 19:21:17 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 54CF53A6A14 for ; Wed, 4 Aug 2010 19:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iGPOd+GFTM1a for ; Wed, 4 Aug 2010 19:21:16 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 0CB723A6A0E for ; Wed, 4 Aug 2010 19:21:16 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.102]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Ogq5Z-000071-Nd; Wed, 04 Aug 2010 19:21:46 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Wed, 4 Aug 2010 19:20:30 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1FFABC6B-73B7-4549-A304-C34ABCB95366@cs.stanford.edu> References: <5FB5C986-D72B-41D9-A193-275DEB1D71A3@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-Scan-Signature: d35fb6c06066e474e02df1cf6298274e Cc: ROLL WG Subject: Re: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 02:21:17 -0000 Comments inline. On Aug 3, 2010, at 6:36 AM, JP Vasseur wrote: >>=20 >> 5. If Trickle hears a transmission that is "inconsistent," the >> Trickle timer resets. If I is greater than Imin,=20 >>=20 >> JP> how could that happen that I < Imin? It can't, but it can be equal to Imin. The inequality is to prevent = starvation if a node keeps on resetting its interval. >> resetting a >> Trickle timer sets I to Imin and begins a new interval. If I = is >> equal to Imin, resetting a Trickle timer does nothing. = Trickle >> may also reset the timer in response to external "events." >>=20 >> The terms consistent, inconsistent and event are in quotes because >> their meaning depends on the use of Trickle. >>=20 >>=20 >> 5. Using Trickle >>=20 >> A protocol specification that uses Trickle MUST specify: >>=20 >>=20 >>=20 >> Levis, et al. Expires January 7, 2011 [Page = 6] >> Internet-Draft draft-ietf-roll-trickle-02 July = 2010 >>=20 >>=20 >> o Default values for Imin, Imax, and k. =20 >>=20 >> JP> s/Default values/Value Why this change? >> Because link layers can >> vary widely in their properties, the default=20 >>=20 >> JP> remove "default" >> value of Imin should >> be specified in terms of the worst-case latency of a link layer >> transmission. For example, a specification should say "the >> default value of Imin is 4 times the worst case link layer >> latency"=20 >>=20 >> JP> may be worth how you define "latency" >> and should not say "the default value of Imin is 500 >> milliseconds." Worst case latency is the time until the first >> link-layer transmission of the frame assuming an idle channel >> (does not include backoff, virtual carrier sense, etc.). >>=20 >> o What constitutes a "consistent" transmission. >>=20 >> o What constitutes an "inconsistent" transmission. >>=20 >> o What "events," if any, besides inconsistent transmissions that >> reset the Trickle timer. >>=20 >>=20 >> 6. Operational Considerations >>=20 >> It is RECOMMENDED that a protocol which uses Trickle include >> mechanisms to inform nodes of configuration parameters at runtime. >> However, it is not always possible to do so. In the cases where >> different nodes have different configuration parameters, Trickle = may >> have unintended behaviors. This section outlines some of those >> behaviors and operational considerations as educational exercises. >>=20 >> 6.1. Mismatched redundancy constants >>=20 >> If nodes do not agree on the redundancy constant k, then nodes = with >> higher values of k will transmit more often than nodes with lower >> values of k. In some cases, this increased load can be = independent >> of the density. For example, consider a network where all nodes = but >> one have k=3D1, and this one node has k=3D2. The different node = can end >> up transmitting on every interval: it is maintaining a = communication >> rate of 2 with only itself. Hence, the danger of mismatched k = values >> is uneven transmission load that can deplete the energy of some >> nodes. >>=20 >> JP> Still this does not lead to interoperability issues. >> Don't we want to recommend consistent configuration ? If you agree, = then >> these comments should go at the end of this section (or beginning) = but they >> apply to several kind of mismatches I'm not sure I want to go as far as recommending consistent = configuration. E.g., if I have some nodes with more energy, they might = be willing to shoulder a greater energy burden and so have a smaller = Imax. >> 6.2. Mismatched Imin If nodes do not agree on Imin, then some = nodes, on hearing inconsistent messages, will transmit sooner than = others. These faster nodes will have their intervals grow to similar = size as the slower nodes within a single slow interval time, but in = that period may suppress the slower nodes. However, such suppression = will end after the first slow interval, when the nodes generally agree = on the interval size. Hence, mismatched Imin values are usually not a = Levis, et al. Expires January 7, 2011 [Page 7] = =0C Internet-Draft draft-ietf-roll-trickle-02 July = 2010 significant concern. 6.3. Mismatched Imax If nodes do not = agree on Imax, then this can cause long-term problems with = transmission load. Nodes with small Imax values will transmit faster, = suppressing those with larger Imax values. The nodes with larger Imax = values, always suppressed, will never transmit. In the base case, = when the network is consistent, this can cause long-term inequities in = energy cost. 6.4. Mismatched definitions If nodes do not agree on = what constitutes a consistent or inconsistent transmission, then = Trickle may fail to operate properly. For example, if a receiver = thinks a transmission is consistent, but the transmitter (if in the = receivers situation) would have thought it inconsistent, then the = receiver will not respond properly and inform the transmitter. This = can lead the network to not reach a consistent state. For this = reason, unlike the configuration constants k, Imin, and Imax, = consistency definitions should be clearly stated in the protocol and = should not be configured at runtime.=20 >> JP> I would suggest a MUST instead of a should in the sentence above. I'm wary of saying MUST; it would mean that an implementation is not = compliant with this document even if, for good reason, it has different = consistency definitions. >> 6.5. Specifying the constant k >>=20 >> There are some edge cases where a protocol may wish to use Trickle >> with its suppression disabled (k is set to infinity). In general, >> this approach is highly dangerous and it is NOT RECOMMENDED. >>=20 >> JP> I would strongly suggest to soften this statement. Just explain = the >> consequences. >> Disabling suppression means that every node will always send on = every >> interval, and can lead to congestion in dense networks. This >> approach is especially dangerous=20 OK -- I will give an explanation. >>=20 >> JP> same comment >> if many nodes reset their intervals >> at the same time. In general, it is much more desirable to set k = to >> a high value (e.g., 5 or 10) than infinity. Typical values for k = are >> 1-5: these achieve a good balance between redundancy and low cost. >>=20 >>=20 >> JP> I would suggest to add refs here. >> Nevertheless, there are situations where a protocol may wish to = turn >> off Trickle suppression. Because k is a natural number >> (Section 4.1), c=3D0 has no useful meaning. If a protocol allows = k to >> be dynamically configured, a value of 0 remains unused. For ease = of >> debugging and packet inspection, having the parameter describe = (c-1) Disagree -- it's easier for debugging when the value equals the value. = There's later text about k=3D0 and using it to represent k=3Dinf. Phil= From yoav@yitran.com Wed Aug 4 21:18:16 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF4423A6922 for ; Wed, 4 Aug 2010 21:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.307 X-Spam-Level: X-Spam-Status: No, score=-6.307 tagged_above=-999 required=5 tests=[AWL=-0.331, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1cJsipDxhjbv for ; Wed, 4 Aug 2010 21:18:16 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id CBC0E3A68F2 for ; Wed, 4 Aug 2010 21:18:15 -0700 (PDT) Received: from source ([209.85.212.49]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTFo7pBDbPu0CTyCtCzkR+UfxIBswGuMr@postini.com; Wed, 04 Aug 2010 21:18:46 PDT Received: by mail-vw0-f49.google.com with SMTP id 11so5035211vws.8 for ; Wed, 04 Aug 2010 21:18:44 -0700 (PDT) Received: by 10.220.123.198 with SMTP id q6mr6849173vcr.99.1280981923042; Wed, 04 Aug 2010 21:18:43 -0700 (PDT) From: Yoav Ben-Yehezkel MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acs0VUhOq+MKxGcCTjCUocvP/YdXpA== Date: Thu, 5 Aug 2010 07:18:40 +0300 Message-ID: <58fdd800e07c56d5ea3bb442fbb7abfd@mail.gmail.com> To: ROLL WG Content-Type: multipart/alternative; boundary=001636d351e17c9511048d0bd80c Subject: [Roll] higher priorities to RPL messages X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 04:18:17 -0000 --001636d351e17c9511048d0bd80c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi, Question to the group: Does the group think a mechanism by which RPL messages will have higher priority over data packets would be useful? Without routing, data cannot go through. If there=92s a high congestion of data traffic in the network, it could slo= w down or in some cases of link layers even completely disable the RPL messages from being transmitted altogether. Thoughts would be very much appreciated. Thanks, Yoav --001636d351e17c9511048d0bd80c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Hi,

=A0

Question to the group:

Does the group think a mechanism by which RPL messag= es will have higher priority over data packets would be useful?

Without routing, data cannot go through.

If there=92s a high congestion of data traffic in th= e network, it could slow down or in some cases of link layers even completely disable = the RPL messages from being transmitted altogether.

=A0

Thoughts would be very much appreciated.

=A0

Thanks,

Yoav

=A0

=A0

--001636d351e17c9511048d0bd80c-- From alexandru.petrescu@gmail.com Thu Aug 5 02:12:23 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51FAB3A659C for ; Thu, 5 Aug 2010 02:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.161 X-Spam-Level: X-Spam-Status: No, score=-2.161 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X2B2XJd5QDS4 for ; Thu, 5 Aug 2010 02:12:21 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id A3ED83A6ADF for ; Thu, 5 Aug 2010 02:12:20 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o759Cn6p029819 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Aug 2010 11:12:49 +0200 Received: from muguet1.intra.cea.fr (muguet1.intra.cea.fr [132.166.192.6]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o759CnIE024147; Thu, 5 Aug 2010 11:12:49 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet1.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o759CmGZ014171; Thu, 5 Aug 2010 11:12:49 +0200 Message-ID: <4C5A8090.30000@gmail.com> Date: Thu, 05 Aug 2010 11:12:48 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: roll@ietf.org References: <58fdd800e07c56d5ea3bb442fbb7abfd@mail.gmail.com> In-Reply-To: <58fdd800e07c56d5ea3bb442fbb7abfd@mail.gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] higher priorities to RPL messages X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 09:12:23 -0000 Le 05/08/2010 06:18, Yoav Ben-Yehezkel a écrit : > Hi, > > Question to the group: > > Does the group think a mechanism by which RPL messages will have > higher priority over data packets would be useful? > > Without routing, data cannot go through. That is right, if the routing tables are not set properly (with fields from DIO messages) then data won't get through, despite the potential presence of HbH or RH headers. Makes some sense to attach higher priority to control messages, but how would one do it? > If there’s a high congestion of data traffic in the network, it could > slow down or in some cases of link layers even completely disable > the RPL messages from being transmitted altogether. > > Thoughts would be very much appreciated. ICMP has this kind of characteristic - it is control. RPL messages are of an ICMP Type. How would one do it? Traffic Class of RFC2460 mentions priority: > The 8-bit Traffic Class field in the IPv6 header is available for > use by originating nodes and/or forwarding routers to identify and > distinguish between different classes or priorities of IPv6 packets. How would this priority be implemented? Are we looking at designing such a Class (reserve bits here and there) and leave implementation behaviour to specify later? Are we looking at diffserv/intserv things like rfc5455? Are we looking at extending MPLS? Are we looking at new fields to add to DIO/DAO to express this priority? All these? These are my comments, Alex > > Thanks, > > Yoav > > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Thu Aug 5 02:38:49 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C95E83A691A for ; Thu, 5 Aug 2010 02:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.164 X-Spam-Level: X-Spam-Status: No, score=-2.164 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMo+4FyLVlMN for ; Thu, 5 Aug 2010 02:38:48 -0700 (PDT) Received: from oxalide-out.extra.cea.fr (oxalide-out.extra.cea.fr [132.168.224.1]) by core3.amsl.com (Postfix) with ESMTP id 873863A68C7 for ; Thu, 5 Aug 2010 02:38:48 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by oxalide.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o759celH020479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 5 Aug 2010 11:38:40 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o759ceQg029712; Thu, 5 Aug 2010 11:38:40 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o759ceWS016894; Thu, 5 Aug 2010 11:38:40 +0200 Message-ID: <4C5A86A0.7000101@gmail.com> Date: Thu, 05 Aug 2010 11:38:40 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: Philip Levis References: <4C57317E.3070900@gmail.com> <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> bc58199e3b35de85c3e16aec79b13992@mail.gmail.com <3895b8f23b1fa4216210be0d92c8d064@mail.gmail.com> <4C59C196.7020303@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 09:38:49 -0000 Le 05/08/2010 00:20, Philip Levis a écrit : > > On Aug 4, 2010, at 12:37 PM, Alexandru Petrescu wrote: > >> Le 04/08/2010 00:34, Philip Levis a écrit : >>> >>> On Aug 2, 2010, at 10:40 PM, Yoav Ben-Yehezkel wrote: >>> >>>> One more thing - >>>> >>>> Maybe in your description you should consider also saying that >>>> trickle can also be used by link layers when the destination is >>>> broadcast or multicast. As you've noted trickle is a mechanism >>>> that doesn't really have to be bound to RPL nor to IP. >>>> >>>> What do you think? >>> >>> I agree 100%. The point is that it's to a set of nearby nodes: >> >> One would like to make sure _all_ nearby nodes that author needs >> to receive the Trickle message _will_ receive, otherwise I guess >> Trickle will fail to maintain consistency, no? > > Sort of. You won't reach consistency in a disconnected neighbor, but > the reliable delivery of individual messages is not that critical. > This is an important consideration, given the lossy nature of > wireless. > > >> >> (draft Trickle says: >>> 5. If Trickle hears a transmission that is "inconsistent," the >>> Trickle timer resets. >> what if a Trickle nodes does not hear a transmission which it >> would otherwise qualify as inconsistent.) >> >> ("near" is also a hard to define term when we talk IP). >> >> Phil said: >>> how this manifests in terms of addressing greatly depends on what >>> the underlying technologies are. I'll work on some text to try to >>> communicate this fact. >> >> Phil - just to continue on this discussion. >> >> Currently IPv6 isn't specified to run on anything which does not >> support link layer multicast. (exceptions are point-to-point links >> such as ppp and or IP-IP or GRE or other IP tunnel interfaces, >> where the addressing model is very simple: only two points are >> hearing each other.) >> >> IPv6 went to a great deal of effort to specify how the link layer >> addressing (MAC and such) converts to IPv6 link-local addresses: >> mapping functions of rfc2464, rfc4191, and more. These cases can >> be enumerated and implemented, not left to unspecified cases. >> >> Trickle not being a protocol, it is supposed to use one. If that >> protocol is IPv6 (e.g. ND, RPL, DHCP) then it won't work on >> something not using link layer multicast. >> >> Trickle running on something else than IP (i.e. Trickle on top of >> MAC messages of IEEE.x) is yet another question. It is possible >> that Trickle-straight-over-MAC may work without link-layer >> multicast. But not using IP one may wonder about specifying >> Trickle StdsTrack, or at IETF alltogether. >> >> Trickle over the adaptation layer mentioned in 6LoWPAN is probably >> such an underlying technology one thinks of running Trickle on. >> 802.15.4 high data rate does use link-layer multicast. >> >> IPv4 is indeed another question. >> >> Just some thoughts, biased of course :-) > > Given that this is the IETF, I think the right thing is to make sure > the text is in that content. E.g., link-layer broadcast isn't > important to cover. What makes this wording a little complex is the > All-RPL-Nodes multicast address. Right, how about suggesting text on the list. I could dare to suggest: "Trickle is an algorithm. It is used by an IP protocol (RPL [], more) to exchange formatted data related to IP routing; when RPL uses Trickle, RPL sends data to all-rpl-routers multicast address; when protocolX uses Trickle, protocolX sends data to addressX; a protocol undefined yet, contemplating the use of Trickle, could send data to an address yet to be defined.". Or something like this; it is good enough to me, although a bit long. Listening to what you think the text should be. Alex > > Phil From ulrich@herberg.name Thu Aug 5 03:59:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA8603A6AF4 for ; Thu, 5 Aug 2010 03:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[AWL=0.741, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hvi6MwUvx7Ap for ; Thu, 5 Aug 2010 03:59:34 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id DD0063A6860 for ; Thu, 5 Aug 2010 03:59:33 -0700 (PDT) Received: by vws10 with SMTP id 10so5407541vws.31 for ; Thu, 05 Aug 2010 04:00:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.61.9 with SMTP id r9mr7041885vch.263.1281006003929; Thu, 05 Aug 2010 04:00:03 -0700 (PDT) Received: by 10.220.183.73 with HTTP; Thu, 5 Aug 2010 04:00:03 -0700 (PDT) In-Reply-To: <75AAB6AE-B4ED-435E-9F37-5135356165D4@cs.stanford.edu> References: <4C57317E.3070900@gmail.com> <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> <75AAB6AE-B4ED-435E-9F37-5135356165D4@cs.stanford.edu> Date: Thu, 5 Aug 2010 13:00:03 +0200 Message-ID: From: Ulrich Herberg To: Philip Levis Content-Type: multipart/alternative; boundary=e0cb4e8873ddd1c1ac048d1173c3 Cc: ROLL WG Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 10:59:34 -0000 --e0cb4e8873ddd1c1ac048d1173c3 Content-Type: text/plain; charset=ISO-8859-1 Phil, On Thu, Aug 5, 2010 at 2:22 AM, Philip Levis wrote: > > On Aug 4, 2010, at 10:08 AM, Ulrich Herberg wrote: > > > > > That sounds reasonable. Would all nodes in the network have to agree > (i.e. by preconfiguration) on the same multicast address? I guess so... > > Hm -- I actually think it would be specified by the protocol using Trickle. > E.g., some protocols might just use the link-local multicast address, while > RPL, say, uses the All-RPL-Nodes local multicast address. It's not > inconceivable that a protocol allows this address to be configured, but my > feeling is that such a statement belongs outside this particular draft. Does > that make sense? > Yes, you are right, that makes sense. Ulrich --e0cb4e8873ddd1c1ac048d1173c3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Phil,

On Thu, Aug 5, 2010 at 2:22 AM, Phi= lip Levis <pal@= cs.stanford.edu> wrote:

On Aug 4, 2010, at 10:08 AM, Ulrich Herberg wrote:

>
> That sounds reasonable. Would all nodes in the network have to agree (= i.e. by preconfiguration) on the same multicast address? I guess so...

Hm -- I actually think it would be specified by the protocol using Tr= ickle. E.g., some protocols might just use the link-local multicast address= , while RPL, say, uses the All-RPL-Nodes local multicast address. It's = not inconceivable that a protocol allows this address to be configured, but= my feeling is that such a statement belongs outside this particular draft.= Does that make sense?

Yes, you are right, that makes sense.

Ulrich <= br>
--e0cb4e8873ddd1c1ac048d1173c3-- From richard.kelsey@ember.com Thu Aug 5 09:29:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 402923A6A07 for ; Thu, 5 Aug 2010 09:29:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zugohV+pvzIi for ; Thu, 5 Aug 2010 09:29:39 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 6BE353A6978 for ; Thu, 5 Aug 2010 09:29:39 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Aug 2010 12:30:09 -0400 Date: Thu, 05 Aug 2010 12:30:39 -0400 Message-Id: <87lj8lc98w.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: <7530319E-679C-48A0-9B5A-90AA69961BD1@cs.stanford.edu> (message from Philip Levis on Wed, 4 Aug 2010 08:13:44 -0700) From: Richard Kelsey References: <874ofbff0d.fsf@kelsey-ws.hq.ember.com> <87ocdicucl.fsf@kelsey-ws.hq.ember.com> <7530319E-679C-48A0-9B5A-90AA69961BD1@cs.stanford.edu> X-OriginalArrivalTime: 05 Aug 2010 16:30:09.0551 (UTC) FILETIME=[788211F0:01CB34BB] Cc: roll@ietf.org Subject: Re: [Roll] RPL hop-by-hop and source route X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 16:29:41 -0000 > From: Philip Levis > Date: Wed, 4 Aug 2010 08:13:44 -0700 > > All RPLInstances provide upward routes; not all instances provide > downward routes. A source routing header is used for downward > routes. So... or are you thinking about the current proposal for lower > stretch P2P communication? No, I was just thinking of the more general, non-source-routing case. > The intent of my reply was *not* to say that there MUST be a > hop-by-hop header when there's a source routed packet. It was to > answer the question "What purpose would the hop-by-hop option serve?" > To answer was "To ensure that a resulting ICMP error uses the same > RPLInstance when possible." It's an open questions whether this is > important. Yes. At the ZigBee/IP interop we can try running without a hop-by-hop header when a source router header is present and see if the IETF black helicopters show up. -Richard Kelsey From pal@cs.stanford.edu Thu Aug 5 12:33:17 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B21E3A680A for ; Thu, 5 Aug 2010 12:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORR9cWukeeVG for ; Thu, 5 Aug 2010 12:33:05 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id CAC883A6901 for ; Thu, 5 Aug 2010 12:31:55 -0700 (PDT) Received: from dn0a2100b4.sunet ([10.33.0.180]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Oh6AK-0004hH-G5; Thu, 05 Aug 2010 12:31:44 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <1FFABC6B-73B7-4549-A304-C34ABCB95366@cs.stanford.edu> Date: Thu, 5 Aug 2010 11:04:17 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <12766418-F99F-4AB0-98F7-087C95720231@cs.stanford.edu> References: <5FB5C986-D72B-41D9-A193-275DEB1D71A3@cisco.com> <1FFABC6B-73B7-4549-A304-C34ABCB95366@cs.stanford.edu> To: Philip Levis X-Mailer: Apple Mail (2.1081) X-Scan-Signature: a11a15d02c0ec4233875b3872b0caebb Cc: ROLL WG Subject: Re: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 19:33:18 -0000 On Aug 4, 2010, at 7:20 PM, Philip Levis wrote: > This can lead the network to not reach a consistent state. For this = reason, unlike the configuration constants k, Imin, and Imax, = consistency definitions should be clearly stated in the protocol and = should not be configured at runtime.=20 >>> JP> I would suggest a MUST instead of a should in the sentence = above. >=20 > I'm wary of saying MUST; it would mean that an implementation is not = compliant with this document even if, for good reason, it has different = consistency definitions. Sorry, I miswrote. I agree that the sentence should say MUST, and SHOULD = NOT. So, > For this reason, unlike the configuration constants k, Imin, and = Imax, consistency definitions MUST be clearly stated in the protocol = and SHOULD NOT be configured at runtime.=20 Sound good? Although the MUST is redundant with prior text... Phil= From pal@cs.stanford.edu Thu Aug 5 12:33:20 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 519993A6B4C for ; Thu, 5 Aug 2010 12:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.397 X-Spam-Level: X-Spam-Status: No, score=-6.397 tagged_above=-999 required=5 tests=[AWL=0.202, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kIVN0ZnL2Pym for ; Thu, 5 Aug 2010 12:33:17 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 824593A698A for ; Thu, 5 Aug 2010 12:32:15 -0700 (PDT) Received: from dn0a2100b4.sunet ([10.33.0.180]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Oh6AJ-0004hH-8I; Thu, 05 Aug 2010 12:31:43 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: <58fdd800e07c56d5ea3bb442fbb7abfd@mail.gmail.com> Date: Thu, 5 Aug 2010 10:27:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7895F3AA-B486-4250-B4A4-B647972E82FE@cs.stanford.edu> References: <58fdd800e07c56d5ea3bb442fbb7abfd@mail.gmail.com> To: Yoav Ben-Yehezkel X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 72f97ea9660f372cf635c7c250d627db Cc: ROLL WG Subject: Re: [Roll] higher priorities to RPL messages X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 19:33:20 -0000 On Aug 4, 2010, at 9:18 PM, Yoav Ben-Yehezkel wrote: > Hi, > =20 > Question to the group: > Does the group think a mechanism by which RPL messages will have = higher priority over data packets would be useful? > Without routing, data cannot go through. > If there=92s a high congestion of data traffic in the network, it = could slow down or in some cases of link layers even completely disable = the RPL messages from being transmitted altogether. > =20 > Thoughts would be very much appreciated. My 2 cents: This seems out of scope. It's an implementation decision, as it has = implications based on what the underlying OS scheduling algorithm is. In = the context of LLNs, at least, high congestion is not very common. We = should assume that the OS or implementation does something intelligent, = rather than enforce external policies. E.g., we expect OS kernels to = schedule packets to different open TCP streams intelligently, rather = than enforce some kind of scheduling policy. I'll try to ground this in my experiences with the TinyOS implementation = of CTP. TinyOS uses a round-robin packet scheduler at the link layer. = Each packet send client (the best analogy to traditional OSes would be = file descriptor) has one reserved slot in a queue, and the link layer = scans this queue for packets to send[1]. If a packet source, such as a = routing protocol, wants to support having more than a single pending = transmission, it layers its own transmission queue on top of this link = layer queue. CTP has two packet send clients: one for data packets, one for control = packets. This means that, even in the presence of high data traffic, a = pending control packet has to wait at most one data packet before being = transmitted, and in the worst case control packets receive 50% of the = link throughput given to the routing protocol. The CTP implementation = handles the starvation problem with an intelligent use of the underlying = OS abstractions. Phil [1] tinyos-2.x/tos/system/AMQueueImplP.nc:nextPacket() From richard.kelsey@ember.com Thu Aug 5 13:23:47 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252933A6886 for ; Thu, 5 Aug 2010 13:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4rpHdgMMkL1P for ; Thu, 5 Aug 2010 13:23:46 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id D35FF3A6851 for ; Thu, 5 Aug 2010 13:23:45 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Aug 2010 16:24:16 -0400 Date: Thu, 05 Aug 2010 16:24:45 -0400 Message-Id: <87hbj8dcz6.fsf@kelsey-ws.hq.ember.com> To: Philip Levis In-reply-to: <7895F3AA-B486-4250-B4A4-B647972E82FE@cs.stanford.edu> (message from Philip Levis on Thu, 5 Aug 2010 10:27:26 -0700) From: Richard Kelsey References: <58fdd800e07c56d5ea3bb442fbb7abfd@mail.gmail.com> <7895F3AA-B486-4250-B4A4-B647972E82FE@cs.stanford.edu> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 05 Aug 2010 20:24:16.0132 (UTC) FILETIME=[2CEC3C40:01CB34DC] Cc: roll@ietf.org Subject: Re: [Roll] higher priorities to RPL messages X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2010 20:23:47 -0000 > From: Philip Levis > Date: Thu, 5 Aug 2010 10:27:26 -0700 > > Does the group think a mechanism by which RPL messages > > will have higher priority over data packets would be > > useful? Without routing, data cannot go through. If > > there’s a high congestion of data traffic in the > > network, it could slow down or in some cases of link > > layers even completely disable the RPL messages from > > being transmitted altogether. > > This seems out of scope. It's an implementation decision, as it has > implications based on what the underlying OS scheduling algorithm > is. In the context of LLNs, at least, high congestion is not very > common. For battery-operated LLNs, perhaps. For ZigBee-style line-powered LLNs, occasional congestion is not uncommon. I do agree with Phil that dealing with congestion is out of scope for RPL. -Richard Kelsey From prvs=8279f281f=mukul@uwm.edu Thu Aug 5 21:31:18 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5E523A684D for ; Thu, 5 Aug 2010 21:31:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.746 X-Spam-Level: X-Spam-Status: No, score=-2.746 tagged_above=-999 required=5 tests=[AWL=-1.636, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U7UIpGli+UCj for ; Thu, 5 Aug 2010 21:31:17 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 144CF3A6358 for ; Thu, 5 Aug 2010 21:31:16 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 05 Aug 2010 23:31:47 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 79B9F2B3F05 for ; Thu, 5 Aug 2010 23:31:24 -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 LBSB+qWdye0w for ; Thu, 5 Aug 2010 23:31:24 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 5253B2B3F03 for ; Thu, 5 Aug 2010 23:31:24 -0500 (CDT) Date: Thu, 5 Aug 2010 23:31:47 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <2003936330.353717.1281069107126.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] The D and DODAGID fields inside a DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 04:31:18 -0000 I guess I dont understand the purpose of the D and DODAGID fields inside a DAO. The D field indicates if the RPLInstanceID value inside the DAO is local. But, isn't that information contained in the RPLInstanceID value itself? Also, the DODAGID field is to be included only if the RPLInstanceID value is local. But, in that case, the DODAGID value can be identified by examining the D bit inside the local RPLInstanceID and the source/destination IPv6 address of the packet. Thanks Mukul From prvs=8279f281f=mukul@uwm.edu Thu Aug 5 23:05:57 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A443A6934 for ; Thu, 5 Aug 2010 23:05:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.365 X-Spam-Level: X-Spam-Status: No, score=-3.365 tagged_above=-999 required=5 tests=[AWL=-0.766, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3C1IDAgcitlj for ; Thu, 5 Aug 2010 23:05:56 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 498663A684D for ; Thu, 5 Aug 2010 23:05:56 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 06 Aug 2010 01:06:26 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 1B3632B3F05 for ; Fri, 6 Aug 2010 01:06:04 -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 NsrZrHcy3bOq for ; Fri, 6 Aug 2010 01:06:03 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id E3E932B3F03 for ; Fri, 6 Aug 2010 01:06:03 -0500 (CDT) Date: Fri, 6 Aug 2010 01:06:26 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <577125715.354106.1281074786743.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <702300541.354075.1281074052015.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Section 9.7 in RPL-11 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 06:05:57 -0000 In non-storing mode operation, a DAO is always unicast to the DAG root. I guess it means that the RPL process in non-root nodes never get to see a DAO some body else generated. If this is true, I am really confused about the following excerpts from Section 9.7 in RPL-11 that deals with non-storing mode operation. " 2. On receiving a unicast DAO, a node MUST propagate the updated downward route information upwards. The node MAY use any parent in the parent set. The downward route information in the DAO message MAY be aggregated with other DAOs before being propagated upwards, which MAY entail to delay the propagation as described below. " As I mentioned above, I don't think that the RPL process in a non-root node would get to see a DAO some other node generated. So, the text above does not make much sense. "...Therefore, in non-storing mode, a node can send a single DAO, ALTHOUGH IT MIGHT CHOOSE TO SEND MORE THAN ONE DAO MESSAGE TO EACH OF MULTIPLE DAO PARENTS." Again, if DAOs are unicast to the root, the text in capital above does not make sense. Thanks Mukul From Matteo.Paris@ember.com Fri Aug 6 08:03:02 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB303A695E for ; Fri, 6 Aug 2010 08:03:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.233, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jyGEuHP5Ar3t for ; Fri, 6 Aug 2010 08:03:01 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 7AA7F3A6AC1 for ; Fri, 6 Aug 2010 08:03:00 -0700 (PDT) Received: from [192.168.81.65] ([192.168.81.65]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 6 Aug 2010 11:03:30 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <2003936330.353717.1281069107126.JavaMail.root@mail02.pantherlink.uwm.edu> References: <2003936330.353717.1281069107126.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Fri, 6 Aug 2010 11:03:29 -0400 To: Mukul Goyal , roll From: Matteo Paris Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-OriginalArrivalTime: 06 Aug 2010 15:03:31.0039 (UTC) FILETIME=[885DD6F0:01CB3578] Subject: Re: [Roll] The D and DODAGID fields inside a DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 15:03:02 -0000 Hi Mukul, RPL-11 section 6.4.1 says: "The 'D' flag indicates that the DODAGID field is present. This flag MUST be set when a local RPLInstanceID is used." This makes sense for storing mode. But in non-storing mode, we should not require the 'D' flag to be set, because the DODAGID is the IP destination of the packet. I brought this up previously here: http://www.ietf.org/mail-archive/web/roll/current/msg05119.html Pascal felt the 'D' flag should be required to be set even in non-storing mode, and that the redundant DODAGID should be compressed out by some yet-to-be-specified mechanism. I think unsetting the 'D' flag is a good mechanism ;-) I'd like to solicit WG input: (a) Leave the text as is. (b) Change the text to read "This flag MUST be set when a local RPLInstanceID is used in a storing mode of operation." Thanks, Matteo At 11:31 PM -0500 8/5/10, Mukul Goyal wrote: >I guess I dont understand the purpose of the D and DODAGID fields >inside a DAO. > >The D field indicates if the RPLInstanceID value inside the DAO is >local. But, isn't that information contained in the RPLInstanceID >value itself? > >Also, the DODAGID field is to be included only if the RPLInstanceID >value is local. But, in that case, the DODAGID value can be >identified by examining the D bit inside the local RPLInstanceID and >the source/destination IPv6 address of the packet. > >Thanks >Mukul > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From prvs=8279f281f=mukul@uwm.edu Fri Aug 6 08:39:14 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFB8A3A6A53 for ; Fri, 6 Aug 2010 08:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.31 X-Spam-Level: X-Spam-Status: No, score=-3.31 tagged_above=-999 required=5 tests=[AWL=-0.711, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zKdjNXfgTv1 for ; Fri, 6 Aug 2010 08:39:13 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id C61403A6AE1 for ; Fri, 6 Aug 2010 08:39:13 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 06 Aug 2010 10:39:45 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 059E32B3F08; Fri, 6 Aug 2010 10:39:22 -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 3A3ehKfFFoIh; Fri, 6 Aug 2010 10:39:21 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id D3B382B3F07; Fri, 6 Aug 2010 10:39:21 -0500 (CDT) Date: Fri, 6 Aug 2010 10:39:44 -0500 (CDT) From: Mukul Goyal To: Jonathan Hui Message-ID: <1797480010.363793.1281109184907.JavaMail.root@mail02.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: [Roll] does an RH4 header or an RPLoption in HbH header imply a data packet? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 15:39:15 -0000 Hi all, I need a bit of help. My impression is that the presence of an RH4 source route header or an RPL option in IPv6 hop-by-hop header imply that the packet is a data packet and not an RPL control packet. So, if I want the RPL process in a router to process a packet, I should not use an RH4 header or an IPv6 hop-by-hop header in that packet. Please let me know if this is not correct. Thanks Mukul From prvs=828ff8a7c=mukul@uwm.edu Fri Aug 6 18:40:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D3ED3A6782 for ; Fri, 6 Aug 2010 18:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.263 X-Spam-Level: X-Spam-Status: No, score=-3.263 tagged_above=-999 required=5 tests=[AWL=-0.664, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9G8z2ci87X8 for ; Fri, 6 Aug 2010 18:40:02 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 4B0793A6407 for ; Fri, 6 Aug 2010 18:40:01 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 06 Aug 2010 20:40:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 7A3712B3F05; Fri, 6 Aug 2010 20:40:10 -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 7eYTLi0IiEvN; Fri, 6 Aug 2010 20:40:09 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 76F4A2B3F03; Fri, 6 Aug 2010 20:40:09 -0500 (CDT) Date: Fri, 6 Aug 2010 20:40:32 -0500 (CDT) From: Mukul Goyal To: Matteo Paris Message-ID: <1283744782.380564.1281145232750.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] The D and DODAGID fields inside a DAO X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Aug 2010 01:40:03 -0000 Hi Matteo I think I prefer option b. Thanks Mukul ----- Original Message ----- From: "Matteo Paris" To: "Mukul Goyal" , "roll" Sent: Friday, August 6, 2010 10:03:29 AM Subject: Re: [Roll] The D and DODAGID fields inside a DAO Hi Mukul, RPL-11 section 6.4.1 says: "The 'D' flag indicates that the DODAGID field is present. This flag MUST be set when a local RPLInstanceID is used." This makes sense for storing mode. But in non-storing mode, we should not require the 'D' flag to be set, because the DODAGID is the IP destination of the packet. I brought this up previously here: http://www.ietf.org/mail-archive/web/roll/current/msg05119.html Pascal felt the 'D' flag should be required to be set even in non-storing mode, and that the redundant DODAGID should be compressed out by some yet-to-be-specified mechanism. I think unsetting the 'D' flag is a good mechanism ;-) I'd like to solicit WG input: (a) Leave the text as is. (b) Change the text to read "This flag MUST be set when a local RPLInstanceID is used in a storing mode of operation." Thanks, Matteo At 11:31 PM -0500 8/5/10, Mukul Goyal wrote: >I guess I dont understand the purpose of the D and DODAGID fields >inside a DAO. > >The D field indicates if the RPLInstanceID value inside the DAO is >local. But, isn't that information contained in the RPLInstanceID >value itself? > >Also, the DODAGID field is to be included only if the RPLInstanceID >value is local. But, in that case, the DODAGID value can be >identified by examining the D bit inside the local RPLInstanceID and >the source/destination IPv6 address of the packet. > >Thanks >Mukul > >_______________________________________________ >Roll mailing list >Roll@ietf.org >https://www.ietf.org/mailman/listinfo/roll From yoav@yitran.com Sun Aug 8 00:12:55 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF3153A67AF for ; Sun, 8 Aug 2010 00:12:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.296 X-Spam-Level: X-Spam-Status: No, score=-6.296 tagged_above=-999 required=5 tests=[AWL=-0.319, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VY7GILQvB-ns for ; Sun, 8 Aug 2010 00:12:53 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id 044E63A6821 for ; Sun, 8 Aug 2010 00:12:51 -0700 (PDT) Received: from source ([209.85.216.44]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTF5ZE/ok270KqmLWCbfLK7tu3Aix0b+0@postini.com; Sun, 08 Aug 2010 00:13:26 PDT Received: by qwe5 with SMTP id 5so7698934qwe.17 for ; Sun, 08 Aug 2010 00:13:23 -0700 (PDT) Received: by 10.220.177.202 with SMTP id bj10mr1425680vcb.0.1281251603172; Sun, 08 Aug 2010 00:13:23 -0700 (PDT) From: Yoav Ben-Yehezkel References: <58fdd800e07c56d5ea3bb442fbb7abfd@mail.gmail.com> <7895F3AA-B486-4250-B4A4-B647972E82FE@cs.stanford.edu> <87hbj8dcz6.fsf@kelsey-ws.hq.ember.com> In-Reply-To: <87hbj8dcz6.fsf@kelsey-ws.hq.ember.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acs03C6h29x7f4SxT22dscvUPSDWRAB7Bq5w Date: Sun, 8 Aug 2010 10:13:21 +0300 Message-ID: To: Richard Kelsey , Philip Levis Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: roll@ietf.org Subject: Re: [Roll] higher priorities to RPL messages X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 08 Aug 2010 07:12:55 -0000 Thanks for the useful responses and discussion. I agree that this is not an RPL issue per-se. Still, I'd like to clarify my point. I'm not looking to do any special thing in RPL to support this. All routing algorithms (not just RPL) would suffer equally from not being prioritized over regular data frames. There are methods by the underlying link layers that provide priorities and QoS (802.11e, for example). I was looking for a recommendation in the RPL spec for signaling to those link layers that RPL messages is of higher priority than regular data packets. Since this problem is generic to all routing and maybe other ICMP messages, maybe a more generic pointer exists in another RFC? Are the leads that Alex provided correct? Thanks, Yoav -----Original Message----- From: Richard Kelsey [mailto:richard.kelsey@ember.com] Sent: Thursday, August 05, 2010 11:25 PM To: Philip Levis Cc: yoav@yitran.com; roll@ietf.org Subject: Re: [Roll] higher priorities to RPL messages > From: Philip Levis > Date: Thu, 5 Aug 2010 10:27:26 -0700 > > Does the group think a mechanism by which RPL messages > > will have higher priority over data packets would be > > useful? Without routing, data cannot go through. If > > there=92s a high congestion of data traffic in the > > network, it could slow down or in some cases of link > > layers even completely disable the RPL messages from > > being transmitted altogether. > > This seems out of scope. It's an implementation decision, as it has > implications based on what the underlying OS scheduling algorithm > is. In the context of LLNs, at least, high congestion is not very > common. For battery-operated LLNs, perhaps. For ZigBee-style line-powered LLNs, occasional congestion is not uncommon. I do agree with Phil that dealing with congestion is out of scope for RPL. -Richard Kelsey From prvs=830aacfb9=mukul@uwm.edu Sun Aug 8 19:32:36 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F094C3A6A1E for ; Sun, 8 Aug 2010 19:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.221 X-Spam-Level: X-Spam-Status: No, score=-3.221 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0H3iLtt7LRYv for ; Sun, 8 Aug 2010 19:32:25 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id E3D763A6A1D for ; Sun, 8 Aug 2010 19:32:24 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 08 Aug 2010 21:32:58 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 1D3272B3F05 for ; Sun, 8 Aug 2010 21:32:34 -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 wK2f0exCfeOh for ; Sun, 8 Aug 2010 21:32:33 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 7E3D42B3F03 for ; Sun, 8 Aug 2010 21:32:33 -0500 (CDT) Date: Sun, 8 Aug 2010 21:32:57 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1048614705.395688.1281321177838.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <20100809022959.CF65C3A6A17@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Fwd: New Version Notification for draft-dt-roll-p2p-rpl-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 02:32:36 -0000 Hi all, Here is the new version of the P2P draft. It takes in account all the comments received so far. I would like to request WG status for the draft. Comments welcome. Regards Mukul ----- Forwarded Message ----- From: "IETF I-D Submission Tool" To: mukul@uwm.edu Cc: "Emmanuel Baccelli" Sent: Sunday, August 8, 2010 9:29:59 PM Subject: New Version Notification for draft-dt-roll-p2p-rpl-02 A new version of I-D, draft-dt-roll-p2p-rpl-02.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository. Filename: draft-dt-roll-p2p-rpl Revision: 02 Title: Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Creation_date: 2010-08-09 WG ID: Independent Submission Number_of_pages: 22 Abstract: Point to point (P2P) communication between arbitrary IPv6 routers and hosts in a Low power and Lossy Network (LLN) is a key requirement for many applications. RPL, the IPv6 Routing Protocol for LLNs, constrains the LLN topology to a Directed Acyclic Graph (DAG) and requires the P2P routing to take place along the DAG links. Such P2P routes may be significantly suboptimal and may lead to traffic congestion near the DAG root. This document describes a P2P route discovery mechanism complementary to RPL base functionality. This mechanism allows an RPL-aware IPv6 router or host to discover and establish on demand one or more routes to another RPL-aware IPv6 router or host in the LLN such that the discovered routes meet the specified cost criteria. The IETF Secretariat. From pthubert@cisco.com Mon Aug 9 01:57:39 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE1C73A68D0 for ; Mon, 9 Aug 2010 01:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.458 X-Spam-Level: X-Spam-Status: No, score=-10.458 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcNIT1AaE2uB for ; Mon, 9 Aug 2010 01:57:35 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id D09ED3A6AA3 for ; Mon, 9 Aug 2010 01:57:34 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnEFADJgX0xAZnwM/2dsb2JhbACBRJ8AcadKmmCFOgSMCQ X-IronPort-AV: E=Sophos;i="4.55,341,1278288000"; d="scan'208,217";a="145330869" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2010 08:58:08 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o798w7eg015559; Mon, 9 Aug 2010 08:58:08 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Aug 2010 10:58:07 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB37A0.FC1D4390" Date: Mon, 9 Aug 2010 10:57:48 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D027CC9A4@XMB-AMS-107.cisco.com> In-Reply-To: <58fdd800e07c56d5ea3bb442fbb7abfd@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] higher priorities to RPL messages thread-index: Acs0VUhOq+MKxGcCTjCUocvP/YdXpADSb0Eg References: <58fdd800e07c56d5ea3bb442fbb7abfd@mail.gmail.com> From: "Pascal Thubert (pthubert)" To: "Yoav Ben-Yehezkel" , "ROLL WG" X-OriginalArrivalTime: 09 Aug 2010 08:58:07.0944 (UTC) FILETIME=[FC6C4480:01CB37A0] Subject: Re: [Roll] higher priorities to RPL messages X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 08:57:39 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB37A0.FC1D4390 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Yoav: =20 There is a well-established practice, that's underlined in RFC 4594: =20 3.1. Current Practice in the Internet =20 =20 Based on today's routing protocols and network control procedures that are used in the Internet, we have determined that CS6 DSCP value SHOULD be used for routing and control and that CS7 DSCP value SHOULD be reserved for future use, potentially for future routing or control protocols. Network administrators MAY use a Local/Experimental DSCP; therefore, they may use a locally defined service class within their network to further differentiate their routing and control traffic. =20 =20 It is implicitly the expectation that all RPL messages will be using CS6 (110000). =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Yoav Ben-Yehezkel Sent: Thursday, August 05, 2010 6:19 AM To: ROLL WG Subject: [Roll] higher priorities to RPL messages =20 Hi, =20 Question to the group: Does the group think a mechanism by which RPL messages will have higher priority over data packets would be useful? Without routing, data cannot go through. If there's a high congestion of data traffic in the network, it could slow down or in some cases of link layers even completely disable the RPL messages from being transmitted altogether. =20 Thoughts would be very much appreciated. =20 Thanks, Yoav =20 =20 ------_=_NextPart_001_01CB37A0.FC1D4390 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Yoav:

 

There is a = well-established practice, that’s underlined in RFC = 4594:

 

3.1.  Current = Practice in the Internet

 

 

   Based = on today's routing protocols and network control = procedures

   that = are used in the Internet, we have determined that CS6 DSCP = value

   SHOULD = be used for routing and control and that CS7 DSCP value = SHOULD

   be = reserved for future use, potentially for future routing or = control

   = protocols.  Network administrators MAY use a Local/Experimental = DSCP;

   = therefore, they may use a locally defined service class within = their

   = network to further differentiate their routing and control = traffic.

 

 

It is implicitly the = expectation that all RPL messages will be using CS6 = (110000).

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Yoav Ben-Yehezkel
Sent: Thursday, August 05, 2010 6:19 = AM
To: ROLL WG
Subject: [Roll] higher priorities to = RPL messages

 

Hi,

 

Question to = the group:

Does the group think a = mechanism by which RPL messages will have higher priority over data = packets would be useful?

Without = routing, data cannot go through.

If = there’s a high congestion of data traffic in the network, it could = slow down or in some cases of link layers even completely disable the = RPL messages from being transmitted altogether.

 

Thoughts = would be very much appreciated.

 

Thanks,

Yoav

 

 

------_=_NextPart_001_01CB37A0.FC1D4390-- From pthubert@cisco.com Mon Aug 9 02:24:45 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 75E9A3A69E4 for ; Mon, 9 Aug 2010 02:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.46 X-Spam-Level: X-Spam-Status: No, score=-10.46 tagged_above=-999 required=5 tests=[AWL=0.139, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0g56EUNpoFe for ; Mon, 9 Aug 2010 02:24:44 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 66FA53A69DC for ; Mon, 9 Aug 2010 02:24:44 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA9mX0xAZnwM/2dsb2JhbACgRHGnOZphhToEjAk X-IronPort-AV: E=Sophos;i="4.55,341,1278288000"; d="scan'208";a="145338960" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2010 09:25:18 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o799PHu0006324; Mon, 9 Aug 2010 09:25:18 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Aug 2010 11:25:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Aug 2010 11:25:14 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D027CC9CC@XMB-AMS-107.cisco.com> In-Reply-To: <874ofbff0d.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL hop-by-hop and source route thread-index: AcszZGOfiwFaJ9plS8OAYcA2M20slgEPve9g References: <874ofbff0d.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" , X-OriginalArrivalTime: 09 Aug 2010 09:25:17.0465 (UTC) FILETIME=[C7B17090:01CB37A4] Subject: Re: [Roll] RPL hop-by-hop and source route X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 09:24:45 -0000 Hi Richard: The RPL option in HbH hdr serves not only as loop avoidance but also as an error detection mechanism. If you do not use it, Rank errors will not be detected, and the root cannot be updated with DAO that fix its view of the network. That view of the network is per instance. So if we wish to report any error to the root, we need the instanceID. The text is lacking details about the "Error in Source Routing Header" ICMP message that is used to carry the error. The message should at least echo the packet in error up to HpH and Routing headers. I'd expect that in the RPL option therein, the flags will be set to indicate a Rank error (R bit) of the impossibility to forward down because the next entry in the RH is not reachable (F bit). Makes sense? Pascal > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Richard Kelsey > Sent: Wednesday, August 04, 2010 1:33 AM > To: roll@ietf.org > Subject: [Roll] RPL hop-by-hop and source route >=20 > A question came up in the planning for the next ZigBeeIP interop. If a packet > has a source route, must it also have a RPL hop-by-hop option? What purpose > would the hop-by-hop option serve? > -Richard Kelsey > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pthubert@cisco.com Mon Aug 9 03:17:39 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DD8B3A6970; Mon, 9 Aug 2010 03:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.464 X-Spam-Level: X-Spam-Status: No, score=-10.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZagoDInj4Kw; Mon, 9 Aug 2010 03:17:37 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5B1E23A696E; Mon, 9 Aug 2010 03:17:37 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPJyX0ytJV2Y/2dsb2JhbACgRHGmT40DjWuCe4I/BIwJ X-IronPort-AV: E=Sophos;i="4.55,341,1278288000"; d="scan'208";a="145360957" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2010 10:18:10 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rcdn-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id o79AHEge018849; Mon, 9 Aug 2010 10:18:09 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Aug 2010 12:17:58 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Aug 2010 12:17:55 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> In-Reply-To: <11162.1280887515@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow Label: 12 bits mutable and 8 bits immutable thread-index: AcsznzBwYeSX1IkTTh2hYfnEYleNpQECxNSQ References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: "Michael Richardson" , , "Carsten Bormann" X-OriginalArrivalTime: 09 Aug 2010 10:17:58.0303 (UTC) FILETIME=[23B30AF0:01CB37AC] Cc: ipv6@ietf.org Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 10:17:39 -0000 Hi Michael: With http://tools.ietf.org/html/draft-ietf-roll-rpl-07#section-7.2 I tried to stay within the lines of RFC 3697 as you also defend in your mail.=20 I think the question we have now is not whether that proposal is lawful but whether the new law being defined at 6MAN would prevent it in the future. If the updated rules allow, then I'll be glad to work on an FL-based alternate to the IPinIP/HbH.=20 It appeared at the 6MAN WG meeting that 12 bits mutable was exactly what the core network was asking for to do its load balancing. A first question to the group could be whether 12 mutable bits are enough for the sensible usages envisioned so far? Pascal > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Michael Richardson > Sent: Wednesday, August 04, 2010 4:05 AM > To: roll@ietf.org; Carsten Bormann > Cc: Pascal Thubert (pthubert); ipv6@ietf.org > Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable >=20 >=20 > {there is a thread which started on roll@ietf.org, and ipv6@ietf.org, and then > seemed to have dropped roll@ietf.org. I'm not on ipv6@ietf.org, so there likely > are message there I've missed} >=20 > okay, so I've read Carsen's opinion. > I read RFC 3697 (which I didn't know about). >=20 > draft-hu-flow-label-cases-00 is a very good read. I pull out something from > section 4 (Discussion); >=20 > The other choice, for designers who wish to use the flow label to > control switching or QoS directly, is to bypass the rules within a > given domain (a set of cooperating nodes) in a way that nodes outside > the domain cannot detect. In this case, any deviation from [RFC3697] > has no possible effect outside the domain in question. >=20 > I don't know where this subject line is from: 12 bits/8bits. > Is there a draft that explains that idea that I've missed? >=20 > My claim is that ROLL's RPL is a set of cooperating nodes. >=20 > But, it's better than that --- it's a set of routers which are tuned to support > specific applications, and the applications want in this case to be given > information like, "what flow label" to use. RPL's RPLinstanceID has all the > properties required of a flow label (or, rather, it has no requirements presently, > and therefore can have the flow label requirements imposed upon it, > specifically: > 2. "Nodes MUST NOT assume any mathematical or other properties of > the Flow Label" > ) >=20 > The non-mutability of the label isn't a problem either --- the applications *AT > EACH END*, even if one end of the application is several AS's away (a very > unusual case for 95% of RPL's target use), that application still needs to know > something about what label to use. >=20 > There are three cases to consider: > a) traffic between two RPL nodes > b) traffic exiting an RPL > c) traffic entering an RPL >=20 > case (a) -- is the "set of cooperating nodes", and therefore is no problem. >=20 > case (b) -- the flow label is set to get through the RPL/LLN, and out to > the network, and the flow label has done it's job, and > the RPL/LLN network could care less what happens to the flow > label at that point. The rest of the network might have a > problem (i.e. a bug) when RPL networks start sending > non-zero flow labels, but that's the rest of the network's > problem. >=20 > case (c) - flow labels of zero are not a problem. There is either a > default RPLinstanceID to use (and traffic flows, perhaps not > optimally), or there isn't (and ICMP Host unreachable occurs). >=20 > - non-zero flow labels which do not map to an RPLinstanceID, > are simply considered zero, see above. > - non-zero flow labels which map to RPLinstanceIDs are used. > *If* it is a problem for outsiders to invoke that LLN's > DODAG, then there are bigger issues, which the flow label can neither > help nor hinder --- the flowlabel is not a magic security cookie. > A firewall may still be required. >=20 > The only real problem I can see is when a packet needs to do (b) and > (c). e.g. use label A to exit LLN alpha, and label B to enter LLN beta. >=20 > I don't have a solution to this. Some have suggested IPIP tunnels, which sound > nice in theory, but in practice do not work in the wilderness found behind the > walls of walled gardens. >=20 > -- > ] 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. >=20 >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From richard.kelsey@ember.com Mon Aug 9 05:26:15 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 56F2828C0DC for ; Mon, 9 Aug 2010 05:26:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[AWL=0.223, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a4bNnzeTwcpp for ; Mon, 9 Aug 2010 05:26:14 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 5F8A328C0EB for ; Mon, 9 Aug 2010 05:26:14 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Aug 2010 08:26:47 -0400 Date: Mon, 09 Aug 2010 08:27:23 -0400 Message-Id: <87d3tsc6ok.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D027CC9CC@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <874ofbff0d.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D027CC9CC@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 09 Aug 2010 12:26:48.0120 (UTC) FILETIME=[23078380:01CB37BE] Cc: roll@ietf.org Subject: Re: [Roll] RPL hop-by-hop and source route X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 12:26:15 -0000 > Date: Mon, 9 Aug 2010 11:25:14 +0200 > From: "Pascal Thubert (pthubert)" > > The RPL option in HbH hdr serves not only as loop > avoidance but also as an error detection mechanism. If > you do not use it, Rank errors will not be detected, and > the root cannot be updated with DAO that fix its view of > the network. Pascal, Detecting a rank error with a source-routed packet doesn't mean that there is a rank error in the DODAG, or even that the root has outdated information. The root may have received new information after sending the packet, or it may have created the source route using other data or a different algorithm. I don't think we should require that the root precisely echo back the routing data it receives in DAOs. > That view of the network is per instance. Why? Why restrict the source routes in this way? -Richard Kelsey From pthubert@cisco.com Mon Aug 9 06:48:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7FB3E3A6AD7 for ; Mon, 9 Aug 2010 06:48:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.466 X-Spam-Level: X-Spam-Status: No, score=-10.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXuHw0FR+Lq2 for ; Mon, 9 Aug 2010 06:48:28 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 439CD3A68ED for ; Mon, 9 Aug 2010 06:48:28 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACukX0xAZnwN/2dsb2JhbACDFZxGanGmcYlSkTWBJoMhcwSMCYc+ X-IronPort-AV: E=Sophos;i="4.55,343,1278288000"; d="scan'208";a="145433766" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2010 13:49:02 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o79Dn0BC002253; Mon, 9 Aug 2010 13:49:02 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Aug 2010 15:49:00 +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, 9 Aug 2010 15:48:58 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D027CCB25@XMB-AMS-107.cisco.com> In-Reply-To: <1797480010.363793.1281109184907.JavaMail.root@mail02.pantherlink.uwm.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: does an RH4 header or an RPLoption in HbH header imply a data packet? thread-index: Acs1faRrNyoppZawTzi/hPdfe/BpPwCR673g References: <1797480010.363793.1281109184907.JavaMail.root@mail02.pantherlink.uwm.edu> From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "Jonathan Hui" X-OriginalArrivalTime: 09 Aug 2010 13:49:00.0898 (UTC) FILETIME=[9F31B420:01CB37C9] Cc: roll Subject: Re: [Roll] does an RH4 header or an RPLoption in HbH header imply a data packet? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 13:48:30 -0000 SGkgTXVrdWw6DQoNClRoaXMgaXMgbm90IGEgbWF0dGVyIG9mIGNvbnRyb2wgb3IgZGF0YSBwbGFu ZS4gVGhlIEhiSC9SSCBoZWxwIGFuIGFyYml0cmFyeSBwYWNrZXQgZ2V0IHRvIGRlc3RpbmF0aW9u IG92ZXIgbXVsdGlwbGUgaG9wcyBpbiB0aGUgUlBMIG5ldHdvcmsuDQpXaXRoIFJQTC0xMSwgb25s eSB0aGUgbXVsdGlob3AgREFPL0RBT19BY2sgdXNlZCBpbiBub24tc3RvcmluZyBuZWVkcyB0aG9z ZSBoZWFkZXJzLCBzaW5jZSBhbGwgb3RoZXIgUlBMIGNvbnRyb2wgbWVzc2FnZXMgYXJlIDEgaG9w IGxpbmsgbG9jYWwuDQoNCkNoZWVycywNCg0KUGFzY2FsDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBNdWt1bCBHb3lhbCBbbWFpbHRvOm11a3VsQHV3bS5lZHVdDQo+ IFNlbnQ6IEZyaWRheSwgQXVndXN0IDA2LCAyMDEwIDU6NDAgUE0NCj4gVG86IEpvbmF0aGFuIEh1 aQ0KPiBDYzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KTsgcm9sbA0KPiBTdWJqZWN0OiBkb2Vz IGFuIFJINCBoZWFkZXIgb3IgYW4gUlBMb3B0aW9uIGluIEhiSCBoZWFkZXIgaW1wbHkgYSBkYXRh DQo+IHBhY2tldD8NCj4gDQo+IEhpIGFsbCwNCj4gDQo+IEkgbmVlZCBhIGJpdCBvZiBoZWxwLg0K PiANCj4gTXkgaW1wcmVzc2lvbiBpcyB0aGF0IHRoZSBwcmVzZW5jZSBvZiBhbiBSSDQgc291cmNl IHJvdXRlIGhlYWRlciBvciBhbiBSUEwNCj4gb3B0aW9uIGluIElQdjYgaG9wLWJ5LWhvcCBoZWFk ZXIgaW1wbHkgdGhhdCB0aGUgcGFja2V0IGlzIGEgZGF0YSBwYWNrZXQgYW5kIG5vdA0KPiBhbiBS UEwgY29udHJvbCBwYWNrZXQuIFNvLCBpZiBJIHdhbnQgdGhlIFJQTCBwcm9jZXNzIGluIGEgcm91 dGVyIHRvIHByb2Nlc3MgYQ0KPiBwYWNrZXQsIEkgc2hvdWxkIG5vdCB1c2UgYW4gUkg0IGhlYWRl ciBvciBhbiBJUHY2IGhvcC1ieS1ob3AgaGVhZGVyIGluIHRoYXQNCj4gcGFja2V0Lg0KPiANCj4g UGxlYXNlIGxldCBtZSBrbm93IGlmIHRoaXMgaXMgbm90IGNvcnJlY3QuDQo+IA0KPiBUaGFua3MN Cj4gTXVrdWwNCg== From prvs=830aacfb9=mukul@uwm.edu Mon Aug 9 06:55:13 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D87F63A686B for ; Mon, 9 Aug 2010 06:55:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.185 X-Spam-Level: X-Spam-Status: No, score=-3.185 tagged_above=-999 required=5 tests=[AWL=-0.586, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d0fkIEa3mscK for ; Mon, 9 Aug 2010 06:55:12 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id D02B13A67FB for ; Mon, 9 Aug 2010 06:55:12 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 09 Aug 2010 08:55:46 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 6C6502B3F06; Mon, 9 Aug 2010 08:55:21 -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 T1vA3axBZo+F; Mon, 9 Aug 2010 08:55:20 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id BC6F62B3F05; Mon, 9 Aug 2010 08:55:20 -0500 (CDT) Date: Mon, 9 Aug 2010 08:55:45 -0500 (CDT) From: Mukul Goyal To: "Pascal Thubert (pthubert)" Message-ID: <1286817750.401414.1281362145324.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D027CCB25@XMB-AMS-107.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] does an RH4 header or an RPLoption in HbH header imply a data packet? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 13:55:13 -0000 Thanks Pascal. I understand it now. The P2P-01 was wrongly using RH4 header to steer packets that needed hop-by-hop processing. I have corrected this error in P2P-02. Thanks Mukul ----- Original Message ----- From: "Pascal Thubert (pthubert)" To: "Mukul Goyal" , "Jonathan Hui" Cc: "roll" Sent: Monday, August 9, 2010 8:48:58 AM Subject: RE: does an RH4 header or an RPLoption in HbH header imply a data packet? Hi Mukul: This is not a matter of control or data plane. The HbH/RH help an arbitrary packet get to destination over multiple hops in the RPL network. With RPL-11, only the multihop DAO/DAO_Ack used in non-storing needs those headers, since all other RPL control messages are 1 hop link local. Cheers, Pascal > -----Original Message----- > From: Mukul Goyal [mailto:mukul@uwm.edu] > Sent: Friday, August 06, 2010 5:40 PM > To: Jonathan Hui > Cc: Pascal Thubert (pthubert); roll > Subject: does an RH4 header or an RPLoption in HbH header imply a data > packet? > > Hi all, > > I need a bit of help. > > My impression is that the presence of an RH4 source route header or an RPL > option in IPv6 hop-by-hop header imply that the packet is a data packet and not > an RPL control packet. So, if I want the RPL process in a router to process a > packet, I should not use an RH4 header or an IPv6 hop-by-hop header in that > packet. > > Please let me know if this is not correct. > > Thanks > Mukul From pthubert@cisco.com Mon Aug 9 07:16:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B46F63A635F for ; Mon, 9 Aug 2010 07:16:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7yv+UAJ8hf9D for ; Mon, 9 Aug 2010 07:16:55 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id AC2123A6AEE for ; Mon, 9 Aug 2010 07:16:52 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADyrX0xAZnwN/2dsb2JhbACgRXGnKZsThToEjAk X-IronPort-AV: E=Sophos;i="4.55,343,1278288000"; d="scan'208";a="145449314" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 09 Aug 2010 14:17:26 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o79EHQcW014744; Mon, 9 Aug 2010 14:17:26 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 9 Aug 2010 16:17:25 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 9 Aug 2010 16:17:21 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D027CCB4B@XMB-AMS-107.cisco.com> In-Reply-To: <87d3tsc6ok.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL hop-by-hop and source route thread-index: Acs3vjdN7n7HJCwXTi+7oD9/swxHHAADaeNQ References: <874ofbff0d.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D027CC9CC@XMB-AMS-107.cisco.com> <87d3tsc6ok.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 09 Aug 2010 14:17:25.0998 (UTC) FILETIME=[978350E0:01CB37CD] Cc: roll@ietf.org Subject: Re: [Roll] RPL hop-by-hop and source route X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 14:16:56 -0000 Hi Richard > > > > The RPL option in HbH hdr serves not only as loop avoidance but also > > as an error detection mechanism. If you do not use it, Rank errors > > will not be detected, and the root cannot be updated with DAO that fix > > its view of the network. >=20 > Pascal, >=20 > Detecting a rank error with a source-routed packet doesn't mean that there is a > rank error in the DODAG, or even that the root has outdated information. The > root may have received new information after sending the packet, or it may > have created the source route using other data or a different algorithm. I don't > think we should require that the root precisely echo back the routing data it > receives in DAOs. [Pascal] Agreed. This is very classical to ICMP errors in general that are throttled.=20 If the node receives a source routed packet from a supposed parent that actually has a higher Rank, this means that at the time of the generation of the routing header, the root had a perception of the network that is now obsolete >=20 > > That view of the network is per instance. >=20 > Why? Why restrict the source routes in this way? =20 [Pascal] Mostly the same answer as in storing mode. If a root could (source) route over mixed instances, it'd lose the benefits of the constraints. Even in storing, a strict hierarchy of instances could have allowed a packet to switch instances in a loopless fashion, but the group decided not to go there. Please do not ask me to defend that position, I was in the other camp : ) Pascal >=20 > -Richard Kelsey From pal@cs.stanford.edu Mon Aug 9 09:49:00 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB88C3A6B04; Mon, 9 Aug 2010 09:49:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y8aXxs07Ej0q; Mon, 9 Aug 2010 09:48:59 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id C05AB3A6836; Mon, 9 Aug 2010 09:48:59 -0700 (PDT) Received: from dn0a2101f9.sunet ([10.33.1.249]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OiVXZ-0001GH-Js; Mon, 09 Aug 2010 09:49:34 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> Date: Mon, 9 Aug 2010 08:59:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1081) X-Scan-Signature: f219e97bb238ccbb8ed40879dafdba3c Cc: Carsten Bormann , roll@ietf.org, ipv6@ietf.org Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 16:49:01 -0000 On Aug 9, 2010, at 3:17 AM, Pascal Thubert (pthubert) wrote: > Hi Michael: >=20 > With http://tools.ietf.org/html/draft-ietf-roll-rpl-07#section-7.2 I > tried to stay within the lines of RFC 3697 as you also defend in your > mail.=20 >=20 > I think the question we have now is not whether that proposal is = lawful > but whether the new law being defined at 6MAN would prevent it in the > future. > If the updated rules allow, then I'll be glad to work on an FL-based > alternate to the IPinIP/HbH.=20 >=20 > It appeared at the 6MAN WG meeting that 12 bits mutable was exactly = what > the core network was asking for to do its load balancing. > A first question to the group could be whether 12 mutable bits are > enough for the sensible usages envisioned so far? My 2c: In the case of the hop-by-hop header, 12 bits is clearly enough for an = 8-bit RPLInstanceId, but clearly not enough for a 16-bit Rank. I think = that trying to compress them (especially Rank) would be a mistake, whose = complexity would far outweigh the benefits.=20 Phil From gnawali@cs.stanford.edu Mon Aug 9 17:06:37 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A10C63A69DF for ; Mon, 9 Aug 2010 17:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.422 X-Spam-Level: X-Spam-Status: No, score=-4.422 tagged_above=-999 required=5 tests=[AWL=-0.904, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id urIx47wfOCYt for ; Mon, 9 Aug 2010 17:06:36 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id A1DD93A69EA for ; Mon, 9 Aug 2010 17:06:36 -0700 (PDT) Received: from mail-iw0-f174.google.com ([209.85.214.174]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1OicN4-00062r-R5 for roll@ietf.org; Mon, 09 Aug 2010 17:07:11 -0700 Received: by iwn33 with SMTP id 33so3952293iwn.19 for ; Mon, 09 Aug 2010 17:07:10 -0700 (PDT) Received: by 10.231.170.21 with SMTP id b21mr19786194ibz.122.1281398830206; Mon, 09 Aug 2010 17:07:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.144.199 with HTTP; Mon, 9 Aug 2010 17:06:50 -0700 (PDT) In-Reply-To: <76DBCE2AA6605F42A49F1BD7454C841BEB0B69@usatlsv105.am.bm.net> References: <2c24b2655735dd40afffafac5a0db04d@mail.gmail.com> <76DBCE2AA6605F42A49F1BD7454C841BEB0B69@usatlsv105.am.bm.net> From: Omprakash Gnawali Date: Mon, 9 Aug 2010 17:06:50 -0700 Message-ID: To: "Monnerie, Emmanuel" Content-Type: text/plain; charset=ISO-8859-1 X-Scan-Signature: fff7235990e19ba309b2ccff5b27b3b9 Cc: roll@ietf.org Subject: Re: [Roll] questions about ETX (was: question on gain control) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 00:06:37 -0000 These are excellent comments about ETX. Without thinking about them carefully we can run into problems when we use ETX for routing. However, from what I remember from the metrics draft discussion, the WG decided to not prescribe a particular way of computing ETX. JP is probably the best person to tell us if this is still the position of the WG. - om_p On Wed, Jul 28, 2010 at 6:55 AM, Monnerie, Emmanuel wrote: > That is correct. It is problematic to use SNR as a link quality > indicator. Computing a SNR is not an easy matter, particularly when it > has to be computed by a low cost and low power device. A SNR is the > ratio of the received signal power of a good packet over the average > noise power. When a link is bad, the device will not have many good > packets to choose from to measure the signal power and therefore the > statistics can be very inaccurately computed. > > I think that ETX or PRR are better metrics in general. But I have a > similar question regarding the definition of the ETX metric (cf: > draft-gnawali-roll-etxof-01). I think it is missing some parameters to > be complete: Which packet transmission is used to compute this > statistic? How long is the packet? > > My point is that the ETX value will depend on the length of the packet. > The standard should either define a baseline packet length to compute > this value or the definition of the ETX should be expanded to allow a > normalization of this value, based on the length of the packets. > > Another question is: which ETX value should be used by default, when a > device discovers a new link? Should it be Infinity, until the statistics > are computed or should it be a more reasonable value (like 1 , 2 or 3)? > Depending on which decision is made, the system behavior can change > quite a bit. > > Any suggestion? > > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Philip Levis > Sent: Tuesday, July 27, 2010 6:48 PM > To: Yoav Ben-Yehezkel > Cc: roll@ietf.org > Subject: Re: [Roll] question on gain control > > (...) > >> Actually using variable transmission power to infer link quality and > stability is problematic: it can be a link has >> high SNR but low PRR (e.g., due to external interference). > >>Phil > > > > > Emmanuel Monnerie > Senior Research Engineer > Landis+Gyr > Energy Management Solutions > Office: +1 678 258 1695 > Fax: +1 678 258 1316 > Emmanuel.Monnerie@landisgyr.com > www.landisgyr.com > manage energy better > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From pthubert@cisco.com Tue Aug 10 04:54:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BF64C3A686C for ; Tue, 10 Aug 2010 04:54:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.471 X-Spam-Level: X-Spam-Status: No, score=-10.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osrNcfTFhn2S for ; Tue, 10 Aug 2010 04:54:35 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BFD923A6405 for ; Tue, 10 Aug 2010 04:54:34 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALbaYExAZnwN/2dsb2JhbACgVnGmS5tWhToEjAiHPg X-IronPort-AV: E=Sophos;i="4.55,348,1278288000"; d="scan'208";a="145889318" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 10 Aug 2010 11:55:01 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7ABspT8001778; Tue, 10 Aug 2010 11:54:57 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Aug 2010 13:54:53 +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: Tue, 10 Aug 2010 13:54:48 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D027CCDAB@XMB-AMS-107.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rank in HbH / FL thread-index: Acs4gtQdA0qrcjk0SeuXQCXAtL8wAw== From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 10 Aug 2010 11:54:53.0889 (UTC) FILETIME=[D878CB10:01CB3882] Cc: roll@ietf.org Subject: [Roll] Rank in HbH / FL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 11:54:35 -0000 Hi Phil: The use of the Rank in forwarding path is to differentiate up from down. Only the floor(Rank) is needed, and that floor() can be made one octet or less even for metrics that we rank in 2 octets. The proposal is not to compress but simply to pass the useful information as opposed to the waste we are currently observing in all packets. Note: Same floor means siblings, which the group selected not to use, upon your suggestion. Pascal > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Monday, August 09, 2010 5:59 PM > To: Pascal Thubert (pthubert) > Cc: Michael Richardson; roll@ietf.org; Carsten Bormann; ipv6@ietf.org > Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable >=20 >=20 > On Aug 9, 2010, at 3:17 AM, Pascal Thubert (pthubert) wrote: >=20 > > Hi Michael: > > > > With http://tools.ietf.org/html/draft-ietf-roll-rpl-07#section-7.2 I > > tried to stay within the lines of RFC 3697 as you also defend in your > > mail. > > > > I think the question we have now is not whether that proposal is lawful > > but whether the new law being defined at 6MAN would prevent it in the > > future. > > If the updated rules allow, then I'll be glad to work on an FL-based > > alternate to the IPinIP/HbH. > > > > It appeared at the 6MAN WG meeting that 12 bits mutable was exactly what > > the core network was asking for to do its load balancing. > > A first question to the group could be whether 12 mutable bits are > > enough for the sensible usages envisioned so far? >=20 > My 2c: >=20 > In the case of the hop-by-hop header, 12 bits is clearly enough for an 8-bit > RPLInstanceId, but clearly not enough for a 16-bit Rank. I think that trying to > compress them (especially Rank) would be a mistake, whose complexity would > far outweigh the benefits. >=20 > Phil From richard.kelsey@ember.com Tue Aug 10 05:41:39 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD7C3A68BC for ; Tue, 10 Aug 2010 05:41:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.396 X-Spam-Level: X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7-EQ0Z9t3qno for ; Tue, 10 Aug 2010 05:41:38 -0700 (PDT) Received: from EMPIRE.hq.ember.com (mail.ember.com [74.10.175.227]) by core3.amsl.com (Postfix) with ESMTP id 2C45C3A67C2 for ; Tue, 10 Aug 2010 05:41:38 -0700 (PDT) Received: from kelsey-ws.hq.ember.com ([192.168.81.37]) by EMPIRE.hq.ember.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Aug 2010 08:42:12 -0400 Date: Tue, 10 Aug 2010 08:42:49 -0400 Message-Id: <877hjyd4fq.fsf@kelsey-ws.hq.ember.com> To: "Pascal Thubert (pthubert)" In-reply-to: <6A2A459175DABE4BB11DE2026AA50A5D027CCB4B@XMB-AMS-107.cisco.com> (pthubert@cisco.com) From: Richard Kelsey References: <874ofbff0d.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D027CC9CC@XMB-AMS-107.cisco.com> <87d3tsc6ok.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCB4B@XMB-AMS-107.cisco.com> X-OriginalArrivalTime: 10 Aug 2010 12:42:12.0395 (UTC) FILETIME=[745A6FB0:01CB3889] Cc: roll@ietf.org Subject: Re: [Roll] RPL hop-by-hop and source route X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 12:41:39 -0000 > Date: Mon, 9 Aug 2010 16:17:21 +0200 > From: "Pascal Thubert (pthubert)" > > > > That view of the network is per instance. > > > > Why? Why restrict the source routes in this way? > > [Pascal] Mostly the same answer as in storing mode. If a root could > (source) route over mixed instances, it'd lose the benefits of the > constraints. Yes, but that is a choice that the root can make. Why should we make that decision for it? > Even in storing, a strict hierarchy of instances could have > allowed a packet to switch instances in a loopless fashion, but the > group decided not to go there. Please do not ask me to defend that > position, I was in the other camp : ) Routing upwards using the DODAG is a completely different issue. The source route forwarding is distinct from RPL and it seems wrong for RPL to put constraints on it. -Richard Kelsey From mcr@sandelman.ca Tue Aug 10 05:56:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03AE3A6821; Tue, 10 Aug 2010 05:56:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=0.405, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJLhta3YYRoe; Tue, 10 Aug 2010 05:56:27 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 58BC73A659C; Tue, 10 Aug 2010 05:56:27 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id BE1EB346A5; Tue, 10 Aug 2010 08:57:01 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 5CE7098A6E; Tue, 10 Aug 2010 08:57:00 -0400 (EDT) From: Michael Richardson To: Brian E Carpenter In-Reply-To: <4C609233.8030207@gmail.com> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 10 Aug 2010 08:57:00 -0400 Message-ID: <23319.1281445020@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Carsten Bormann , ipv6@ietf.org, roll@ietf.org Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 12:56:28 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Brian" == Brian E Carpenter writes: >> With >> http://tools.ietf.org/html/draft-ietf-roll-rpl-07#section-7.2 I >> tried to stay within the lines of RFC 3697 as you also defend in >> your mail. >> >> I think the question we have now is not whether that proposal is >> lawful but whether the new law being defined at 6MAN would >> prevent it in the future. If the updated rules allow, then I'll >> be glad to work on an FL-based alternate to the IPinIP/HbH. Brian> So I understand that ROLL would definitely need the ability Brian> to define explicit semantics on the label. Would it also need Brian> the label to be mutable? The only case where there is a problem is when there is a packet that arrives from the outside, to a ROLL "border router" (we don't have such a term in ROLL. The ROLL term would be grounded DODAG root). The problem would be if: a) the flow label was non-zero. b) the flow label named a RPLinstanceID which did exist. c) the originating IP was not permitted to use that instanceID d) yet we wanted traffic to continue. In that case, we have a problem and we might want to set the flow-label to zero. I think this situation is simply illegal, and I think the culprit is part (d). As I indicated in a previous message, the above could happen when there were two ROLL networks connected together by the "internet" (lower-case I intentional, this doesn't have to be the public Internet, but it does have to cross administrative boundaries of some kind), and one needed flow-label A to exit network 1, and flow-label B to enter network 2. ("needed" --- only that flow label would name the right RPLinstance, which had the correct set of routing constraints) >> It appeared at the 6MAN WG meeting that 12 bits mutable was >> exactly what the core network was asking for to do its load >> balancing. A first question to the group could be whether 12 >> mutable bits are enough for the sensible usages envisioned so >> far? Brian> To me it seems that 12 bits could contain enough randomness Brian> to drive a load balancing mechanism, but there's no need for Brian> those bits to be mutable that I can see. On the other hand, Brian> 12 bits seems very small for any kind of nonce or for a flow Brian> identification scheme, so it seems that draft-blake and Brian> draft-donley would be knocked out. ROLL is sees the label/RPLinstanceID as being an opaque number with no specific properties. We actually punt to the administrator to even define/configure it. I doubt that many ROLL networks will have as many as 2^8 instances, let alone 2^12 instances. The rational for lots of bits would be to encourage random allocation such that in the event that two uncoordinated ROLL networks happened to merge (even for a few minutes!!!) that the likelyhood of cross talk would be reduced. A merge like I describe here is not directly envisaged by the current set of requirements in my opinion, but I think that requirement will emerge in the future. - -- ] 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Finger me for keys iQEVAwUBTGFMmoCLcPvd0N1lAQJz7gf/Uaa3xF+O9u5AeUxOrg/s3ehvb0z2AyTo /OWqRH+yYnsgJV79KintI25Hv6upIWdGDECxQzv1nSNaXEyQl76s/y7NQkjGB9Uy 3e1RXbFdY54fRj0ElsQw5PbieYqNo0in28bcbWYkfZdqALi7HXSlBHHmoADlB4hh tvR6qFJJfIw3L4bYCtSoD75NLEzrZXrSBTdFsH/KDdiUUYQVM214+mRS9V1ymXwK Jn+uIpEvyD+fK4iAyDG29lSAONrF4HaS+LmLRJI98lwHgMejiaxvkRAI6sQCHaQ8 tBW2o475fbVr++di19BmOEf7ohPEHmN5La6M2hxfMq8G6r2gZK/gJg== =yMdQ -----END PGP SIGNATURE----- From pthubert@cisco.com Tue Aug 10 06:33:52 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6AD583A691A; Tue, 10 Aug 2010 06:33:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.472 X-Spam-Level: X-Spam-Status: No, score=-10.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hGgi0W8ToVjd; Tue, 10 Aug 2010 06:33:47 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 83FCD3A6864; Tue, 10 Aug 2010 06:33:40 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EACbyYExAZnwM/2dsb2JhbACDFZxYanGnMIlSgzGOTIEmgVWBTHMEjAg X-IronPort-AV: E=Sophos;i="4.55,348,1278288000"; d="scan'208";a="145921591" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 10 Aug 2010 13:34:15 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7ADYEqS025776; Tue, 10 Aug 2010 13:34:15 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Aug 2010 15:34:14 +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, 10 Aug 2010 15:34:07 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> In-Reply-To: <4C609233.8030207@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow Label: 12 bits mutable and 8 bits immutable thread-index: Acs4HG5rIVBQRFbOQGajJMoOYnOIGAAbA+Og References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> From: "Pascal Thubert (pthubert)" To: "Brian E Carpenter" X-OriginalArrivalTime: 10 Aug 2010 13:34:14.0606 (UTC) FILETIME=[B95606E0:01CB3890] Cc: Carsten Bormann , roll@ietf.org, ipv6@ietf.org Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 13:33:52 -0000 SGkgQnJpYW46DQogDQo+IE9uIDIwMTAtMDgtMDkgMjI6MTcsIFBhc2NhbCBUaHViZXJ0IChwdGh1 YmVydCkgd3JvdGU6DQo+ID4gSGkgTWljaGFlbDoNCj4gPg0KPiA+IFdpdGggaHR0cDovL3Rvb2xz LmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1yb2xsLXJwbC0wNyNzZWN0aW9uLTcuMiBJDQo+ID4g dHJpZWQgdG8gc3RheSB3aXRoaW4gdGhlIGxpbmVzIG9mIFJGQyAzNjk3IGFzIHlvdSBhbHNvIGRl ZmVuZCBpbiB5b3VyDQo+ID4gbWFpbC4NCj4gPg0KPiA+IEkgdGhpbmsgdGhlIHF1ZXN0aW9uIHdl IGhhdmUgbm93IGlzIG5vdCB3aGV0aGVyIHRoYXQgcHJvcG9zYWwgaXMNCj4gPiBsYXdmdWwgYnV0 IHdoZXRoZXIgdGhlIG5ldyBsYXcgYmVpbmcgZGVmaW5lZCBhdCA2TUFOIHdvdWxkIHByZXZlbnQg aXQNCj4gPiBpbiB0aGUgZnV0dXJlLg0KPiA+IElmIHRoZSB1cGRhdGVkIHJ1bGVzIGFsbG93LCB0 aGVuIEknbGwgYmUgZ2xhZCB0byB3b3JrIG9uIGFuIEZMLWJhc2VkDQo+ID4gYWx0ZXJuYXRlIHRv IHRoZSBJUGluSVAvSGJILg0KPiANCj4gU28gSSB1bmRlcnN0YW5kIHRoYXQgUk9MTCB3b3VsZCBk ZWZpbml0ZWx5IG5lZWQgdGhlIGFiaWxpdHkgdG8gZGVmaW5lIGV4cGxpY2l0DQo+IHNlbWFudGlj cyBvbiB0aGUgbGFiZWwuIFdvdWxkIGl0IGFsc28gbmVlZCB0aGUgbGFiZWwgdG8gYmUgbXV0YWJs ZT8NCj4gDQoNCltQYXNjYWxdIFRoZSBGTCBiYXNlZCBwcm9wb3NhbCBmb3IgUlBMIHVzZXMgMTIg bXV0YWJsZSBiaXRzLiANCg0KVGhleSBhcmUgdXNlZCBhcyBhbiBpbi1iYW5kIGNvbnRyb2wgcGxh bmUgdGhhdCBjaGVja3MgdGhlIGNvbnNpc3RlbmN5IG9mIHJvdXRpbmcgc3RhdGVzIGFsb25nIGEg cGF0aC4gVGhvc2Ugc3RhdGVzIGNhbiBlYXNpbHkgZ2V0IG91dCBvZiBzeW5jIGR1ZSB0byB0aGUg bmF0dXJlIG9mIHRoZSBsaW5rcywgYnV0IHRoZSBtYWludGVuYW5jZSBjYW4gYmUgY29zdGx5LiBX ZSB3YW50IHRvIGFjY2VsZXJhdGUgdGhlIHJlcGFpcnMgb24gdGhvc2UgbGlua3MgdGhhdCBhcmUg YWN0dWFsbHkgdXNlZCB3aGVuIGFuIGluY29uc2lzdGVuY3kgaXMgZGV0ZWN0ZWQgdGhhdCB3aWxs IGltcGFjdCB0aGUgZGVsaXZlcnkuDQoNClJQTCBhbHNvIGJ1aWxkcyBtdWx0aXBsZSB0b3BvbG9n aWVzICh2aXJ0dWFsIG5ldHdvcmtzIGlkZW50aWZpZWQgYnkgYW4gaW5zdGFuY2VJRCkgdG8gYWRk cmVzcyB2YXJpb3VzIGNvbnN0cmFpbnRzLCBpbiB0ZXJtcyB0aGF0IGNhbiBiZSBzdWNoIGFzIG1l dHJpY3MgYnV0IGFsc28gYWRtaW5pc3RyYXRpdmUuIEUuZy4gYSBwb3dlciB1dGlsaXR5IENvbW1h bmQgJiBDb250cm9sIG5ldHdvcmsgYXQgaG9tZSB3aWxsIGhhdmUgYSBzcGVjaWZpYyBJRCB0aGF0 J3MgZGlmZmVyZW50IGZyb20gdGhlIGRlZmF1bHQgZ2VuZXJhbCBwdXJwb3NlIG9uZSwgc28gdGhl IHBvd2VyIHJlbGF0ZWQgdHJhZmZpYyBlbmRzIHVwIGF0IHRoZSBwb3dlciB1dGlsaXR5IEdXIGFs b25nIGEgc3BlY2lmaWMgZ3JhcGguIA0KDQpBbiBvcGFxdWUgaW5zdGFuY2VJRCBmb3IgdGhlIHRv cG9sb2d5IGNhbiBiZSBrbm93biBieSB0aGUgZW5kIHBvaW50cy4gVGhlIGluc3RhbmNlSUQgaXMg bm90IG5lY2Vzc2FyaWx5IHJlbGF0ZWQgdG8gUW9TIGFuZCBkb2VzIG5vdCBtYXAgdG8gYSBwZXIg aG9wIGJlaGF2aW9yLCBidXQgaW4gb3VyIGNhc2UsIHRvIGFjdHMgbW9yZSBsaWtlIEwzIC4xUSB0 YWcuIFRoZSBGbG93IExhYmVsIGlzIHRoZSBvbmx5IGZpZWxkIGF2YWlsYWJsZSBmb3IgYW4gYXBw bGljYXRpb24gdG8gcGFzcyBzdWNoIGluZm9ybWF0aW9uIHRvIHRoZSBuZXR3b3JrLiBUaHVzIHRo ZSBub24tbXV0YWJsZSA4IGJpdHMgaW4gdGhlIHByb3Bvc2FsLiANCg0KPiA+DQo+ID4gSXQgYXBw ZWFyZWQgYXQgdGhlIDZNQU4gV0cgbWVldGluZyB0aGF0IDEyIGJpdHMgbXV0YWJsZSB3YXMgZXhh Y3RseQ0KPiA+IHdoYXQgdGhlIGNvcmUgbmV0d29yayB3YXMgYXNraW5nIGZvciB0byBkbyBpdHMg bG9hZCBiYWxhbmNpbmcuDQo+ID4gQSBmaXJzdCBxdWVzdGlvbiB0byB0aGUgZ3JvdXAgY291bGQg YmUgd2hldGhlciAxMiBtdXRhYmxlIGJpdHMgYXJlDQo+ID4gZW5vdWdoIGZvciB0aGUgc2Vuc2li bGUgdXNhZ2VzIGVudmlzaW9uZWQgc28gZmFyPw0KPiANCj4gVG8gbWUgaXQgc2VlbXMgdGhhdCAx MiBiaXRzIGNvdWxkIGNvbnRhaW4gZW5vdWdoIHJhbmRvbW5lc3MgdG8gZHJpdmUgYSBsb2FkDQo+ IGJhbGFuY2luZyBtZWNoYW5pc20sIGJ1dCB0aGVyZSdzIG5vIG5lZWQgZm9yIHRob3NlIGJpdHMg dG8gYmUgbXV0YWJsZSB0aGF0IEkNCj4gY2FuIHNlZS4gT24gdGhlIG90aGVyIGhhbmQsIDEyIGJp dHMgc2VlbXMgdmVyeSBzbWFsbCBmb3IgYW55IGtpbmQgb2Ygbm9uY2Ugb3INCj4gZm9yIGEgZmxv dyBpZGVudGlmaWNhdGlvbiBzY2hlbWUsIHNvIGl0IHNlZW1zIHRoYXQgZHJhZnQtYmxha2UgYW5k IGRyYWZ0LWRvbmxleQ0KPiB3b3VsZCBiZSBrbm9ja2VkIG91dC4NCg0KSSdtIHVuc3VyZSB3aHkg ZHJhZnRfZG9ubGV5IGRvZXMgbm90IGNvcHkgdGhlIElQdjQgVE9TIEJ5dGUgaW4gdGhlIElQdjYg VHJhZmZpYyBDbGFzcyBPY3RldCwgaWYgZGlmZmVyZW50aWF0ZWQgc2VydmljZSBpcyB3aGF0IHRo ZSBkcmFmdCBpcyBhZnRlci4gDQpJbiBhbnkgY2FzZSwgaXQgYXBwZWFycyB0aGF0IHRoZSBuZWVk IGlzIG5vdCByZWFsbHkgZm9yIGEgZmxvdyBidXQgZm9yIGEgZmxvdyB0eXBlLCBpbiB3aGljaCBj YXNlIDggbm9uIG11dGFibGUgYml0cyBhcmUgZW5vdWdoLg0KDQpJJ20gYWxzbyB1bnN1cmUgd2h5 IGRyYWZ0IGJsYWtlIGNhbiBiZSBwcmVmZXJyZWQgb3ZlciBzeW4gY29va2llcywgYnV0IGlmIGl0 IGlzLCB0aGVuLCBvYnZpb3VzbHkgdGhlIG1vcmUgYml0cyB0aGUgYmV0dGVyLiBTdGlsbCwgdGhp cyBub25jZSBpcyBub3QgdXNlZCBieSB0aGUgbmV0d29yaywgc28gdGhlIG5ldHdvcmsgaGVhZGVy IHNob3VsZCBub3QgYmUgZW5jdW1iZXJlZCBieSBpdC4gSWYgeW91IGxvb2sgYXQgaXQsIGEgc2lt aWxhciBwcm9ibGVtIGFwcGVhcnMgd2hlbiBhIG5vZGUgcmVjZWl2ZXMgYSBwYWNrZXQgYmFjayBp biBhbiBJQ01QIGVycm9yLCBpbiB3aGljaCBjYXNlIGl0IHdvdWxkIGJlIHNhZmUgdG8gbWFrZSBz dXJlIHRoYXQgdGhlIG5vZGUgcmVhbGx5IGlzc3VlZCB0aGF0IHBhY2tldCBpbiB0aGUgZmlyc3Qg cGxhY2UsIG90aGVyd2lzZSBhY3Rpb25zIHRha2VuIHVwb24gdGhlIElDTVAgY291bGQgYmUgbWlz dXNlZCBieSBhbiBhdHRhY2tlciBmcm9tIGFueXdoZXJlIGluIHRoZSBJbnRlcm5ldC4uIElmIHdl IHRha2UgdGhlIHBhdGggb2YgYSBub25jZSwgSSdkIGZhdm9yIGEgbmV3ICJzb3VyY2Ugb3B0aW9u IiB3aXRoIHNlbWFudGljcyBieSB3aGljaCB0aGUgbmV0d29yayBpcyBub3QgY29uY2VybmVkIHdp dGggdGhlIGhlYWRlciBhbmQgIHRoYXQgd291bGQgZW5hYmxlIHRoZSBzb3VyY2UgdG8gcGxhY2Ug aXRzIG93biBpbmZvcm1hdGlvbiBzdWNoIGFzIHRoaXMgbm9uY2UuDQoNClRoYW5rcyBhIGJ1bmNo IGZvciB5b3VyIGhlbHAsDQoNClBhc2NhbA0KDQo+ICAgIEJyaWFuDQo+IA0KPiA+DQo+ID4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IGlwdjYtYm91bmNlc0BpZXRmLm9y ZyBbbWFpbHRvOmlwdjYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+ID4gT2YNCj4gPj4g TWljaGFlbCBSaWNoYXJkc29uDQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgQXVndXN0IDA0LCAyMDEw IDQ6MDUgQU0NCj4gPj4gVG86IHJvbGxAaWV0Zi5vcmc7IENhcnN0ZW4gQm9ybWFubg0KPiA+PiBD YzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KTsgaXB2NkBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0 OiBSZTogRmxvdyBMYWJlbDogMTIgYml0cyBtdXRhYmxlIGFuZCA4IGJpdHMgaW1tdXRhYmxlDQo+ ID4+DQo+ID4+DQo+ID4+IHt0aGVyZSBpcyBhIHRocmVhZCB3aGljaCBzdGFydGVkIG9uIHJvbGxA aWV0Zi5vcmcsIGFuZCBpcHY2QGlldGYub3JnLA0KPiA+IGFuZCB0aGVuDQo+ID4+IHNlZW1lZCB0 byBoYXZlIGRyb3BwZWQgcm9sbEBpZXRmLm9yZy4gSSdtIG5vdCBvbiBpcHY2QGlldGYub3JnLCBz bw0KPiA+IHRoZXJlIGxpa2VseQ0KPiA+PiBhcmUgbWVzc2FnZSB0aGVyZSBJJ3ZlIG1pc3NlZH0N Cj4gPj4NCj4gPj4gb2theSwgc28gSSd2ZSByZWFkIENhcnNlbidzIG9waW5pb24uDQo+ID4+IEkg cmVhZCBSRkMgMzY5NyAod2hpY2ggSSBkaWRuJ3Qga25vdyBhYm91dCkuDQo+ID4+DQo+ID4+IGRy YWZ0LWh1LWZsb3ctbGFiZWwtY2FzZXMtMDAgaXMgYSB2ZXJ5IGdvb2QgcmVhZC4gIEkgcHVsbCBv dXQNCj4gPiBzb21ldGhpbmcgZnJvbQ0KPiA+PiBzZWN0aW9uIDQgKERpc2N1c3Npb24pOw0KPiA+ Pg0KPiA+PiAgICBUaGUgb3RoZXIgY2hvaWNlLCBmb3IgZGVzaWduZXJzIHdobyB3aXNoIHRvIHVz ZSB0aGUgZmxvdyBsYWJlbCB0bw0KPiA+PiAgICBjb250cm9sIHN3aXRjaGluZyBvciBRb1MgZGly ZWN0bHksIGlzIHRvIGJ5cGFzcyB0aGUgcnVsZXMgd2l0aGluIGENCj4gPj4gICAgZ2l2ZW4gZG9t YWluIChhIHNldCBvZiBjb29wZXJhdGluZyBub2RlcykgaW4gYSB3YXkgdGhhdCBub2Rlcw0KPiA+ IG91dHNpZGUNCj4gPj4gICAgdGhlIGRvbWFpbiBjYW5ub3QgZGV0ZWN0LiAgSW4gdGhpcyBjYXNl LCBhbnkgZGV2aWF0aW9uIGZyb20NCj4gPiBbUkZDMzY5N10NCj4gPj4gICAgaGFzIG5vIHBvc3Np YmxlIGVmZmVjdCBvdXRzaWRlIHRoZSBkb21haW4gaW4gcXVlc3Rpb24uDQo+ID4+DQo+ID4+IEkg ZG9uJ3Qga25vdyB3aGVyZSB0aGlzIHN1YmplY3QgbGluZSBpcyBmcm9tOiAxMiBiaXRzLzhiaXRz Lg0KPiA+PiBJcyB0aGVyZSBhIGRyYWZ0IHRoYXQgZXhwbGFpbnMgdGhhdCBpZGVhIHRoYXQgSSd2 ZSBtaXNzZWQ/DQo+ID4+DQo+ID4+IE15IGNsYWltIGlzIHRoYXQgUk9MTCdzIFJQTCBpcyBhIHNl dCBvZiBjb29wZXJhdGluZyBub2Rlcy4NCj4gPj4NCj4gPj4gQnV0LCBpdCdzIGJldHRlciB0aGFu IHRoYXQgLS0tIGl0J3MgYSBzZXQgb2Ygcm91dGVycyB3aGljaCBhcmUgdHVuZWQNCj4gPiB0byBz dXBwb3J0DQo+ID4+IHNwZWNpZmljIGFwcGxpY2F0aW9ucywgYW5kIHRoZSBhcHBsaWNhdGlvbnMg d2FudCBpbiB0aGlzIGNhc2UgdG8gYmUNCj4gPiBnaXZlbg0KPiA+PiBpbmZvcm1hdGlvbiBsaWtl LCAid2hhdCBmbG93IGxhYmVsIiB0byB1c2UuICBSUEwncyBSUExpbnN0YW5jZUlEIGhhcw0KPiA+ IGFsbCB0aGUNCj4gPj4gcHJvcGVydGllcyByZXF1aXJlZCBvZiBhIGZsb3cgbGFiZWwgKG9yLCBy YXRoZXIsIGl0IGhhcyBubw0KPiA+IHJlcXVpcmVtZW50cyBwcmVzZW50bHksDQo+ID4+IGFuZCB0 aGVyZWZvcmUgY2FuIGhhdmUgdGhlIGZsb3cgbGFiZWwgcmVxdWlyZW1lbnRzIGltcG9zZWQgdXBv biBpdCwNCj4gPj4gc3BlY2lmaWNhbGx5Og0KPiA+PiAgICAyLiAgIk5vZGVzIE1VU1QgTk9UIGFz c3VtZSBhbnkgbWF0aGVtYXRpY2FsIG9yIG90aGVyIHByb3BlcnRpZXMgb2YNCj4gPj4gICAgICAg IHRoZSBGbG93IExhYmVsIg0KPiA+PiApDQo+ID4+DQo+ID4+IFRoZSBub24tbXV0YWJpbGl0eSBv ZiB0aGUgbGFiZWwgaXNuJ3QgYSBwcm9ibGVtIGVpdGhlciAtLS0gdGhlDQo+ID4gYXBwbGljYXRp b25zICpBVA0KPiA+PiBFQUNIIEVORCosIGV2ZW4gaWYgb25lIGVuZCBvZiB0aGUgYXBwbGljYXRp b24gaXMgc2V2ZXJhbCBBUydzIGF3YXkgKGENCj4gPiB2ZXJ5DQo+ID4+IHVudXN1YWwgY2FzZSBm b3IgOTUlIG9mIFJQTCdzIHRhcmdldCB1c2UpLCB0aGF0IGFwcGxpY2F0aW9uIHN0aWxsDQo+ID4g bmVlZHMgdG8ga25vdw0KPiA+PiBzb21ldGhpbmcgYWJvdXQgd2hhdCBsYWJlbCB0byB1c2UuDQo+ ID4+DQo+ID4+IFRoZXJlIGFyZSB0aHJlZSBjYXNlcyB0byBjb25zaWRlcjoNCj4gPj4gICAgICAg YSkgdHJhZmZpYyBiZXR3ZWVuIHR3byBSUEwgbm9kZXMNCj4gPj4gICAgICAgYikgdHJhZmZpYyBl eGl0aW5nIGFuIFJQTA0KPiA+PiAgICAgICBjKSB0cmFmZmljIGVudGVyaW5nIGFuIFJQTA0KPiA+ Pg0KPiA+PiBjYXNlIChhKSAtLSBpcyB0aGUgInNldCBvZiBjb29wZXJhdGluZyBub2RlcyIsIGFu ZCB0aGVyZWZvcmUgaXMgbm8NCj4gPiBwcm9ibGVtLg0KPiA+PiBjYXNlIChiKSAtLSB0aGUgZmxv dyBsYWJlbCBpcyBzZXQgdG8gZ2V0IHRocm91Z2ggdGhlIFJQTC9MTE4sIGFuZCBvdXQNCj4gPiB0 bw0KPiA+PiAgICAgICAgICAgICB0aGUgbmV0d29yaywgYW5kIHRoZSBmbG93IGxhYmVsIGhhcyBk b25lIGl0J3Mgam9iLCBhbmQNCj4gPj4gICAgICAgICAgICAgdGhlIFJQTC9MTE4gbmV0d29yayBj b3VsZCBjYXJlIGxlc3Mgd2hhdCBoYXBwZW5zIHRvIHRoZQ0KPiA+IGZsb3cNCj4gPj4gICAgICAg ICAgICAgbGFiZWwgYXQgdGhhdCBwb2ludC4gICBUaGUgcmVzdCBvZiB0aGUgbmV0d29yayBtaWdo dCBoYXZlDQo+ID4gYQ0KPiA+PiAgICAgICAgICAgICBwcm9ibGVtIChpLmUuIGEgYnVnKSB3aGVu IFJQTCBuZXR3b3JrcyBzdGFydCBzZW5kaW5nDQo+ID4+ICAgICAgICAgICAgIG5vbi16ZXJvICBm bG93IGxhYmVscywgYnV0IHRoYXQncyB0aGUgcmVzdCBvZiB0aGUNCj4gPiBuZXR3b3JrJ3MNCj4g Pj4gICAgICAgICAgICAgcHJvYmxlbS4NCj4gPj4NCj4gPj4gY2FzZSAoYykgLSBmbG93IGxhYmVs cyBvZiB6ZXJvIGFyZSBub3QgYSBwcm9ibGVtLiAgVGhlcmUgaXMgZWl0aGVyIGENCj4gPj4gICAg ICAgICAgZGVmYXVsdCBSUExpbnN0YW5jZUlEIHRvIHVzZSAoYW5kIHRyYWZmaWMgZmxvd3MsIHBl cmhhcHMgbm90DQo+ID4+ICAgICAgICAgIG9wdGltYWxseSksIG9yIHRoZXJlIGlzbid0IChhbmQg SUNNUCBIb3N0IHVucmVhY2hhYmxlDQo+ID4gb2NjdXJzKS4NCj4gPj4gICAgICAgICAgLSBub24t emVybyBmbG93IGxhYmVscyB3aGljaCBkbyBub3QgbWFwIHRvIGFuIFJQTGluc3RhbmNlSUQsDQo+ ID4+ICAgICAgICAgICAgYXJlIHNpbXBseSBjb25zaWRlcmVkIHplcm8sIHNlZSBhYm92ZS4NCj4g Pj4gICAgICAgICAgLSBub24temVybyBmbG93IGxhYmVscyB3aGljaCBtYXAgdG8gUlBMaW5zdGFu Y2VJRHMgYXJlIHVzZWQuDQo+ID4+ICAgICAgICAgICAgKklmKiBpdCBpcyBhIHByb2JsZW0gZm9y IG91dHNpZGVycyB0byBpbnZva2UgdGhhdCBMTE4ncw0KPiA+PiAgICAgICAgICAgIERPREFHLCB0 aGVuIHRoZXJlIGFyZSBiaWdnZXIgaXNzdWVzLCB3aGljaCB0aGUgZmxvdyBsYWJlbA0KPiA+IGNh biBuZWl0aGVyDQo+ID4+ICAgICAgICAgICAgaGVscCBub3IgaGluZGVyIC0tLSB0aGUgZmxvd2xh YmVsIGlzIG5vdCBhIG1hZ2ljIHNlY3VyaXR5DQo+ID4gY29va2llLg0KPiA+PiAgICAgICAgICAg IEEgZmlyZXdhbGwgbWF5IHN0aWxsIGJlIHJlcXVpcmVkLg0KPiA+Pg0KPiA+PiBUaGUgb25seSBy ZWFsIHByb2JsZW0gSSBjYW4gc2VlIGlzIHdoZW4gYSBwYWNrZXQgbmVlZHMgdG8gZG8gKGIpIGFu ZA0KPiA+PiAoYykuICAgZS5nLiB1c2UgbGFiZWwgQSB0byBleGl0IExMTiBhbHBoYSwgYW5kIGxh YmVsIEIgdG8gZW50ZXIgTExODQo+ID4gYmV0YS4NCj4gPj4gSSBkb24ndCBoYXZlIGEgc29sdXRp b24gdG8gdGhpcy4gIFNvbWUgaGF2ZSBzdWdnZXN0ZWQgSVBJUCB0dW5uZWxzLA0KPiA+IHdoaWNo IHNvdW5kDQo+ID4+IG5pY2UgaW4gdGhlb3J5LCBidXQgaW4gcHJhY3RpY2UgZG8gbm90IHdvcmsg aW4gdGhlIHdpbGRlcm5lc3MgZm91bmQNCj4gPiBiZWhpbmQgdGhlDQo+ID4+IHdhbGxzIG9mIHdh bGxlZCBnYXJkZW5zLg0KPiA+Pg0KPiA+PiAtLQ0KPiA+PiBdICAgICAgIEhlIHdobyBpcyB0aXJl ZCBvZiBXZWlyZCBBbCBpcyB0aXJlZCBvZiBsaWZlISAgICAgICAgICAgfA0KPiA+IGZpcmV3YWxs cyAgWw0KPiA+PiBdICAgTWljaGFlbCBSaWNoYXJkc29uLCBTYW5kZWxtYW4gU29mdHdhcmUgV29y a3MsIE90dGF3YSwgT04gICAgfG5ldA0KPiA+PiBhcmNoaXRlY3RbDQo+ID4+IF0gbWNyQHNhbmRl bG1hbi5vdHRhd2Eub24uY2EgaHR0cDovL3d3dy5zYW5kZWxtYW4ub3R0YXdhLm9uLmNhLw0KPiA+ IHxkZXZpY2UNCj4gPj4gZHJpdmVyWw0KPiA+PiAgICBLeW90byBQbHVzOiB3YXRjaCB0aGUgdmlk ZW8NCj4gPj4gPGh0dHA6Ly93d3cueW91dHViZS5jb20vd2F0Y2g/dj1rengxeWNMWFFTRT4NCj4g Pj4gCSAgICAgICAgICAgICAgIHRoZW4gc2lnbiB0aGUgcGV0aXRpb24uDQo+ID4+DQo+ID4+DQo+ ID4+DQo+ID4+DQo+ID4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4+IElFVEYgSVB2NiB3b3JraW5nIGdyb3Vw IG1haWxpbmcgbGlzdA0KPiA+PiBpcHY2QGlldGYub3JnDQo+ID4+IEFkbWluaXN0cmF0aXZlIFJl cXVlc3RzOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lwdjYNCj4gPj4g LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IElFVEYgSVB2NiB3b3JraW5nIGdyb3Vw IG1haWxpbmcgbGlzdA0KPiA+IGlwdjZAaWV0Zi5vcmcNCj4gPiBBZG1pbmlzdHJhdGl2ZSBSZXF1 ZXN0czogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pcHY2DQo+ID4gLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gPg0K From pthubert@cisco.com Tue Aug 10 07:24:13 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7CB53A6843; Tue, 10 Aug 2010 07:24:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.324 X-Spam-Level: X-Spam-Status: No, score=-10.324 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGVlE0azlWB3; Tue, 10 Aug 2010 07:24:12 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id DCCA93A6934; Tue, 10 Aug 2010 07:24:11 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKP9YEyrRN+K/2dsb2JhbACgV3GnfI0DjkyCe4I/BIwI X-IronPort-AV: E=Sophos;i="4.55,348,1278288000"; d="scan'208";a="238273537" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-5.cisco.com with ESMTP; 10 Aug 2010 14:24:47 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o7AEOkCi020020; Tue, 10 Aug 2010 14:24:46 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Aug 2010 16:24:45 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Aug 2010 16:24:42 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D027CCE7B@XMB-AMS-107.cisco.com> In-Reply-To: <48421D4F-0E73-4192-88EA-D7C6672768F5@free.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow Label: 12 bits mutable and 8 bits immutable thread-index: Acs3uQSDw+IdBcU/TEm79myLaXk9+wA3g8cQ References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <48421D4F-0E73-4192-88EA-D7C6672768F5@free.fr> From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-OriginalArrivalTime: 10 Aug 2010 14:24:45.0891 (UTC) FILETIME=[C81F6930:01CB3897] Cc: Carsten Bormann , roll@ietf.org, 6man 6man Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 14:24:14 -0000 Salut R=E9mi, Please see below: Pascal > -----Original Message----- > From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] > Sent: Monday, August 09, 2010 1:50 PM > To: Pascal Thubert (pthubert) > Cc: 6man 6man; Michael Richardson; roll@ietf.org; Carsten Bormann > Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable >=20 >=20 > Le 9 ao=FBt 2010 =E0 12:17, Pascal Thubert (pthubert) a =E9crit : >=20 > > Hi Michael: > > > > With http://tools.ietf.org/html/draft-ietf-roll-rpl-07#section-7.2 I > > tried to stay within the lines of RFC 3697 as you also defend in = your > > mail. > > > > I think the question we have now is not whether that proposal is > > lawful but whether the new law being defined at 6MAN would prevent = it > > in the future. > > If the updated rules allow, then I'll be glad to work on an FL-based > > alternate to the IPinIP/HbH. > > > > It appeared at the 6MAN WG meeting that 12 bits mutable was exactly > > what the core network was asking for to do its load balancing. >=20 > Would you have more details on WHY it would be "exactly" what was = needed > (???) ? [Pascal] That does not come from me. I asked at the mike during the WG = meeting, and the answer that was given was that for the purpose of a = load balancing hash in the SP network, 11 or 12 bits would be enough. > > A first question to the group could be whether 12 mutable bits are > > enough for the sensible usages envisioned so far? >=20 > I'd rather see the first question as being "Are there some = improvements of RFC > 3697 that would make it practicable?". >=20 > If yes, improving this RFC rather than deprecating it after 6+ years = of standard- > track existence would IMHO be better for IPv6 credibility (and IMHO = for that of > IETF in general). >=20 > The two improvements that seem to make sense (see various exchanged = mails) > are: > - permit stateless support (with flow-ID hashes in place of flow-based = stateful > processing) > - permit intermediate nodes to set FLs when source hosts haven't done = it (still > as shorthands for flow ISs made available in IPv6 first headers). >=20 [Pascal] We agree here. The point if that there might be enough room for = both, depending on what we are doing. Note that for the latter, the discussion was also that it is not obvious = at the egress of the network to reset the FL to zero in order to enable = the next AS to reuse it. So the conclusion was rather to use the bits is = a DSCP fashion. Pascal > > > > > >> -----Original Message----- > >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = Behalf > > Of > >> Michael Richardson > >> Sent: Wednesday, August 04, 2010 4:05 AM > >> To: roll@ietf.org; Carsten Bormann > >> Cc: Pascal Thubert (pthubert); ipv6@ietf.org > >> Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable > >> > >> > >> {there is a thread which started on roll@ietf.org, and = ipv6@ietf.org, > > and then > >> seemed to have dropped roll@ietf.org. I'm not on ipv6@ietf.org, so > > there likely > >> are message there I've missed} > >> > >> okay, so I've read Carsen's opinion. > >> I read RFC 3697 (which I didn't know about). > >> > >> draft-hu-flow-label-cases-00 is a very good read. I pull out > > something from > >> section 4 (Discussion); > >> > >> The other choice, for designers who wish to use the flow label to > >> control switching or QoS directly, is to bypass the rules within = a > >> given domain (a set of cooperating nodes) in a way that nodes > > outside > >> the domain cannot detect. In this case, any deviation from > > [RFC3697] > >> has no possible effect outside the domain in question. > >> > >> I don't know where this subject line is from: 12 bits/8bits. > >> Is there a draft that explains that idea that I've missed? > >> > >> My claim is that ROLL's RPL is a set of cooperating nodes. > >> > >> But, it's better than that --- it's a set of routers which are = tuned > > to support > >> specific applications, and the applications want in this case to be > > given > >> information like, "what flow label" to use. RPL's RPLinstanceID = has > > all the > >> properties required of a flow label (or, rather, it has no > > requirements presently, > >> and therefore can have the flow label requirements imposed upon it, > >> specifically: > >> 2. "Nodes MUST NOT assume any mathematical or other properties = of > >> the Flow Label" > >> ) > >> > >> The non-mutability of the label isn't a problem either --- the > > applications *AT > >> EACH END*, even if one end of the application is several AS's away = (a > > very > >> unusual case for 95% of RPL's target use), that application still > > needs to know > >> something about what label to use. > >> > >> There are three cases to consider: > >> a) traffic between two RPL nodes > >> b) traffic exiting an RPL > >> c) traffic entering an RPL > >> > >> case (a) -- is the "set of cooperating nodes", and therefore is no > > problem. > >> > >> case (b) -- the flow label is set to get through the RPL/LLN, and = out > > to > >> the network, and the flow label has done it's job, and > >> the RPL/LLN network could care less what happens to the > > flow > >> label at that point. The rest of the network might = have > > a > >> problem (i.e. a bug) when RPL networks start sending > >> non-zero flow labels, but that's the rest of the > > network's > >> problem. > >> > >> case (c) - flow labels of zero are not a problem. There is either = a > >> default RPLinstanceID to use (and traffic flows, perhaps = not > >> optimally), or there isn't (and ICMP Host unreachable > > occurs). > >> > >> - non-zero flow labels which do not map to an = RPLinstanceID, > >> are simply considered zero, see above. > >> - non-zero flow labels which map to RPLinstanceIDs are = used. > >> *If* it is a problem for outsiders to invoke that LLN's > >> DODAG, then there are bigger issues, which the flow label > > can neither > >> help nor hinder --- the flowlabel is not a magic security > > cookie. > >> A firewall may still be required. > >> > >> The only real problem I can see is when a packet needs to do (b) = and > >> (c). e.g. use label A to exit LLN alpha, and label B to enter LLN > > beta. > >> > >> I don't have a solution to this. Some have suggested IPIP tunnels, > > which sound > >> nice in theory, but in practice do not work in the wilderness found > > behind the > >> walls of walled gardens. > >> > >> -- > >> ] 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. > >> > >> > >> > >> > >> = -------------------------------------------------------------------- > >> IETF IPv6 working group mailing list > >> ipv6@ietf.org > >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > >> = -------------------------------------------------------------------- > > -------------------------------------------------------------------- > > IETF IPv6 working group mailing list > > ipv6@ietf.org > > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > > -------------------------------------------------------------------- >=20 From mcr@sandelman.ca Tue Aug 10 07:27:07 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D6D23A6934; Tue, 10 Aug 2010 07:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yfo+GkUpqKTv; Tue, 10 Aug 2010 07:27:06 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id DFF713A6915; Tue, 10 Aug 2010 07:27:05 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id B491534455; Tue, 10 Aug 2010 10:27:40 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 4A19698A6E; Tue, 10 Aug 2010 10:27:39 -0400 (EDT) From: Michael Richardson To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 10 Aug 2010 10:27:39 -0400 Message-ID: <26885.1281450459@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Carsten Bormann , roll@ietf.org, ipv6@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 14:27:07 -0000 >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: >> On 2010-08-09 22:17, Pascal Thubert (pthubert) wrote: > Hi >> Michael: >> > >> > With >> http://tools.ietf.org/html/draft-ietf-roll-rpl-07#section-7.2 I > >> tried to stay within the lines of RFC 3697 as you also defend in >> your > mail. >> > >> > I think the question we have now is not whether that proposal >> is > lawful but whether the new law being defined at 6MAN would >> prevent it > in the future. > If the updated rules allow, then >> I'll be glad to work on an FL-based > alternate to the >> IPinIP/HbH. >> >> So I understand that ROLL would definitely need the ability to >> define explicit semantics on the label. Would it also need the >> label to be mutable? >> Pascal> [Pascal] The FL based proposal for RPL uses 12 mutable bits. Pascal> They are used as an in-band control plane that checks the Pascal> consistency of routing states along a path. Those states can Pascal> easily get out of sync due to the nature of the links, but Pascal> the maintenance can be costly. We want to accelerate the Pascal> repairs on those links that are actually used when an Pascal> inconsistency is detected that will impact the delivery. I don't understand how the FL helps us on this! Probably I missed something important. What you write below was my entire understanding of our need for an in-band tag. Pascal> RPL also builds multiple topologies (virtual networks Pascal> identified by an instanceID) to address various constraints, Pascal> in terms that can be such as metrics but also Pascal> administrative. E.g. a power utility Command & Control Pascal> network at home will have a specific ID that's different Pascal> from the default general purpose one, so the power related Pascal> traffic ends up at the power utility GW along a specific Pascal> graph. Pascal> An opaque instanceID for the topology can be known by the Pascal> end points. The instanceID is not necessarily related to QoS Pascal> and does not map to a per hop behavior, but in our case, to Pascal> acts more like L3 .1Q tag. The Flow Label is the only field Pascal> available for an application to pass such information to the Pascal> network. Thus the non-mutable 8 bits in the proposal. +1 -- ] 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 Tue Aug 10 08:20:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EED03A68C1; Tue, 10 Aug 2010 08:20:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.623 X-Spam-Level: X-Spam-Status: No, score=-1.623 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6oE+ZMUza-eY; Tue, 10 Aug 2010 08:20:40 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id E8B083A6887; Tue, 10 Aug 2010 08:20:39 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 42BEE343F2; Tue, 10 Aug 2010 11:21:14 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 371BF98A6E; Tue, 10 Aug 2010 11:21:13 -0400 (EDT) From: Michael Richardson To: "Joel M. Halpern" In-Reply-To: <4C616315.2060301@joelhalpern.com> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <23319.1281445020@marajade.sandelman.ca> <4C616315.2060301@joelhalpern.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 10 Aug 2010 11:21:13 -0400 Message-ID: <31515.1281453673@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org, 6man 6man Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 15:20:41 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Joel" == Joel M Halpern writes: Joel> Off-list, although you may decide that my confusion is wider, and take it Joel> back to the list: okay, I think it's worthwhile. Joel> When a ROLL network is talking to the rest of the world, using IPv6, it would Joel> seem that packets can arrive with Joel> a) a non-zero flow label Joel> b) which happened to be an extant RPLinstanceID Joel> c) and apparently the sender, since it is outside of ROLL, is not permitted Joel> to use that instanceID Joel> d) but we clearly want the traffic to continue Joel> WHhy is this at all unlikely? Are you counting on not having Joel> collisions between values in a 20 bit field? It simply isn't Joel> big enough for that to be a safe assumption. I think that (d) is unlikely. That is, random nodes on the network, not only will not have a reason to talk to the light bulb in my living room, but also won't be permitted to do so. (If it's actually me at the random IP, then likely I'll come through an IPsec tunnel...) I'm not saying that this will apply to *ALL* ROLL deployments, but to the majority of them that are envisaged today. (In fact, the things I want to deploy likely will suffer from this more than the average will) In particular, the commodity situation where some node on my network decides to do an HTTP request to commodity site FOO, and the packets in question here are replies to my request. I do not know how the reply flow labels will be set, but if it will be simply echoed by TCP passive opens, then in fact, (c) might not apply. That is, the node will have permission to use that instanceID. It's not because the node is outside of the ROLL that it can not use the instanceID. It's just that nodes outside the ROLL won't know much about the instanceIDs, if the applications running on them have not been configured properly. That is, my network device used instanceID XYZ to send the request out, and it is appropriate for replies to also use XYZ. There might even be a stateful firewall opening a pinhole on the ACL for instanceID XYZ. If it should come that it is accepable for an intermediate node to reset the FL to zero, that would solve the problem for incoming packets. I guess, I'd rather we allocate well known FL=1 (or 0b1111...) to indicate, "has been reset" rather than "was never set", I'd be happier. If it is permissible for a "firewall" to drop packets with non-zero FLs, then that might also solve the problem. I'd hate to see that in any kind of commodity system: I've had it with "secure" banks that can not speak ECN, or that have broken PMTU. - -- ] 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Finger me for keys iQEVAwUBTGFuZ4CLcPvd0N1lAQKZHQf/dEAJLQkwFLXDUAaDPLU0bzw4GoMb6xzw ILymBmJKBLUJ88LwGDLCC5XNwn2ayY9EB/wE/N6yt5l6e9mijDhiHAaNQAVMMlxs ktqEx048ANVbG6QtRYsCmJyjWmoutG5jYBYfIuDJBle5vHsKApb7msH+I24C3jRs AyaTJfom7isFTLo/Eua0a5t7OORdbNB61aRmqqDwJ4g0gCjJlxOaPJhAglm/j3lV W24SshuJy+M0Zglzu7XbYqobcaA0//jJBe3nMpLTUJyVuT8+vdQ9m7lbblUI2YKZ YHfWIkVzbWGxBoe7J9SiFu0vR56g88pCEBXuYiXkkTeiWMQpHDiL8g== =0kD/ -----END PGP SIGNATURE----- From mcr@sandelman.ca Tue Aug 10 09:08:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B03583A6A03; Tue, 10 Aug 2010 09:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.65 X-Spam-Level: X-Spam-Status: No, score=-1.65 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ESJzPlCfpM8f; Tue, 10 Aug 2010 09:08:53 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 9D0493A6A01; Tue, 10 Aug 2010 09:08:53 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 14BB334632; Tue, 10 Aug 2010 12:09:28 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id C695C98A6E; Tue, 10 Aug 2010 12:09:26 -0400 (EDT) From: Michael Richardson To: =?us-ascii?Q?=3D=3Fiso-8859-1=3FQ=3FR=3DE9mi=5FDespr=3DE9s=3F=3D?= In-Reply-To: <097F191C-3E28-48E3-AAAF-81730D2A49FD@free.fr> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <48421D4F-0E73-4192-88EA-D7C6672768F5@free.fr> <6A2A459175DABE4BB11DE2026AA50A5D027CCE7B@XMB-AMS-107.cisco.com> <097F191C-3E28-48E3-AAAF-81730D2A49FD@free.fr> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Aug 2010 12:09:26 -0400 Message-ID: <987.1281456566@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Carsten Bormann , 6man 6man , roll@ietf.org Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 16:08:54 -0000 >>>>> "R=E9mi" =3D=3D R=E9mi Despr=E9s writes: R=E9mi> RFC 3697 isn't concerned with ASes, and doesn't need to be. R=E9mi> The proposal is only that, where load balancing is performed,=20 R=E9mi> 0 FLs MAY be replaced by meaningful values for this purpose.=20= =20=20 R=E9mi> A FL, once set to a non 0 value, never needs to be reset. okay, so what you are saying is that load balancing uses of the FL are only upset when they see zero. So for instance, if layer-4s (i.e. end points) were mandated that they must now always set a FL consistently on a flow, and set it to a non-zero value, that this would satisfy the requirements of load balancers. In this context, permission would be given to set zero FL to a non-zero value.=20 --=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 From mcr@sandelman.ca Tue Aug 10 09:27:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 895B13A6A8B; Tue, 10 Aug 2010 09:27:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.674 X-Spam-Level: X-Spam-Status: No, score=-1.674 tagged_above=-999 required=5 tests=[AWL=0.280, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7DGLoEavW1R; Tue, 10 Aug 2010 09:27:33 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 46E9F3A6A1A; Tue, 10 Aug 2010 09:27:33 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 7465A34602; Tue, 10 Aug 2010 12:28:08 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 3C66598A6E; Tue, 10 Aug 2010 12:28:07 -0400 (EDT) From: Michael Richardson To: Carsten Bormann In-Reply-To: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <23319.1281445020@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 10 Aug 2010 12:28:07 -0400 Message-ID: <1723.1281457687@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org, ipv6@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 16:27:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Carsten" == Carsten Bormann writes: Carsten> On Aug 10, 2010, at 14:57, Michael Richardson wrote: >> The only case where there is a problem is when there is a packet that >> arrives from the outside, to a ROLL "border router" (we don't have such >> a term in ROLL. The ROLL term would be grounded DODAG root). Carsten> I haven't yet quite found out whether RPL tries to be Carsten> useful for networks with hosts, but if it does, the same Carsten> kind if problem would occur when a host sets the flow Carsten> label. RPL networks consists of leafs and routers. Both typically act as hosts. Routers are just hosts that happen to be between other nodes. (Although, some hosts are too weak to be routers) Little to no traffic on the RPL is unaware of which RPLinstanceID to use, because the applications there needs to send using a specific set of constraints, which is encapsulated into the RPLinstanceID. For ignorant applications, the OS may well be able to set the instanceID. In other cases, an instanceID of zero may be most correct. There may be some cases where there are ordinary hosts which are on a network which is not RPL, but is connected to an RPL network. (The group does not have any consensus if these will be layer-2 bridged, or layer-3 routed yet). In these cases the application either will be aware, or won't care. - -- ] 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Finger me for keys iQEVAwUBTGF+FoCLcPvd0N1lAQIg3wgAvbvI14OA+2U55Yvq+rfJCLkxWArxDz1r ehRUog5MQSVmx4u0QKz71g4PhKLIUTrVmf/8rffSLGjaw7VrEjPR6yNSNO4FFBcY jTx/ShrN2e51SNTL0w0tg7qU8JdJs9wfVifGTcNmEg4IfWePXG802EUiq8liPInU WCbKMEflZ9W5PMRbsELxV7uGTi24QL+Eb8bs9xYpeFKd08RKaxho0dfBGikYZNDt 1oDrHxAKd7WCn0z2mhE/GLuexn29axO0GGJn6uKsYa2obSL9vm0CiRt4cw6xNsIa ye+OiN4rEJ2nNi7FaGAD3OqNnU8SSZserrhdQK577l33cu3PwrMYOw== =HL+W -----END PGP SIGNATURE----- From pal@cs.stanford.edu Tue Aug 10 09:54:10 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F25513A698D for ; Tue, 10 Aug 2010 09:54:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.422 X-Spam-Level: X-Spam-Status: No, score=-6.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1rlS+KCpaFl for ; Tue, 10 Aug 2010 09:54:09 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 2CE0E3A68F3 for ; Tue, 10 Aug 2010 09:54:09 -0700 (PDT) Received: from dn0a21021b.sunet ([10.33.2.27]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Ois68-00065O-3S; Tue, 10 Aug 2010 09:54:44 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D027CCDAB@XMB-AMS-107.cisco.com> Date: Tue, 10 Aug 2010 09:54:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6A2A459175DABE4BB11DE2026AA50A5D027CCDAB@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 6b0537b5faa14548adc1759647fcb4de Cc: roll@ietf.org Subject: Re: [Roll] Rank in HbH / FL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 16:54:10 -0000 On Aug 10, 2010, at 4:54 AM, Pascal Thubert (pthubert) wrote: > Hi Phil: >=20 > The use of the Rank in forwarding path is to differentiate up from = down. > Only the floor(Rank) is needed, and that floor() can be made one octet > or less even for metrics that we rank in 2 octets. > The proposal is not to compress but simply to pass the useful > information as opposed to the waste we are currently observing in all > packets. > Note: Same floor means siblings, which the group selected not to use, > upon your suggestion. Pascal, I understand what the goal is; I'm questioning whether it's technically = feasible. This works in some cases, but not all. E.g. if you use the entire 12 = bits to represent Rank but MinHopRankIncrease is < 16 (0x10), then you = cannot compress Rank properly. If you want to use fewer than 12 bits, = then the constraint becomes tighter. For some metric->Rank conversions, where the dynamic range is relatively = small, such as ETX, then this constraint might be possible to satisfy. = But there are some metric->Rank conversions, such as latency, where the = dynamic range can be very high. Yes, floor() *can* be made one octet in some cases. That does not mean = it can be done so in all cases. Otherwise we have specified that = MinHopRankIncrease is always >=3D 256.=20 Phil= From pal@cs.stanford.edu Tue Aug 10 10:28:36 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 183603A6A8A; Tue, 10 Aug 2010 10:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.433 X-Spam-Level: X-Spam-Status: No, score=-6.433 tagged_above=-999 required=5 tests=[AWL=0.166, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alCynepkL47e; Tue, 10 Aug 2010 10:28:35 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 0C4BD3A6951; Tue, 10 Aug 2010 10:28:35 -0700 (PDT) Received: from dn0a21021b.sunet ([10.33.2.27]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OisdS-00042i-6g; Tue, 10 Aug 2010 10:29:10 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <1723.1281457687@marajade.sandelman.ca> Date: Tue, 10 Aug 2010 10:29:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <81F72C20-12D3-48D6-968F-A4407DF140C8@cs.stanford.edu> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <23319.1281445020@marajade.sandelman.ca> <1723.1281457687@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1081) X-Scan-Signature: b05cf9a5276a81ca133e41a937654b06 Cc: Carsten Bormann , roll@ietf.org, ipv6@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 17:28:36 -0000 On Aug 10, 2010, at 9:28 AM, Michael Richardson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 >>>>>> "Carsten" =3D=3D Carsten Bormann writes: > Carsten> On Aug 10, 2010, at 14:57, Michael Richardson wrote: >=20 >>> The only case where there is a problem is when there is a packet = that >>> arrives from the outside, to a ROLL "border router" (we don't have = such >>> a term in ROLL. The ROLL term would be grounded DODAG root). >=20 > Carsten> I haven't yet quite found out whether RPL tries to be > Carsten> useful for networks with hosts, but if it does, the same > Carsten> kind if problem would occur when a host sets the flow > Carsten> label.=20 ... >=20 > For ignorant applications, the OS may well be able to set the > instanceID. In other cases, an instanceID of zero may be most = correct. >=20 > There may be some cases where there are ordinary hosts which are on a > network which is not RPL, but is connected to an RPL network.=20 > (The group does not have any consensus if these will be layer-2 = bridged, > or layer-3 routed yet). In these cases the application either will be > aware, or won't care. I feel like we're running in circles, in part due to different = expectations of how RPL will be used. It's clear that in proprietary or vertically integrated networks running = RPL, it's possible to state how controllers/other nodes set the flow = label in order to play nice with RPL. E.g., if my home automation = network receives commands from a special device (which itself might have = a web/SOAP/etc. interface), then that special device can set the flow = label. This isn't the problem case. The problem case for the use of the flow label is when arbitrary = Internet hosts (e.g., my laptop) want to communicate with devices = running RPL. E.g., I have a home RPL network and want to directly talk = to a RPL device from my laptop. Requiring the packet source to be aware = of flow labels and how to set them breaks the whole idea of Internet = connectivity: suddenly an end host needs to be aware of what routing = protocol is used to reach the other host, as well as configuration = parameters of that host. I need to be able to SSH to the RPL-connected = device without requiring a new ssh program that uses ioctls to set flow = labels. We can't say that only OSes which set the flow label to 0 (or = some other value) can be used. Nor can we expect to change how OSes set = the flow label. So the problem is that a packet originating from outside the RPL = network, destined to a RPL node, may have an arbitrary flow label. The = RPL border router needs to handle the packet in an effective way. = Whatever solution we come up with needs to handle this effectively if = the Internet is going to support connectivity to LLN devices. It's = critical that the solution not make assumptions about how the flow = labels are set or what the behavior of the non-RPL end host is. We want = Windows, Linux, OS X, Windows Mobile, Android, Symbian, and other = current Internet devices to be able to talk with LLNs. Phil= From jpv@cisco.com Tue Aug 10 11:27:50 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAA083A6A8D for ; Tue, 10 Aug 2010 11:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.469 X-Spam-Level: X-Spam-Status: No, score=-110.469 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yXtOobDXtnoF for ; Tue, 10 Aug 2010 11:27:49 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 5C1E93A69A1 for ; Tue, 10 Aug 2010 11:27:49 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJc2YUyrR7Ht/2dsb2JhbACgLHGhXJtShToEiUCCVYdB X-IronPort-AV: E=Sophos;i="4.55,349,1278288000"; d="scan'208,217";a="571444660" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 10 Aug 2010 18:28:24 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7AISNBV007386; Tue, 10 Aug 2010 18:28:23 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Aug 2010 20:28:23 +0200 Received: from [10.98.96.115] ([10.61.96.103]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 10 Aug 2010 20:28:18 +0200 Message-Id: <37491E99-36D8-4287-B2FA-FBC38EE79AE1@cisco.com> From: JP Vasseur To: ROLL WG , Tzeta Tsao , Roger Alexander , David Ward , Philip Levis In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-101-361884454 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 10 Aug 2010 20:17:58 +0200 References: <1A214829-24F0-47EB-80F0-964135888009@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 10 Aug 2010 18:28:19.0783 (UTC) FILETIME=[CEAE5D70:01CB38B9] Subject: [Roll] ROLL Security Design Team can be dissolved X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 18:27:50 -0000 --Apple-Mail-101-361884454 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, The ROLL Security Design Team has reached all of its Milestones and can now be dissolved. I would like to warmly thank the ROLL security DT members for the hard work produced over the last few months. Thanks. JP and David. On Jan 25, 2010, at 11:22 PM, JP Vasseur wrote: > Dear all, > > This is to announce the formation of a new RPL Security Design Team, > made of the following members: > * Tzeta Tsao > * Roger Alexander > * Dave Ward > * Phil Levis > > Thanks to the four of you for volunteering. > > Rene Struik will help the team as our security advisor. > > As a reminder: > > * The work produced by a Design Team has no special status in the WG > and is subject to WG consensus as any other individual submission > * We ask the Design Team to request for input from the WG and to > provide regular updates on the progress: please send input requests > to the mailing list, post regular updates of the document to get a > chance to everybody to comment, ... > * All: please provide input to the Design Team and copy the mailing > list. > > Charter > ###### > > The charter of the security design team is to produce a Security > Framework document and the potential routing security extensions to > RPL in the context of that framework (or document how existing > routing mechanisms should be used). With regards to the framework, > the Security DT may choose to use http://www.ietf.org/id/draft-tsao-roll-security-framework-01.txt > as a starting point (the document has been presented and discussed > at the last two Working Group meetings). > > Please make sure to be aligned with the ROLL terminology document > and provide input to their authors should new terms be introduced. > > Milestones > ######### > > Milestones are pretty aggressive. > > Feb 10: produce a first draft of Security Framework to be submitted > to the WG for WG adoption > Feb 29: produce a first draft on the potential security extensions > for RPL as a separate document (that may be incorporated in the core > specification of RPL in a second step). > > The Design Team may not be dissolved after the completion of the > security work for RPL as security in routing within LLN may apply to > future specifications produced by the Working Group. > > It is strongly encouraged to produce new version as the document > progress (each time a substantial change is made to the document). > > Thanks. > > JP and David. > > On Jan 21, 2010, at 9:09 AM, JP Vasseur wrote: > >> Dear WG, >> >> I think that we can all be very happy with our progress so far with >> the core specification of RPL. There are still a few open issues >> that we need to solve before IETF-77: >> >> * Detailed DAO mechanisms >> * Detailed mode of operation with multicast >> * Use of Flow Label versus new IPv6 header >> * Potential needed optimization such as DAO packing >> * Editorial work >> * ... >> >> We are on track for all of these. >> >> The one item we absolutely need to speed on is security. As you >> know there is a security framework document that is still not a WG >> document and we now need to start the work on the RPL security >> aspects. To that end, we will form a small Design Team with >> aggressive milestones, the objective being to have the RPL security >> item almost completed by end of Feb, ready for the IETF-77. >> >> If you have a good understanding of RPL and routing security >> expertise, please go back to me (unicast). >> >> Thanks. >> >> JP. >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-101-361884454 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear = all,

The ROLL Security Design Team has = reached all of its Milestones and can now be dissolved. I would like to = warmly thank the ROLL security DT members for the hard work produced = over the last few = months. 

Thanks.

JP= and David.

On Jan 25, 2010, at 11:22 PM, JP = Vasseur wrote:

Dear all,

This is to announce the formation of = a new RPL Security Design Team, made of the following members:
* = Tzeta Tsao
* Roger Alexander
* Dave Ward
* Phil = Levis

Thanks to the four of you for volunteering.

Rene = Struik will help the team as our security advisor.

As a = reminder:

* The work produced by a Design Team has no special = status in the WG and is subject to WG consensus as any other individual = submission
* We ask the Design Team to request for input from the WG = and to provide regular updates on the progress: please send input = requests to the mailing list, post regular updates of the document to = get a chance to everybody to comment, ...
* All: please provide input = to the Design Team and copy the mailing = list.

Charter
######

The charter of the security design = team is to produce a Security Framework document and the potential = routing security extensions to RPL in the context of that framework (or = document how existing routing mechanisms should be used). With regards = to the framework, the Security DT may choose to use = http://www.ietf.org/id/draft-tsao-roll-security-framework-01.txt as = a starting point (the document has been presented and discussed at the = last two Working Group meetings).

Please make sure to be aligned = with the ROLL terminology document and provide input to their authors = should new terms be = introduced.

Milestones
#########

Milestones are pretty = aggressive.

Feb 10: produce a first draft of Security Framework = to be submitted to the WG for WG adoption
Feb 29: produce a first = draft on the potential security extensions for RPL as a separate = document (that may be incorporated in the core specification of RPL in a = second step).

The Design Team may not be dissolved after the = completion of the security work for RPL as security in routing within = LLN may apply to future specifications produced by the Working = Group.

It is strongly encouraged to produce new version as the = document progress (each time a substantial change is made to the = document).

Thanks.

JP and David.

On Jan 21, 2010, = at 9:09 AM, JP Vasseur wrote:

Dear = WG,

I think that we can all be very happy with our progress = so far with the core specification of RPL. There are still a few open = issues that we need to solve before IETF-77:

* Detailed DAO = mechanisms
* Detailed mode of = operation with multicast
* Use = of Flow Label versus new IPv6 header
* Potential needed optimization such as DAO = packing
* Editorial = work
* = ...

We are on track for all of = these.

The one item we = absolutely need to speed on is security. As you know there is a security = framework document that is still not a WG document and we now need to = start the work on the RPL security aspects. To that end, we will form a = small Design Team with aggressive milestones, the objective being to = have the RPL security item almost completed by end of Feb, ready for the = IETF-77.

If you have a = good understanding of RPL and routing security expertise, please go back = to me (unicast).

Thanks.

JP.
_______________________________________________
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-101-361884454-- From pal@cs.stanford.edu Tue Aug 10 12:13:21 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4CCB3A686D for ; Tue, 10 Aug 2010 12:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.442 X-Spam-Level: X-Spam-Status: No, score=-6.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQTwmI96qlrI for ; Tue, 10 Aug 2010 12:13:20 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 4A2323A6840 for ; Tue, 10 Aug 2010 12:13:20 -0700 (PDT) Received: from dn0a21021b.sunet ([10.33.2.27]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OiuGp-00014K-Of; Tue, 10 Aug 2010 12:13:55 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Tue, 10 Aug 2010 11:46:00 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7FE6DAEC-91E4-4FB9-A78C-65F7601A7624@cs.stanford.edu> References: <5FB5C986-D72B-41D9-A193-275DEB1D71A3@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 980022258218d8e0da9e8fd80fb6777b Cc: ROLL WG Subject: Re: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 19:13:21 -0000 On Aug 3, 2010, at 6:36 AM, JP Vasseur wrote: >=20 >=20 > Begin forwarded message: >=20 >>=20 >>=20 >> 4.2. Algorithm Description >>=20 >> The Trickle algorithm has five rules: >>=20 >> 1. When an interval begins, Trickle resets c to 0 and sets t to a >> random point in the interval, taken from the range [I/2, I). >>=20 >> JP> s/I)/I] Just as a note -- this is an example of why there's the strong language = about not tweaking Trickle. If you use [I/2, I] rather than [I/2, I), = then there's an ambiguity when intervals are synchronized: a packet = transmitted in interval X can suppress in interval X+1. This could = prevent Trickle from maintaining its minimum communication rate, as an = entire interval could pass with no transmissions. Phil= From mcr@sandelman.ca Tue Aug 10 13:08:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE65C28B56A; Tue, 10 Aug 2010 13:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.694 X-Spam-Level: X-Spam-Status: No, score=-1.694 tagged_above=-999 required=5 tests=[AWL=0.260, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtnepUnqrTfx; Tue, 10 Aug 2010 13:08:34 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id AD77428C0D0; Tue, 10 Aug 2010 13:08:33 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 819B6345CE; Tue, 10 Aug 2010 16:09:08 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 783D698A6E; Tue, 10 Aug 2010 16:09:07 -0400 (EDT) From: Michael Richardson To: Philip Levis In-Reply-To: <81F72C20-12D3-48D6-968F-A4407DF140C8@cs.stanford.edu> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <23319.1281445020@marajade.sandelman.ca> <1723.1281457687@marajade.sandelman.ca> <81F72C20-12D3-48D6-968F-A4407DF140C8@cs.stanford.edu> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 10 Aug 2010 16:09:07 -0400 Message-ID: <10288.1281470947@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Carsten Bormann , roll@ietf.org, ipv6@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 20:08:35 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Philip" == Philip Levis writes: Philip> I feel like we're running in circles, in part due to Philip> different expectations of how RPL will be used. Philip> It's clear that in proprietary or vertically integrated Philip> networks running RPL, it's possible to state how Philip> controllers/other nodes set the flow label in order to play Philip> nice with RPL. E.g., if my home automation network receives Philip> commands from a special device (which itself might have a Philip> web/SOAP/etc. interface), then that special device can set Philip> the flow label. This isn't the problem case. Philip> The problem case for the use of the flow label is when Philip> arbitrary Internet hosts (e.g., my laptop) want to Philip> communicate with devices running RPL. E.g., I have a home Philip> RPL network and want to directly talk to a RPL device from Philip> my laptop. Requiring the packet source to be aware of flow Philip> labels and how to set them breaks the whole idea of Internet Philip> connectivity: suddenly an end host needs to be aware of what Philip> routing protocol is used to reach the other host, as well as Philip> configuration parameters of that host. I need to be able to Philip> SSH to the RPL-connected device without requiring a new ssh Philip> program that uses ioctls to set flow labels. We can't say Philip> that only OSes which set the flow label to 0 (or some other Philip> value) can be used. Nor can we expect to change how OSes set Philip> the flow label. I guess I don't see the problem to be as big a deal as you suggest. I'm happy if flow label 0 gets some default RPLinstanceID. It would be convenient if the rules were relaxed such that on ingress, the RPL edge router could *set* the FL if it were zero, and it appears that this matches up well with what the load balancing people want to do. Today, if you ssh or HTTP or what-not, without doing anything special, you will get a flow label of zero, which with the above rule, means you get connectivity. Only if some intermediate node sets the FL=0 would it be a problem today, and that's illegal so far. BTW: the flowlabel is not in an ioctl, it's right in the sockaddr_in6. Too bad that inet_ntop(3)/RFC2373/4291 was not specified to include the flow label, as then it would be just a matter of user education... Maybe there is some way to use the %ifname notation used for ifindex mapping. (okay, it falls apart once you want to use DNS) It seems to me that within RPL, if we use RPLinstanceID, we need to decide what to do when we get a flow label from an untrusted source that is non-zero. Inserting an end-host option, with the unstrusted FL seems like the right thing to do to me. This facility might be generally useful to entire Internet. - -- ] 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Finger me for keys iQEVAwUBTGGx4oCLcPvd0N1lAQIuhgf/Z6e/vJKj9K+6+N3djKdLx7nut2iJ+K1X JaKs/TsKJdNJ59520x9m5pcYo+r9oXrGVG2mohIHu0WktY/XkJMdBSncgkiKvSmh VEZlFAzw+eJYZdiNlWvIFxD13REOyc4S+jJhx6ECONFSq2csHdbt8q7O1jIsDuar hEhLS7v0a61T7rbM7aP95q+aYBr2ofWX5g596I/lYgSwZ7+fhuySm7DhckBWf/yC pPdEw4xAMA4/jnHZzp3iTKcFhbGQWvdBvsUKPM/EJLQWwExzFS3WmEP3ltDyXkiZ zo5oEj7Xdir2mN18cvyysa/8izgQ8sD3TSYUu+feNHO2hRdbNRoX3w== =kE6H -----END PGP SIGNATURE----- From mcr@sandelman.ca Tue Aug 10 13:15:31 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95B6B3A67DA; Tue, 10 Aug 2010 13:15:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.974 X-Spam-Level: X-Spam-Status: No, score=-0.974 tagged_above=-999 required=5 tests=[AWL=-0.494, BAYES_00=-2.599, FRT_ADULT2=1.474, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEFjEycrFqOd; Tue, 10 Aug 2010 13:15:30 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id AC6D93A683C; Tue, 10 Aug 2010 13:15:29 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id E42C73475D; Tue, 10 Aug 2010 16:16:04 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id E22DE98A6E; Tue, 10 Aug 2010 16:16:03 -0400 (EDT) From: Michael Richardson To: Carsten Bormann In-Reply-To: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <23319.1281445020@marajade.sandelman.ca> <1723.1281457687@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Tue, 10 Aug 2010 16:16:03 -0400 Message-ID: <10486.1281471363@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org, ipv6@ietf.org Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 20:15:32 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Carsten" == Carsten Bormann writes: >> RPL networks consists of leafs and routers. Both typically act as hosts. >> Routers are just hosts that happen to be between other nodes. >> (Although, some hosts are too weak to be routers) Carsten> OK, I'm not talking of "host" as in originates or Carsten> terminates traffic, but "host" in the sense of "does not Carsten> participate in routing". Carsten> It appears there is no such thing inside a RPL world then. Yes, by that definition that's perhaps a fair statement! I prefer to think of each device as being a router, which an attached host. (the ip_output()/ip_input() parts... are the host, the ip_forward() is the router...) >> Little to no traffic on the RPL is unaware of which RPLinstanceID to >> use, because the applications there needs to send using a specific set >> of constraints, which is encapsulated into the RPLinstanceID. Carsten> Hosts (as in "don't participate in routing") would have Carsten> little idea of such concepts. Yes, but the *applications* do know about such things. Carsten> In IP, hosts send packets to an IP address. You can do that. Your packet might not get there in time. It might take a much longer route than necessary. It might not get there at all, if whatever default RPLinstance that exists does not include your destination. Carsten> Sometimes there are additional considerations, which we so Carsten> far have been addressing [sic] with the TOS byte, i.e., the Carsten> DSCP today. If you prefer, you may think of the RPLinstance as naming something akin to an MPLS or ATM "circuit", except that it's NBMA-ish tree rather than P2P. - -- ] 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Finger me for keys iQEVAwUBTGGzfYCLcPvd0N1lAQKcmAf8DlywBcc1Hq3p8WCos9Oj3srsXnfFuEJb xjWSF7OCbTeAHmP6VYnlNl0BIQCFYonwMFuab4qfdBecbCRcSmegrOWt+SdTAvCJ CCzhc+8afOaFf5Wp5nf1o2l0JmCjHA8Mvmjb7a95O3ZGSnyxOD53Bzo+I2MQTp5Z cdo5O8x6RViuxPFKejsLOn8k5PMP+DMjuTXvuGv31x0+q/KaSs34USXyGLiW5s5i PR827FfSd78pt4V1NzbT55Xrs8ZVAinqNpuLFNbRPWuN60Hymx2Mcr7kLNDW31XW oUji2nvTeCszohWnDJ8nvLv/G1DU1oTAafxZwCpNnebMxupQjBfGkg== =c8iq -----END PGP SIGNATURE----- From pal@cs.stanford.edu Tue Aug 10 17:18:53 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3586F3A69CB; Tue, 10 Aug 2010 17:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.45 X-Spam-Level: X-Spam-Status: No, score=-6.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZEY9JHgGqcaD; Tue, 10 Aug 2010 17:18:52 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 65EDC3A683E; Tue, 10 Aug 2010 17:18:49 -0700 (PDT) Received: from dn0a210181.sunet ([10.33.1.129]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Oiz1V-0007Ln-Dq; Tue, 10 Aug 2010 17:19:25 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <10288.1281470947@marajade.sandelman.ca> Date: Tue, 10 Aug 2010 17:18:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <06149C25-36CA-4956-9686-EB86C2E86089@cs.stanford.edu> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <23319.1281445020@marajade.sandelman.ca> <1723.1281457687@marajade.sandelman.ca> <81F72C20-12D3-48D6-968F-A4407DF140C8@cs.stanford.edu> <10288.1281470947@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 9dddbef7dbf47a29383c7a3c8e5dce6e Cc: Carsten Bormann , roll@ietf.org, ipv6@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 00:18:53 -0000 On Aug 10, 2010, at 1:09 PM, Michael Richardson wrote: >=20 > I guess I don't see the problem to be as big a deal as you suggest. > I'm happy if flow label 0 gets some default RPLinstanceID. =20 >=20 > It would be convenient if the rules were relaxed such that on ingress, > the RPL edge router could *set* the FL if it were zero, and it appears > that this matches up well with what the load balancing people want to > do. >=20 > Today, if you ssh or HTTP or what-not, without doing anything special, > you will get a flow label of zero, which with the above rule, means = you > get connectivity. Only if some intermediate node sets the FL=3D0 = would it > be a problem today, and that's illegal so far. Can you promise me that every device in the Internet does this, i.e. = that there are no IP stacks which set the flow label? Phil= From mcr@sandelman.ca Tue Aug 10 18:05:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABD223A6881; Tue, 10 Aug 2010 18:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.68 X-Spam-Level: X-Spam-Status: No, score=-1.68 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0xX0wD6VBwr; Tue, 10 Aug 2010 18:05:23 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 94C473A683E; Tue, 10 Aug 2010 18:05:23 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id 56FED34406; Tue, 10 Aug 2010 21:05:58 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id E7C1B98A73; Tue, 10 Aug 2010 21:05:56 -0400 (EDT) From: Michael Richardson To: Fred Baker In-Reply-To: <357087A8-7FD7-4696-88CA-F7D8E41209EE@cisco.com> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <48421D4F-0E73-4192-88EA-D7C6672768F5@free.fr> <6A2A459175DABE4BB11DE2026AA50A5D027CCE7B@XMB-AMS-107.cisco.com> <097F191C-3E28-48E3-AAAF-81730D2A49FD@free.fr> <987.1281456566@marajade.sandelman.ca> <357087A8-7FD7-4696-88CA-F7D8E41209EE@cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Tue, 10 Aug 2010 21:05:56 -0400 Message-ID: <23209.1281488756@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: =?us-ascii?Q?=3D=3Fus-ascii=3FQ=3F=3D3D=3D3Fiso-8859-1=3D3FQ=3D3FR=3D3?= =?us-ascii?Q?DE9mi=3D5FDespr=3D3DE9s=3D3F=3D3D=3F=3D?= , 6man 6man , roll@ietf.org, Carsten Bormann Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 01:05:24 -0000 >>>>> "Fred" =3D=3D Fred Baker writes: Fred> I would find that surprising. There are ample cases where the Fred> originator of a high data rate flow (sensor data from a radio Fred> telescope to a number cruncher, to pick one example) might Fred> want to use the flow label to send data from one session down Fred> multiple paths. Multi-path TCP would be another example. I Fred> suppose you could argue that consistently alternating among N Fred> flow labels can be thought of as N separate flows, but if it's Fred> TCP there are other ramifications.=20 I did write: >> points) were mandated that they must now always set a FL consistentl= y on >> a flow, and set it to a non-zero value, that this would satisfy the >> requirements of load balancers. I don't mean to say that the FL has to be a single value: I guess it could be from a set of values if one wants to do multi-path. Fred> In any event, the requirement of the load balancer is not that Fred> the originator gives things a tag; we can develop such tags Fred> from a hash of the source and destination address quite well, Fred> thanks. The important thing is that things are tagged in a Well... if FL is unique per sender's concept of flow, that's 128+20 bits for the tcam vs 256+8+32 bits if you use the 5-tuple. (why use a tcam for this... I don't know... there are no wildcard bits. A cam or patricia-tree would be as good...) Fred> manner that helps the load balancer. There are two major uses Fred> of load balancers. In data centers, we balance sessions Fred> to/from sets of servers, and the question when a new session Fred> comes up is which server is most likely to be able to Fred> effectively serve it (has the necessary resources including Fred> access to the right disks, CPU cycles, etc). In bandwidth Fred> allocation uses (spreading load across multiple Fred> otherwise-equivalent paths), the question is how to use each Fred> of the paths most effectively - we want some traffic on each Fred> of them and we want none of the paths to be overloaded or Fred> introducing more delay or loss than others. Everyone's Fred> instinctive knee-jerk response to the question seems to be Fred> "hash something and depend on the law of large numbers to Fred> serve the need", and the observation of numerous operators is Fred> that the law of large numbers is a good start but is not an Fred> adequate solution. You really want the load balancer to be Fred> able to be smarter than that.=20 Fred> Which is why people that build load balancers frequently do so Fred> using NAT technology or some other way of tagging individual Fred> sessions. And why they are looking for mutable flow labels in Fred> this thread.=20 So, they want to mutate all flow labels, or just non-zero ones? >>>>>>> "R=E9mi" =3D=3D R=E9mi Despr=E9s writes: > R=E9mi> RFC 3697 isn't concerned with ASes, and doesn't need to be. > R=E9mi> The proposal is only that, where load balancing is performed,= =20 > R=E9mi> 0 FLs MAY be replaced by meaningful values for this purpose.= =20=20=20 > R=E9mi> A FL, once set to a non 0 value, never needs to be reset. mcr> okay, so what you are saying is that load balancing uses of the FL= are mcr> only upset when they see zero. So for instance, if layer-4s (i.e.= end mcr> points) were mandated that they must now always set a FL consisten= tly on mcr> a flow, and set it to a non-zero value, that this would satisfy the mcr> requirements of load balancers. mcr>=20 mcr> In this context, permission would be given to set zero FL to a non= -zero mcr> value.=20 From pthubert@cisco.com Wed Aug 11 02:15:05 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D5713A6A38 for ; Wed, 11 Aug 2010 02:15:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.474 X-Spam-Level: X-Spam-Status: No, score=-10.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c77MHDiLNMOq for ; Wed, 11 Aug 2010 02:15:00 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 541093A6A49 for ; Wed, 11 Aug 2010 02:15:00 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALYGYkxAZnwN/2dsb2JhbACgO3GfUZtWhToEjCg X-IronPort-AV: E=Sophos;i="4.55,352,1278288000"; d="scan'208";a="146331421" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 11 Aug 2010 09:15:35 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7B9FYos007767; Wed, 11 Aug 2010 09:15:35 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Aug 2010 11:15:35 +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: Wed, 11 Aug 2010 11:15:32 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D027CD0CD@XMB-AMS-107.cisco.com> In-Reply-To: <877hjyd4fq.fsf@kelsey-ws.hq.ember.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] RPL hop-by-hop and source route thread-index: Acs4iamRcDjQDantTt+TF0XHcBfh7QAqyBWQ References: <874ofbff0d.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D027CC9CC@XMB-AMS-107.cisco.com> <87d3tsc6ok.fsf@kelsey-ws.hq.ember.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCB4B@XMB-AMS-107.cisco.com> <877hjyd4fq.fsf@kelsey-ws.hq.ember.com> From: "Pascal Thubert (pthubert)" To: "Richard Kelsey" X-OriginalArrivalTime: 11 Aug 2010 09:15:35.0320 (UTC) FILETIME=[C188A980:01CB3935] Cc: roll@ietf.org Subject: Re: [Roll] RPL hop-by-hop and source route X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 09:15:05 -0000 Hi Richard: > > Even in storing, a strict hierarchy of instances could have allowed a > > packet to switch instances in a loopless fashion, but the group > > decided not to go there. Please do not ask me to defend that position, > > I was in the other camp : ) >=20 > Routing upwards using the DODAG is a completely different issue. The source > route forwarding is distinct from RPL and it seems wrong for RPL to put > constraints on it. The point does not have to do with up or down routing. It has to do with the capabilities of the path and the respect of the constraints. If the Source Route uses hops from multiple instances that are computed for different OFs then the result is admittedly loopless, but unconstrained as well. Like I said, the enforcement of this limitation does not come from me. I support allowing the instance switching as long as there's a policy that makes it loopless, and the deployment guys understand what they are doing and the result they can expect from doing it. The source routing by the root is one example of that whereby the policy is to enforce that the root checks at least that it builds a loopless source route (that's actually specified in the 6MAN draft so I'm fine). Pascal > -----Original Message----- > From: Richard Kelsey [mailto:richard.kelsey@ember.com] > Sent: Tuesday, August 10, 2010 2:43 PM > To: Pascal Thubert (pthubert) > Cc: roll@ietf.org > Subject: Re: [Roll] RPL hop-by-hop and source route >=20 > > Date: Mon, 9 Aug 2010 16:17:21 +0200 > > From: "Pascal Thubert (pthubert)" > > > > > > That view of the network is per instance. > > > > > > Why? Why restrict the source routes in this way? > > > > [Pascal] Mostly the same answer as in storing mode. If a root could > > (source) route over mixed instances, it'd lose the benefits of the > > constraints. >=20 > Yes, but that is a choice that the root can make. Why should we make that > decision for it? >=20 > > Even in storing, a strict hierarchy of instances could have allowed a > > packet to switch instances in a loopless fashion, but the group > > decided not to go there. Please do not ask me to defend that position, > > I was in the other camp : ) >=20 > Routing upwards using the DODAG is a completely different issue. The source > route forwarding is distinct from RPL and it seems wrong for RPL to put > constraints on it. >=20 > -Richard Kelsey From pthubert@cisco.com Wed Aug 11 03:00:08 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 257C63A6855; Wed, 11 Aug 2010 03:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.475 X-Spam-Level: X-Spam-Status: No, score=-10.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fry5U2Rd2tGR; Wed, 11 Aug 2010 03:00:07 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 9B93D3A6358; Wed, 11 Aug 2010 03:00:06 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuMFAPcRYkxAZnwM/2dsb2JhbACTOo0BcZ8dm1uFOgSMKA X-IronPort-AV: E=Sophos;i="4.55,352,1278288000"; d="scan'208";a="146171749" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 11 Aug 2010 10:00:41 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7BA0eSA004117; Wed, 11 Aug 2010 10:00:41 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Aug 2010 12:00:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 x-cr-puzzleid: {9C078CB1-2476-4607-9393-D0D74A9FFC6B} MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable x-cr-hashedpuzzle: KLvZ K2iA SeDn VGKj Vwlm akjC bbZy fzGO kDZZ kdHC lpIH nprx n4tn n+qK snWI wYLK; 5; YgByAGkAYQBuAC4AZQAuAGMAYQByAHAAZQBuAHQAZQByAEAAZwBtAGEAaQBsAC4AYwBvAG0AOwBjAGEAYgBvAGMAYQBiAG8AQABnAG0AYQBpAGwALgBjAG8AbQA7AGkAcAB2ADYAQABpAGUAdABmAC4AbwByAGcAOwBtAGMAcgBAAHMAYQBuAGQAZQBsAG0AYQBuAC4AYwBhADsAcgBvAGwAbABAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {9C078CB1-2476-4607-9393-D0D74A9FFC6B}; cAB0AGgAdQBiAGUAcgB0AEAAYwBpAHMAYwBvAC4AYwBvAG0A; Wed, 11 Aug 2010 09:27:54 GMT; UgBFADoAIABGAGwAbwB3ACAATABhAGIAZQBsADoAIAAxADIAIABiAGkAdABzACAAbQB1AHQAYQBiAGwAZQAgAGEAbgBkACAAOAAgAGIAaQB0AHMAIABpAG0AbQB1AHQAYQBiAGwAZQA= Content-class: urn:content-classes:message Date: Wed, 11 Aug 2010 12:00:38 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> In-Reply-To: <26885.1281450459@marajade.sandelman.ca> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flow Label: 12 bits mutable and 8 bits immutable thread-index: Acs4mDuYpbsNpyPGRtOaqNz3bQaw7AAnjn1w References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> From: "Pascal Thubert (pthubert)" To: X-OriginalArrivalTime: 11 Aug 2010 10:00:39.0292 (UTC) FILETIME=[0D3A0BC0:01CB393C] Cc: Carsten Bormann , roll@ietf.org, ipv6@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 10:00:08 -0000 >=20 > Pascal> [Pascal] The FL based proposal for RPL uses 12 mutable bits. >=20 > Pascal> They are used as an in-band control plane that checks the > Pascal> consistency of routing states along a path. Those states can > Pascal> easily get out of sync due to the nature of the links, but > Pascal> the maintenance can be costly. We want to accelerate the > Pascal> repairs on those links that are actually used when an > Pascal> inconsistency is detected that will impact the delivery. >=20 > I don't understand how the FL helps us on this! Probably I missed something > important. What you write below was my entire understanding of our need for > an in-band tag. [Pascal] This point is not about the flow label specifically but about the RPL strategy, and it works whether we use the flow label or the hop by hop techniques to transport the info. In short, the mere fact that there is a packet on the broken path causes us to 1) detect and 2) fix the issue. If there's no packet on a broken path then it can stay broken for a while. There will probably be many broken paths at any point of time in the network, due to transient link interference, movement, and all sorts of routing desyncs. Considering the cost of proactive rapid resolution, we have chosen not to fix the routing issues as soon as they appear but 1) lazily and 2) on-demand. The lazy piece is a global reconstruction of the DAG that happens periodically. The on-demand piece is a data path validation that allows us to fix a path as it is being used, either using a mutable flow label field or the Hop by Hop header. Pascal From pthubert@cisco.com Wed Aug 11 03:00:08 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E32F93A6855; Wed, 11 Aug 2010 03:00:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.977 X-Spam-Level: X-Spam-Status: No, score=-9.977 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, GB_AFFORDABLE=1, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yygbN-Rmmaj3; Wed, 11 Aug 2010 03:00:07 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 7F71E28C0CF; Wed, 11 Aug 2010 03:00:07 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPcRYkxAZnwM/2dsb2JhbACgO3GfHZtbhToEjCg X-IronPort-AV: E=Sophos;i="4.55,352,1278288000"; d="scan'208";a="146171753" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 11 Aug 2010 10:00:41 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7BA0eSC004117; Wed, 11 Aug 2010 10:00:41 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Aug 2010 12:00:39 +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: Wed, 11 Aug 2010 12:00:36 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D027CD106@XMB-AMS-107.cisco.com> In-Reply-To: <4C61CA3D.80807@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ROLL choice to not use the Flow Label thread-index: Acs41nQ3x5Taf3ZXTH2SzGGuGnNI1AAYuz5Q References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com><11162.1280887515@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com><4C609233.8030207@gmail.com><23319.1281445020@marajade.sandelman.ca><1723.1281457687@marajade.sandelman.ca><645C41BE-BDB5-4D09-891A-9640FD1165AE@cisco.com> <4C61CA3D.80807@gmail.com> From: "Pascal Thubert (pthubert)" To: "Brian E Carpenter" , "Fred Baker (fred)" X-OriginalArrivalTime: 11 Aug 2010 10:00:39.0621 (UTC) FILETIME=[0D6C3F50:01CB393C] Cc: Carsten Bormann , roll@ietf.org, ipv6@ietf.org Subject: Re: [Roll] ROLL choice to not use the Flow Label X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 10:00:09 -0000 Hi Brian: The Hop by Hop is certainly the clean solution.=20 The trouble is that it requires additional bytes in every packet for the header and for the IP-in-IP encapsulation that goes with it; yet RPL operates in a domain where devices can be strictly constrained in energy and frames can be very small, so every bit counts quite dramatically. Thus we're looking for more affordable alternates. We have started a 6MAN document on the IP in IP avoidance for instance. Here, the point is not to get the flow label definition impacted by RPL but to see if the flow label can be used by RPL within the definition that 6MAN will refine. If we have enough mutable bits, then we can allow an alternate mode in RPL whereby those they are used as opposed to the HbH.=20 For the instance ID, it's certainly a lot more complex since we are defining an interaction between the app layer and the network. I do not know if the result of a 6MAN work on such interaction can be used by RPL in the end, but I think it is a good subject to address before we make all bits mutable. My initial take would be that there should at least be one bit somewhere that indicates that the source does not want (a piece of) the FL to be modified.=20 Pascal > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf Of > Brian E Carpenter > Sent: Tuesday, August 10, 2010 11:53 PM > To: Fred Baker (fred) > Cc: Carsten Bormann; roll@ietf.org; ipv6@ietf.org; Michael Richardson > Subject: ROLL choice to not use the Flow Label >=20 > Thanks for all the enlightment about ROLL. >=20 > My personal conclusion is that the ROLL considerations are too complex and > too subtle to be compatible with using a general-purpose IPv6 header field (i.e. > the flow label) for ROLL purposes. They seem to be an extreme case of the > challenges of defining a local-use regime for the flow label, which have already > been a stumbling block for the various versions of draft-carpenter-6man-flow- > update. >=20 > So IMHO, ROLL/RPL was quite wise to drop the IPv6 header flow label proposal. >=20 > Brian >=20 > On 2010-08-11 08:53, Fred Baker wrote: > > On Aug 10, 2010, at 11:21 AM, Carsten Bormann wrote: > > > >> OK, I'm not talking of "host" as in originates or terminates traffic, but "host" > in the sense of "does not participate in routing". > >> It appears there is no such thing inside a RPL world then. > > > > A RPL or Manet world doesn't have the 1970's-mentality limitation that hosts > have to be stupid. Of all networking architectures, the Internet is the only one > with that delusion. > > > > http://www.ipinc.net/IPv4.GIF > > > > > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From pthubert@cisco.com Wed Aug 11 04:24:22 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A51E3A68A5 for ; Wed, 11 Aug 2010 04:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.472 X-Spam-Level: X-Spam-Status: No, score=-10.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MOtVYG5-xYXl for ; Wed, 11 Aug 2010 04:24:21 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B51FB3A6817 for ; Wed, 11 Aug 2010 04:24:20 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGolYkyrR7Hu/2dsb2JhbACgO3GfUZtdhToEjCiHTA X-IronPort-AV: E=Sophos;i="4.55,352,1278288000"; d="scan'208";a="170456661" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 11 Aug 2010 11:24:56 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7BBOq55005471; Wed, 11 Aug 2010 11:24:56 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 11 Aug 2010 13:24:56 +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: Wed, 11 Aug 2010 13:24:53 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D027CD184@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rank in HbH / FL thread-index: Acs4rMd4oX7S71DhRMaCsQIs0zHZ0AAfnI+w References: <6A2A459175DABE4BB11DE2026AA50A5D027CCDAB@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 11 Aug 2010 11:24:56.0000 (UTC) FILETIME=[D3427400:01CB3947] Cc: roll@ietf.org Subject: Re: [Roll] Rank in HbH / FL X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 11:24:22 -0000 Hi Phil: I would not mind specifying that min hop increase is >=3D 256. Also, the FL approach is an alternate to the mainstream HbH. At moment, only HbH Is available and we'll see where 6MAN goes. If there's a way to use the flow label, then we'll document it.=20 Best, Pascal > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Tuesday, August 10, 2010 6:55 PM > To: Pascal Thubert (pthubert) > Cc: Michael Richardson; roll@ietf.org > Subject: Re: Rank in HbH / FL >=20 > On Aug 10, 2010, at 4:54 AM, Pascal Thubert (pthubert) wrote: >=20 > > Hi Phil: > > > > The use of the Rank in forwarding path is to differentiate up from down. > > Only the floor(Rank) is needed, and that floor() can be made one octet > > or less even for metrics that we rank in 2 octets. > > The proposal is not to compress but simply to pass the useful > > information as opposed to the waste we are currently observing in all > > packets. > > Note: Same floor means siblings, which the group selected not to use, > > upon your suggestion. >=20 > Pascal, >=20 > I understand what the goal is; I'm questioning whether it's technically feasible. >=20 > This works in some cases, but not all. E.g. if you use the entire 12 bits to > represent Rank but MinHopRankIncrease is < 16 (0x10), then you cannot > compress Rank properly. If you want to use fewer than 12 bits, then the > constraint becomes tighter. >=20 > For some metric->Rank conversions, where the dynamic range is relatively > small, such as ETX, then this constraint might be possible to satisfy. But there > are some metric->Rank conversions, such as latency, where the dynamic range > can be very high. >=20 > Yes, floor() *can* be made one octet in some cases. That does not mean it can > be done so in all cases. Otherwise we have specified that MinHopRankIncrease > is always >=3D 256. >=20 > Phil From mcr@sandelman.ca Wed Aug 11 07:48:09 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF8C83A6944; Wed, 11 Aug 2010 07:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.354 X-Spam-Level: X-Spam-Status: No, score=-1.354 tagged_above=-999 required=5 tests=[AWL=-0.400, BAYES_00=-2.599, GB_AFFORDABLE=1, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5T3trOQQ9TYs; Wed, 11 Aug 2010 07:48:09 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 751933A6900; Wed, 11 Aug 2010 07:48:08 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 7274634771; Wed, 11 Aug 2010 10:48:44 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 8E10298A73; Wed, 11 Aug 2010 10:48:43 -0400 (EDT) From: Michael Richardson To: "Pascal Thubert (pthubert)" In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D027CD106@XMB-AMS-107.cisco.com> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com><11162.1280887515@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com><4C609233.8030207@gmail.com><23319.1281445020@marajade.sandelman.ca><1723.1281457687@marajade.sandelman.ca><645C41BE-BDB5-4D09-891A-9640FD1165AE@cisco.com> <4C61CA3D.80807@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CD106@XMB-AMS-107.cisco.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 11 Aug 2010 10:48:43 -0400 Message-ID: <4881.1281538123@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: Carsten Bormann , roll@ietf.org, ipv6@ietf.org, Brian E Carpenter , "Fred Baker \(fred\)" Subject: Re: [Roll] ROLL choice to not use the Flow Label X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 14:48:10 -0000 >>>>> "Pascal" == Pascal Thubert <(pthubert)" > writes: Pascal> Hi Brian: Pascal> The Hop by Hop is certainly the clean solution. Pascal> The trouble is that it requires additional bytes in every Pascal> packet for the header and for the IP-in-IP encapsulation Pascal> that goes with it; yet RPL operates in a domain where Pascal> devices can be strictly constrained in energy and frames can Pascal> be very small, so every bit counts quite dramatically. Thus Pascal> we're looking for more affordable alternates. We have Pascal> started a 6MAN document on the IP in IP avoidance for Pascal> instance. Pascal> Here, the point is not to get the flow label definition Pascal> impacted by RPL but to see if the flow label can be used by Pascal> RPL within the definition that 6MAN will refine. If we have Pascal> enough mutable bits, then we can allow an alternate mode in Pascal> RPL whereby those they are used as opposed to the HbH. So one solution is for RPL to just do what it wants to inside the LLN, and use IP-in-IP for packets that arrive at the LLN border with a non-zero FL. (ditto for packets that have to leave) This makes the extra bytes the exception rather than the rule. It also can be turned off in closed networks where the FL has been coordinated across the AS. This would be facilitated by the rule that we can set a zero FL to a non-zero value. -- ] 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 pal@cs.stanford.edu Wed Aug 11 16:33:58 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6DA53A6964; Wed, 11 Aug 2010 16:33:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.432 X-Spam-Level: X-Spam-Status: No, score=-6.432 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rwug2MmISeZ5; Wed, 11 Aug 2010 16:33:57 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id D6E133A68C5; Wed, 11 Aug 2010 16:33:57 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.127]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OjKob-0003nF-OJ; Wed, 11 Aug 2010 16:34:34 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Philip Levis In-Reply-To: Date: Wed, 11 Aug 2010 16:34:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <48421D4F-0E73-4192-88EA-D7C6672768F5@free.fr> <6A2A459175DABE4BB11DE2026AA50A5D027CCE7B@XMB-AMS-107.cisco.com> <097F191C-3E28-48E3-AAAF-81730D2A49FD@free.fr> <987.1281456566@marajade.sandelman.ca> To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 72f97ea9660f372cf635c7c250d627db Cc: Carsten Bormann , roll@ietf.org, 6man 6man Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 23:33:58 -0000 On Aug 10, 2010, at 11:12 PM, R=E9mi Despr=E9s wrote: >=20 > Le 10 ao=FBt 2010 =E0 18:09, Michael Richardson a =E9crit : >=20 >>=20 >>>>>>> "R=E9mi" =3D=3D R=E9mi Despr=E9s writes: >> R=E9mi> RFC 3697 isn't concerned with ASes, and doesn't need to be. >> R=E9mi> The proposal is only that, where load balancing is = performed,=20 >> R=E9mi> 0 FLs MAY be replaced by meaningful values for this = purpose. =20 >> R=E9mi> A FL, once set to a non 0 value, never needs to be reset. >>=20 >> okay, so what you are saying is that load balancing uses of the FL = are >> only upset when they see zero. So for instance, if layer-4s (i.e. = end >> points) were mandated that they must now always set a FL consistently = on >> a flow, and set it to a non-zero value, that this would satisfy the >> requirements of load balancers. >=20 > Right. >=20 > To be even more precise:=20 > - Flow endpoints (sometimes layer 4 and sometimes layer 3) should from = now on be mandated to set FLs with non-0 values that statistically = differ from a flow to another. The intention is to have a BCP for network stack implementers to follow? > - However, we have to face that, so far, they are generally mandated = to set FLs to 0. I apologize for the lack of context (I'm coming from ROLL): your = sentence seems to suggest that flow labels today are mandated to be 0. = This doesn't seem to be right: among other things, ping6 supports = setting the flow label, and by default allocates a random flow label.[1] = Basically, I'm confused if you're talking in the present tense of what's = done with flow labels today, or the future tense of how flow labels = should be used in the future. Phil [1] http://linux.die.net/man/8/ping6 From pal@cs.stanford.edu Wed Aug 11 16:40:57 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 984463A6964; Wed, 11 Aug 2010 16:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.575 X-Spam-Level: X-Spam-Status: No, score=-6.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSX2o7F8QktR; Wed, 11 Aug 2010 16:40:56 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id B2D663A67B7; Wed, 11 Aug 2010 16:40:56 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.127]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OjKvN-0004MP-5g; Wed, 11 Aug 2010 16:41:33 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> Date: Wed, 11 Aug 2010 16:41:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 323acaff36744e8473855e70acc36bcb Cc: Carsten Bormann , roll@ietf.org, ipv6@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 23:40:57 -0000 On Aug 11, 2010, at 3:00 AM, Pascal Thubert (pthubert) wrote: >>=20 >> Pascal> [Pascal] The FL based proposal for RPL uses 12 mutable > bits. >>=20 >> Pascal> They are used as an in-band control plane that checks the >> Pascal> consistency of routing states along a path. Those states > can >> Pascal> easily get out of sync due to the nature of the links, but >> Pascal> the maintenance can be costly. We want to accelerate the >> Pascal> repairs on those links that are actually used when an >> Pascal> inconsistency is detected that will impact the delivery. >>=20 >> I don't understand how the FL helps us on this! Probably I missed > something >> important. What you write below was my entire understanding of our > need for >> an in-band tag. >=20 > [Pascal] This point is not about the flow label specifically but about > the RPL strategy, and it works whether we use the flow label or the = hop > by hop techniques to transport the info. In short, the mere fact that > there is a packet on the broken path causes us to 1) detect and 2) fix > the issue. If there's no packet on a broken path then it can stay = broken > for a while. There will probably be many broken paths at any point of > time in the network, due to transient link interference, movement, = and > all sorts of routing desyncs. Considering the cost of proactive rapid > resolution, we have chosen not to fix the routing issues as soon as = they > appear but 1) lazily and 2) on-demand. > The lazy piece is a global reconstruction of the DAG that happens > periodically. The on-demand piece is a data path validation that = allows > us to fix a path as it is being used, either using a mutable flow = label > field or the Hop by Hop header. Maybe a rewording might make this clearer. Basically, RPL puts up to two pieces information in packets that it = routes. The first is which routing topology this packet should be routed = on: RPL supports multiple parallel topologies, e.g., one optimized for = low latency and a second optimized for low energy. This information is = called the RPLInstanceId.=20 The second is information about the "cost" of the forwarder's route to = the destination. This hop-by-hop "cost" information is called Rank. Rank = is needed to detect routing loops: if a router receives a packet whose = prior router's Rank is less than or equal to its own, Rank is not = strictly decreasing and there may be a routing loop. Being able to embed this information in the flow label, rather than = requiring additional headers and IP-in-IP, would greatly reduce header = overhead. In RPL, we're often concerned about very short, such as 10 = byte, packets, so this could be a big savings. The challenge is that the RPLInstanceId is 8 bits and Rank is 16 bits. Does that make sense? Phil= From pal@cs.stanford.edu Wed Aug 11 16:45:21 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E97303A6A29; Wed, 11 Aug 2010 16:45:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.577 X-Spam-Level: X-Spam-Status: No, score=-6.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gNUn3zp4PsI; Wed, 11 Aug 2010 16:45:21 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 3577F3A69DA; Wed, 11 Aug 2010 16:45:21 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.127]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OjKzd-0004hQ-Ly; Wed, 11 Aug 2010 16:45:57 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <4C61CA3D.80807@gmail.com> Date: Wed, 11 Aug 2010 16:45:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <34081FAF-DBBA-40E1-822A-677966860469@cs.stanford.edu> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <23319.1281445020@marajade.sandelman.ca> <1723.1281457687@marajade.sandelman.ca> <645C41BE-BDB5-4D09-891A-9640FD1165AE@cisco.com> <4C61CA3D.80807@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 8e086a056c9d4443aaf3b84243aabc30 Cc: Carsten Bormann , roll@ietf.org, ipv6@ietf.org, Fred Baker Subject: Re: [Roll] ROLL choice to not use the Flow Label X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 23:45:22 -0000 On Aug 10, 2010, at 2:53 PM, Brian E Carpenter wrote: > Thanks for all the enlightment about ROLL. >=20 > My personal conclusion is that the ROLL considerations > are too complex and too subtle to be compatible with using > a general-purpose IPv6 header field (i.e. the flow label) > for ROLL purposes. They seem to be an extreme case of the > challenges of defining a local-use regime for the flow label, > which have already been a stumbling block for the various > versions of draft-carpenter-6man-flow-update. >=20 > So IMHO, ROLL/RPL was quite wise to drop the IPv6 header flow label > proposal. >=20 Brian, I agree that the technical challenges seems significant. It was clear = that, as we were writing RPL, we didn't yet know how to do it, and so we = dropped the idea from the base draft.=20 That being said, the possible benefits are pretty enormous to RPL = networks. I'm therefore of the opinion that we're doing the right thing, = trying to think this through and reach consensus on if there's a way to = do use the flow label cleanly and effectively. The answer may be no, but = the answer may also be yes: only discussion and good engineering design = will let us figure it out. Phil From pthubert@cisco.com Thu Aug 12 01:47:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 890D73A681E; Thu, 12 Aug 2010 01:47:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.475 X-Spam-Level: X-Spam-Status: No, score=-10.475 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KNBSJ8iebwBQ; Thu, 12 Aug 2010 01:47:02 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 2D3943A6804; Thu, 12 Aug 2010 01:47:02 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOJRY0xAZnwM/2dsb2JhbACgOHGfFps9hToEjDmHTQ X-IronPort-AV: E=Sophos;i="4.55,357,1278288000"; d="scan'208";a="146614332" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 12 Aug 2010 08:47:38 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7C8lccE023513; Thu, 12 Aug 2010 08:47:38 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Aug 2010 10:47: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="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Aug 2010 10:47:34 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02862A68@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Flow Label: 12 bits mutable and 8 bits immutable thread-index: Acs5sHwSxCEdViTsSh21dkm/g+QKXgASQ3Wg References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: "Philip Levis" X-OriginalArrivalTime: 12 Aug 2010 08:47:38.0155 (UTC) FILETIME=[044757B0:01CB39FB] Cc: Carsten Bormann , roll@ietf.org, ipv6@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 08:47:03 -0000 > >> > >> Pascal> [Pascal] The FL based proposal for RPL uses 12 mutable > > bits. > >> > >> Pascal> They are used as an in-band control plane that checks the > >> Pascal> consistency of routing states along a path. Those states > > can > >> Pascal> easily get out of sync due to the nature of the links, but > >> Pascal> the maintenance can be costly. We want to accelerate the > >> Pascal> repairs on those links that are actually used when an > >> Pascal> inconsistency is detected that will impact the delivery. > >> > >> I don't understand how the FL helps us on this! Probably I missed > > something > >> important. What you write below was my entire understanding of our > > need for > >> an in-band tag. > > > > [Pascal] This point is not about the flow label specifically but about > > the RPL strategy, and it works whether we use the flow label or the > > hop by hop techniques to transport the info. In short, the mere fact > > that there is a packet on the broken path causes us to 1) detect and > > 2) fix the issue. If there's no packet on a broken path then it can > > stay broken for a while. There will probably be many broken paths at > > any point of time in the network, due to transient link interference, > > movement, and all sorts of routing desyncs. Considering the cost of > > proactive rapid resolution, we have chosen not to fix the routing > > issues as soon as they appear but 1) lazily and 2) on-demand. > > The lazy piece is a global reconstruction of the DAG that happens > > periodically. The on-demand piece is a data path validation that > > allows us to fix a path as it is being used, either using a mutable > > flow label field or the Hop by Hop header. >=20 > Maybe a rewording might make this clearer. >=20 > Basically, RPL puts up to two pieces information in packets that it routes. The > first is which routing topology this packet should be routed on: RPL supports > multiple parallel topologies, e.g., one optimized for low latency and a second > optimized for low energy. This information is called the RPLInstanceId. >=20 > The second is information about the "cost" of the forwarder's route to the > destination. This hop-by-hop "cost" information is called Rank. Rank is needed > to detect routing loops: if a router receives a packet whose prior router's Rank > is less than or equal to its own, Rank is not strictly decreasing and there may be > a routing loop. >=20 > Being able to embed this information in the flow label, rather than requiring > additional headers and IP-in-IP, would greatly reduce header overhead. In RPL, > we're often concerned about very short, such as 10 byte, packets, so this could > be a big savings. >=20 > The challenge is that the RPLInstanceId is 8 bits and Rank is 16 bits. >=20 > Does that make sense? [Pascal] Agreed. We'll note that the Hop by Hop + IP in IP is costly but solves the generic problem *within* the RPL network. The use of the Flow label *within* the RPL network would be an alternate so it could have a more limited applicability, like a more limited number of instances or a Rank floor that can be expressed in 1 octet or less, which is probably more than enough considering that infinity is 16 in RIP. This could cover a large number of foreseeable deployments. There is certainly a strong benefit in Low Power Lossy Networks to make the flow label mutable. Still, making it all mutable will definitely block a communication path between the app and the network, which I feel is a mistake. Pascal From pthubert@cisco.com Thu Aug 12 06:59:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 96A423A6A27; Thu, 12 Aug 2010 06:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.326 X-Spam-Level: X-Spam-Status: No, score=-10.326 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8Z+uU1s1UmN; Thu, 12 Aug 2010 06:59:33 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B8CD53A68B2; Thu, 12 Aug 2010 06:59:33 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHubY0yrRN+J/2dsb2JhbACgPHGgH5szhToEjDk X-IronPort-AV: E=Sophos;i="4.55,358,1278288000"; d="scan'208";a="572405657" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 12 Aug 2010 14:00:10 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o7CE04oj020411; Thu, 12 Aug 2010 14:00:10 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Aug 2010 16:00:09 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 12 Aug 2010 16:00:06 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02862BB4@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Flow Label: 12 bits mutable and 8 bits immutable thread-index: Acs6HZXvn2eg2aTZTtOjzkMvGPYIsQACGlBQ References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com><11162.1280887515@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com><4C609233.8030207@gmail.com><6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com><26885.1281450459@marajade.sandelman.ca><6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com><6A2A459175DABE4BB11DE2026AA50A5D02862A68@XMB-AMS-107.cisco.com> From: "Pascal Thubert (pthubert)" To: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= X-OriginalArrivalTime: 12 Aug 2010 14:00:09.0843 (UTC) FILETIME=[AD27DC30:01CB3A26] Cc: Carsten Bormann , roll@ietf.org, ipv6@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 13:59:34 -0000 Yes, R=E9mi, you are. We have explained that inserting data requires a new header and thus IP = in IP encapsulation. This happens for instance when a packet comes from = the Internet into a RPL network. Which we can hardly accept in = constrained networks an devices. In most cases, we could squeeze the = information we need in the Flow Label should it be mutable. =20 Pascal > -----Original Message----- > From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf = Of > R=E9mi Despr=E9s > Sent: Thursday, August 12, 2010 2:55 PM > To: Pascal Thubert (pthubert) > Cc: ipv6@ietf.org; Carsten Bormann; roll@ietf.org; Brian E Carpenter; > mcr@sandelman.ca > Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable >=20 >=20 > Le 12 ao=FBt 2010 =E0 10:47, Pascal Thubert (pthubert) a =E9crit : > > We'll note that the Hop by Hop + IP in IP is costly but solves the > > generic problem *within* the RPL network. The use of the Flow label > > *within* the RPL network would be an alternate so it could have a = more > > limited applicability, like a more limited number of instances or a > > Rank floor that can be expressed in 1 octet or less, which is = probably > > more than enough considering that infinity is 16 in RIP. This could > > cover a large number of foreseeable deployments. > > > > There is certainly a strong benefit in Low Power Lossy Networks to > > make the flow label mutable. >=20 > How strong the benefit isn't clear to me. > Since RPL networks are recognized as such by hosts, it seems easy to = add a > short field, just before the IP header, to contain whatever is useful = for this kind > of network. > Mixing functions with those of FLs would thus be avoided. >=20 > Did I miss something? > RD >=20 >=20 >=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From jpv@cisco.com Thu Aug 12 12:26:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067133A681D for ; Thu, 12 Aug 2010 12:26:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.47 X-Spam-Level: X-Spam-Status: No, score=-110.47 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W6YZW1j3qIaJ for ; Thu, 12 Aug 2010 12:26:52 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2A2B93A67F0 for ; Thu, 12 Aug 2010 12:26:23 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKfnY0yrR7Hu/2dsb2JhbACgNnGiX5tVhToEiV6CXQ X-IronPort-AV: E=Sophos;i="4.55,360,1278288000"; d="scan'208,217";a="572596432" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 12 Aug 2010 19:26:25 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7CJQOvH012438; Thu, 12 Aug 2010 19:26:24 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Aug 2010 21:26:24 +0200 Received: from [10.105.111.69] ([10.61.96.23]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Aug 2010 21:26:23 +0200 Message-Id: From: JP Vasseur To: ROLL WG In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-102-538350936 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 12 Aug 2010 21:19:05 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Aug 2010 19:26:23.0604 (UTC) FILETIME=[4006C340:01CB3A54] Subject: [Roll] WG Last Call on draft-ietf-roll-trickle-02 has ended X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 19:26:54 -0000 --Apple-Mail-102-538350936 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, WG Last Call on draft-ietf-roll-trickle-02 has now ended. Authors, please address the comments raised during the WG Last Call and submit a new revision, before publication request. Thanks. JP. On Jul 28, 2010, at 10:05 AM, JP Vasseur wrote: > Dear WG, > > draft-ietf-roll-trickle-02 is stable and now ready for WG Last Call. > > This starts a 2-week Working Group last call ending on August 11 at > 9:00am ET. > > Please send your comments to the authors and the list. > > Thanks. > > JP. --Apple-Mail-102-538350936 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear all,

WG = Last Call on draft-ietf-roll-trickle-02 has now = ended. 
Authors, please address the comments raised = during the WG Last Call and submit a new revision, before publication = request.

Thanks.

JP.

On Jul 28, 2010, at 10:05 AM, JP Vasseur = wrote:

Dear WG,

draft-ietf-roll-trickle-02 is stable and now ready = for WG Last Call.

This starts a 2-week Working Group last call = ending on August 11 at 9:00am ET.

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

Thanks.

JP.
=

= --Apple-Mail-102-538350936-- From jpv@cisco.com Thu Aug 12 12:27:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4511D3A67C3 for ; Thu, 12 Aug 2010 12:27:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.471 X-Spam-Level: X-Spam-Status: No, score=-110.471 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XK2RzLqvVtOB for ; Thu, 12 Aug 2010 12:27:29 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D9D233A6A4F for ; Thu, 12 Aug 2010 12:27:15 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC7nY0yrR7H+/2dsb2JhbACgNnGiWptWhToEiV6CXQ X-IronPort-AV: E=Sophos;i="4.55,360,1278288000"; d="scan'208,217";a="239541001" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 12 Aug 2010 19:26:36 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7CJQZD5013834; Thu, 12 Aug 2010 19:26:36 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Aug 2010 21:26:35 +0200 Received: from [10.105.111.69] ([10.61.96.23]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Aug 2010 21:26:34 +0200 Message-Id: <7E77E102-2A1D-4F92-9A31-DDA13A4CDBA1@cisco.com> From: JP Vasseur To: ROLL WG In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-103-538800552 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 12 Aug 2010 21:26:34 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 12 Aug 2010 19:26:34.0761 (UTC) FILETIME=[46AD2F90:01CB3A54] Subject: [Roll] WG Last Call on draft-ietf-roll-trickle-02 has ended X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 19:27:30 -0000 --Apple-Mail-103-538800552 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, WG Last Call on draft-ietf-roll-trickle-02 has now ended. Authors, please address the comments raised during the WG Last Call and submit a new revision, before publication request. Thanks. JP. On Jul 28, 2010, at 10:05 AM, JP Vasseur wrote: > Dear WG, > > draft-ietf-roll-trickle-02 is stable and now ready for WG Last Call. > > This starts a 2-week Working Group last call ending on August 11 at > 9:00am ET. > > Please send your comments to the authors and the list. > > Thanks. > > JP. --Apple-Mail-103-538800552 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear all,

WG = Last Call on draft-ietf-roll-trickle-02 has now = ended. 
Authors, please address the comments raised = during the WG Last Call and submit a new revision, before publication = request.

Thanks.

JP.

On Jul 28, 2010, at 10:05 AM, JP Vasseur = wrote:

Dear WG,

draft-ietf-roll-trickle-02 is stable and now ready = for WG Last Call.

This starts a 2-week Working Group last call = ending on August 11 at 9:00am ET.

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

Thanks.

JP.
=

= --Apple-Mail-103-538800552-- From remi.despres@free.fr Mon Aug 9 04:49:29 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 48DE828C0E0; Mon, 9 Aug 2010 04:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.504 X-Spam-Level: X-Spam-Status: No, score=-1.504 tagged_above=-999 required=5 tests=[AWL=0.445, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fntR594LZBb5; Mon, 9 Aug 2010 04:49:28 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.19]) by core3.amsl.com (Postfix) with ESMTP id 73C823A6834; Mon, 9 Aug 2010 04:49:27 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2303.sfr.fr (SMTP Server) with ESMTP id EB91470000A7; Mon, 9 Aug 2010 13:50:00 +0200 (CEST) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2303.sfr.fr (SMTP Server) with ESMTP id 3307070000A6; Mon, 9 Aug 2010 13:50:00 +0200 (CEST) X-SFR-UUID: 20100809115000209.3307070000A6@msfrf2303.sfr.fr Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> Date: Mon, 9 Aug 2010 13:49:58 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <48421D4F-0E73-4192-88EA-D7C6672768F5@free.fr> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Sun, 15 Aug 2010 14:43:40 -0700 Cc: Carsten Bormann , roll@ietf.org, 6man 6man Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 11:49:29 -0000 Le 9 ao=FBt 2010 =E0 12:17, Pascal Thubert (pthubert) a =E9crit : > Hi Michael: >=20 > With http://tools.ietf.org/html/draft-ietf-roll-rpl-07#section-7.2 I > tried to stay within the lines of RFC 3697 as you also defend in your > mail.=20 >=20 > I think the question we have now is not whether that proposal is = lawful > but whether the new law being defined at 6MAN would prevent it in the > future. > If the updated rules allow, then I'll be glad to work on an FL-based > alternate to the IPinIP/HbH.=20 >=20 > It appeared at the 6MAN WG meeting that 12 bits mutable was exactly = what > the core network was asking for to do its load balancing. Would you have more details on WHY it would be "exactly" what was needed = (???) ?=20 > A first question to the group could be whether 12 mutable bits are > enough for the sensible usages envisioned so far? I'd rather see the first question as being "Are there some improvements = of RFC 3697 that would make it practicable?". If yes, improving this RFC rather than deprecating it after 6+ years of = standard-track existence would IMHO be better for IPv6 credibility (and = IMHO for that of IETF in general). The two improvements that seem to make sense (see various exchanged = mails) are: - permit stateless support (with flow-ID hashes in place of flow-based = stateful processing) - permit intermediate nodes to set FLs when source hosts haven't done it = (still as shorthands for flow ISs made available in IPv6 first headers). Regards, RD >=20 > Pascal >=20 >=20 >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > Of >> Michael Richardson >> Sent: Wednesday, August 04, 2010 4:05 AM >> To: roll@ietf.org; Carsten Bormann >> Cc: Pascal Thubert (pthubert); ipv6@ietf.org >> Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable >>=20 >>=20 >> {there is a thread which started on roll@ietf.org, and ipv6@ietf.org, > and then >> seemed to have dropped roll@ietf.org. I'm not on ipv6@ietf.org, so > there likely >> are message there I've missed} >>=20 >> okay, so I've read Carsen's opinion. >> I read RFC 3697 (which I didn't know about). >>=20 >> draft-hu-flow-label-cases-00 is a very good read. I pull out > something from >> section 4 (Discussion); >>=20 >> The other choice, for designers who wish to use the flow label to >> control switching or QoS directly, is to bypass the rules within a >> given domain (a set of cooperating nodes) in a way that nodes > outside >> the domain cannot detect. In this case, any deviation from > [RFC3697] >> has no possible effect outside the domain in question. >>=20 >> I don't know where this subject line is from: 12 bits/8bits. >> Is there a draft that explains that idea that I've missed? >>=20 >> My claim is that ROLL's RPL is a set of cooperating nodes. >>=20 >> But, it's better than that --- it's a set of routers which are tuned > to support >> specific applications, and the applications want in this case to be > given >> information like, "what flow label" to use. RPL's RPLinstanceID has > all the >> properties required of a flow label (or, rather, it has no > requirements presently, >> and therefore can have the flow label requirements imposed upon it, >> specifically: >> 2. "Nodes MUST NOT assume any mathematical or other properties of >> the Flow Label" >> ) >>=20 >> The non-mutability of the label isn't a problem either --- the > applications *AT >> EACH END*, even if one end of the application is several AS's away (a > very >> unusual case for 95% of RPL's target use), that application still > needs to know >> something about what label to use. >>=20 >> There are three cases to consider: >> a) traffic between two RPL nodes >> b) traffic exiting an RPL >> c) traffic entering an RPL >>=20 >> case (a) -- is the "set of cooperating nodes", and therefore is no > problem. >>=20 >> case (b) -- the flow label is set to get through the RPL/LLN, and out > to >> the network, and the flow label has done it's job, and >> the RPL/LLN network could care less what happens to the > flow >> label at that point. The rest of the network might have > a >> problem (i.e. a bug) when RPL networks start sending >> non-zero flow labels, but that's the rest of the > network's >> problem. >>=20 >> case (c) - flow labels of zero are not a problem. There is either a >> default RPLinstanceID to use (and traffic flows, perhaps not >> optimally), or there isn't (and ICMP Host unreachable > occurs). >>=20 >> - non-zero flow labels which do not map to an RPLinstanceID, >> are simply considered zero, see above. >> - non-zero flow labels which map to RPLinstanceIDs are used. >> *If* it is a problem for outsiders to invoke that LLN's >> DODAG, then there are bigger issues, which the flow label > can neither >> help nor hinder --- the flowlabel is not a magic security > cookie. >> A firewall may still be required. >>=20 >> The only real problem I can see is when a packet needs to do (b) and >> (c). e.g. use label A to exit LLN alpha, and label B to enter LLN > beta. >>=20 >> I don't have a solution to this. Some have suggested IPIP tunnels, > which sound >> nice in theory, but in practice do not work in the wilderness found > behind the >> walls of walled gardens. >>=20 >> -- >> ] 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. >>=20 >>=20 >>=20 >>=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- From brian.e.carpenter@gmail.com Mon Aug 9 16:41:12 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 80E983A68AC; Mon, 9 Aug 2010 16:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.809 X-Spam-Level: X-Spam-Status: No, score=-102.809 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkuO-zaL3bee; Mon, 9 Aug 2010 16:41:10 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 092903A67D4; Mon, 9 Aug 2010 16:41:09 -0700 (PDT) Received: by qyk1 with SMTP id 1so2602748qyk.10 for ; Mon, 09 Aug 2010 16:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=rUg1SNWMtSi0RZimZ21IvEDQImVSWKLngtd0TyWC1s8=; b=H3eItfcA7rfXt3StV0YvmVEwozHOvSYdVTMCs77WxTEY3Z+9VuxAXZmPVtHrrIa098 eIL8GT/DVmU56Q6G1z28stq0h/szq/DbeFmr4Q0h/9POPmiPpYXLRu3L+YH8c1w5QzB6 JdDH1S0nJu84PYHUy8sct6v6ALn3zsC3FJABY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=d7FhYPx2o6bmqnMnF/wpw+k0NRLoLk/DW7Zky9Ko7kf0ZENfZ8f/j/kYvIduHr2UGx 2WI2yMuQ9sWYyoqgwaV4kW5QYZdViiJbwXej48XRh+lxoPo30HzeC475BxpEgBZ6jNXo YJRLezhFxTJgVx1SEajMqckZC+ghTcMJqlKU8= Received: by 10.224.64.80 with SMTP id d16mr9064852qai.266.1281397304288; Mon, 09 Aug 2010 16:41:44 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id t1sm7053920qcs.45.2010.08.09.16.41.41 (version=SSLv3 cipher=RC4-MD5); Mon, 09 Aug 2010 16:41:43 -0700 (PDT) Message-ID: <4C609233.8030207@gmail.com> Date: Tue, 10 Aug 2010 11:41:39 +1200 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: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 15 Aug 2010 14:43:40 -0700 Cc: Carsten Bormann , roll@ietf.org, ipv6@ietf.org Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Aug 2010 23:41:12 -0000 Pascal, Thanks for this and your previous message. I would need to think very carefully whether this proposal would really have been strictly compatible with RFC 3697 - it actually depends on how the agreement to use these semantics imposed on the flow label is made (what is called 'flow state establishment' in the RFC). I see more weaknesses in 3697 each time I look at it :-( More below... On 2010-08-09 22:17, Pascal Thubert (pthubert) wrote: > Hi Michael: > > With http://tools.ietf.org/html/draft-ietf-roll-rpl-07#section-7.2 I > tried to stay within the lines of RFC 3697 as you also defend in your > mail. > > I think the question we have now is not whether that proposal is lawful > but whether the new law being defined at 6MAN would prevent it in the > future. > If the updated rules allow, then I'll be glad to work on an FL-based > alternate to the IPinIP/HbH. So I understand that ROLL would definitely need the ability to define explicit semantics on the label. Would it also need the label to be mutable? > > It appeared at the 6MAN WG meeting that 12 bits mutable was exactly what > the core network was asking for to do its load balancing. > A first question to the group could be whether 12 mutable bits are > enough for the sensible usages envisioned so far? To me it seems that 12 bits could contain enough randomness to drive a load balancing mechanism, but there's no need for those bits to be mutable that I can see. On the other hand, 12 bits seems very small for any kind of nonce or for a flow identification scheme, so it seems that draft-blake and draft-donley would be knocked out. Brian > >> -----Original Message----- >> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On Behalf > Of >> Michael Richardson >> Sent: Wednesday, August 04, 2010 4:05 AM >> To: roll@ietf.org; Carsten Bormann >> Cc: Pascal Thubert (pthubert); ipv6@ietf.org >> Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable >> >> >> {there is a thread which started on roll@ietf.org, and ipv6@ietf.org, > and then >> seemed to have dropped roll@ietf.org. I'm not on ipv6@ietf.org, so > there likely >> are message there I've missed} >> >> okay, so I've read Carsen's opinion. >> I read RFC 3697 (which I didn't know about). >> >> draft-hu-flow-label-cases-00 is a very good read. I pull out > something from >> section 4 (Discussion); >> >> The other choice, for designers who wish to use the flow label to >> control switching or QoS directly, is to bypass the rules within a >> given domain (a set of cooperating nodes) in a way that nodes > outside >> the domain cannot detect. In this case, any deviation from > [RFC3697] >> has no possible effect outside the domain in question. >> >> I don't know where this subject line is from: 12 bits/8bits. >> Is there a draft that explains that idea that I've missed? >> >> My claim is that ROLL's RPL is a set of cooperating nodes. >> >> But, it's better than that --- it's a set of routers which are tuned > to support >> specific applications, and the applications want in this case to be > given >> information like, "what flow label" to use. RPL's RPLinstanceID has > all the >> properties required of a flow label (or, rather, it has no > requirements presently, >> and therefore can have the flow label requirements imposed upon it, >> specifically: >> 2. "Nodes MUST NOT assume any mathematical or other properties of >> the Flow Label" >> ) >> >> The non-mutability of the label isn't a problem either --- the > applications *AT >> EACH END*, even if one end of the application is several AS's away (a > very >> unusual case for 95% of RPL's target use), that application still > needs to know >> something about what label to use. >> >> There are three cases to consider: >> a) traffic between two RPL nodes >> b) traffic exiting an RPL >> c) traffic entering an RPL >> >> case (a) -- is the "set of cooperating nodes", and therefore is no > problem. >> case (b) -- the flow label is set to get through the RPL/LLN, and out > to >> the network, and the flow label has done it's job, and >> the RPL/LLN network could care less what happens to the > flow >> label at that point. The rest of the network might have > a >> problem (i.e. a bug) when RPL networks start sending >> non-zero flow labels, but that's the rest of the > network's >> problem. >> >> case (c) - flow labels of zero are not a problem. There is either a >> default RPLinstanceID to use (and traffic flows, perhaps not >> optimally), or there isn't (and ICMP Host unreachable > occurs). >> - non-zero flow labels which do not map to an RPLinstanceID, >> are simply considered zero, see above. >> - non-zero flow labels which map to RPLinstanceIDs are used. >> *If* it is a problem for outsiders to invoke that LLN's >> DODAG, then there are bigger issues, which the flow label > can neither >> help nor hinder --- the flowlabel is not a magic security > cookie. >> A firewall may still be required. >> >> The only real problem I can see is when a packet needs to do (b) and >> (c). e.g. use label A to exit LLN alpha, and label B to enter LLN > beta. >> I don't have a solution to this. Some have suggested IPIP tunnels, > which sound >> nice in theory, but in practice do not work in the wilderness found > behind the >> walls of walled gardens. >> >> -- >> ] 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. >> >> >> >> >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- > From remi.despres@free.fr Tue Aug 10 08:10:55 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADE353A67F8; Tue, 10 Aug 2010 08:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.541 X-Spam-Level: X-Spam-Status: No, score=-1.541 tagged_above=-999 required=5 tests=[AWL=0.408, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSAgs2oQDPLI; Tue, 10 Aug 2010 08:10:49 -0700 (PDT) Received: from smtp23.services.sfr.fr (smtp23.services.sfr.fr [93.17.128.20]) by core3.amsl.com (Postfix) with ESMTP id 40AE43A69EC; Tue, 10 Aug 2010 08:10:48 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2322.sfr.fr (SMTP Server) with ESMTP id 293677000093; Tue, 10 Aug 2010 17:11:18 +0200 (CEST) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2322.sfr.fr (SMTP Server) with ESMTP id 5D3A47000092; Tue, 10 Aug 2010 17:11:17 +0200 (CEST) X-SFR-UUID: 20100810151117381.5D3A47000092@msfrf2322.sfr.fr Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D027CCE7B@XMB-AMS-107.cisco.com> Date: Tue, 10 Aug 2010 17:11:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <097F191C-3E28-48E3-AAAF-81730D2A49FD@free.fr> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <48421D4F-0E73-4192-88EA-D7C6672768F5@free.fr> <6A2A459175DABE4BB11DE2026AA50A5D027CCE7B@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Sun, 15 Aug 2010 14:43:40 -0700 Cc: Carsten Bormann , roll@ietf.org, 6man 6man Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 15:10:55 -0000 Hi Pascal, More comments below. Le 10 ao=FBt 2010 =E0 16:24, Pascal Thubert (pthubert) a =E9crit : > Salut R=E9mi, >=20 > Please see below: >=20 > Pascal >=20 >> -----Original Message----- >> From: R=E9mi Despr=E9s [mailto:remi.despres@free.fr] >> Sent: Monday, August 09, 2010 1:50 PM >> To: Pascal Thubert (pthubert) >> Cc: 6man 6man; Michael Richardson; roll@ietf.org; Carsten Bormann >> Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable >>=20 >>=20 >> Le 9 ao=FBt 2010 =E0 12:17, Pascal Thubert (pthubert) a =E9crit : >>=20 >>> Hi Michael: >>>=20 >>> With http://tools.ietf.org/html/draft-ietf-roll-rpl-07#section-7.2 I >>> tried to stay within the lines of RFC 3697 as you also defend in = your >>> mail. >>>=20 >>> I think the question we have now is not whether that proposal is >>> lawful but whether the new law being defined at 6MAN would prevent = it >>> in the future. >>> If the updated rules allow, then I'll be glad to work on an FL-based >>> alternate to the IPinIP/HbH. >>>=20 >>> It appeared at the 6MAN WG meeting that 12 bits mutable was exactly >>> what the core network was asking for to do its load balancing. >>=20 >> Would you have more details on WHY it would be "exactly" what was = needed >> (???) ? >=20 > [Pascal] That does not come from me. I asked at the mike during the WG = meeting, and the answer that was given was that for the purpose of a = load balancing hash in the SP network, 11 or 12 bits would be enough. What is clear, though, is that a hash of 11-12 bits has a higher = probability of collisions than a hash on 20 bits. If hashes become permitted (which simplifies support of FLs for load = balancing), it is then clear that 20 is better than 12. >>> A first question to the group could be whether 12 mutable bits are >>> enough for the sensible usages envisioned so far? >>=20 >> I'd rather see the first question as being "Are there some = improvements of RFC >> 3697 that would make it practicable?". >>=20 >> If yes, improving this RFC rather than deprecating it after 6+ years = of standard- >> track existence would IMHO be better for IPv6 credibility (and IMHO = for that of >> IETF in general). >>=20 >> The two improvements that seem to make sense (see various exchanged = mails) >> are: >> - permit stateless support (with flow-ID hashes in place of = flow-based stateful >> processing) >> - permit intermediate nodes to set FLs when source hosts haven't done = it (still >> as shorthands for flow ISs made available in IPv6 first headers). >>=20 > [Pascal] We agree here. The point if that there might be enough room = for both, depending on what we are doing. > Note that for the latter, the discussion was also that it is not = obvious at the egress of the network to reset the FL to zero in order to = enable the next AS to reuse it. RFC 3697 isn't concerned with ASes, and doesn't need to be. The proposal is only that, where load balancing is performed, 0 FLs MAY = be replaced by meaningful values for this purpose. A FL, once set to a non 0 value, never needs to be reset. > So the conclusion was rather to use the bits is a DSCP fashion. I am not sure what is meant by used in a DSCP fashion (some DSCP actual = uses seem to me rather complex). In any case, using FLs ONLY as FLs (essentially RFC 3697, but completed = to be more practicable), is IMHO the most reasonable approach to improve = the situation in a reasonable timeframe. I understand that 20 unused bits in IP headers is bound to arouse envy, = but adding a new role to FLs, with the original role becoming less = efficient rather than more efficient, is IMHO a wrong approach.=20 Cheers, RD >=20 > Pascal >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: ipv6-bounces@ietf.org [mailto:ipv6-bounces@ietf.org] On = Behalf >>> Of >>>> Michael Richardson >>>> Sent: Wednesday, August 04, 2010 4:05 AM >>>> To: roll@ietf.org; Carsten Bormann >>>> Cc: Pascal Thubert (pthubert); ipv6@ietf.org >>>> Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable >>>>=20 >>>>=20 >>>> {there is a thread which started on roll@ietf.org, and = ipv6@ietf.org, >>> and then >>>> seemed to have dropped roll@ietf.org. I'm not on ipv6@ietf.org, so >>> there likely >>>> are message there I've missed} >>>>=20 >>>> okay, so I've read Carsen's opinion. >>>> I read RFC 3697 (which I didn't know about). >>>>=20 >>>> draft-hu-flow-label-cases-00 is a very good read. I pull out >>> something from >>>> section 4 (Discussion); >>>>=20 >>>> The other choice, for designers who wish to use the flow label to >>>> control switching or QoS directly, is to bypass the rules within a >>>> given domain (a set of cooperating nodes) in a way that nodes >>> outside >>>> the domain cannot detect. In this case, any deviation from >>> [RFC3697] >>>> has no possible effect outside the domain in question. >>>>=20 >>>> I don't know where this subject line is from: 12 bits/8bits. >>>> Is there a draft that explains that idea that I've missed? >>>>=20 >>>> My claim is that ROLL's RPL is a set of cooperating nodes. >>>>=20 >>>> But, it's better than that --- it's a set of routers which are = tuned >>> to support >>>> specific applications, and the applications want in this case to be >>> given >>>> information like, "what flow label" to use. RPL's RPLinstanceID = has >>> all the >>>> properties required of a flow label (or, rather, it has no >>> requirements presently, >>>> and therefore can have the flow label requirements imposed upon it, >>>> specifically: >>>> 2. "Nodes MUST NOT assume any mathematical or other properties of >>>> the Flow Label" >>>> ) >>>>=20 >>>> The non-mutability of the label isn't a problem either --- the >>> applications *AT >>>> EACH END*, even if one end of the application is several AS's away = (a >>> very >>>> unusual case for 95% of RPL's target use), that application still >>> needs to know >>>> something about what label to use. >>>>=20 >>>> There are three cases to consider: >>>> a) traffic between two RPL nodes >>>> b) traffic exiting an RPL >>>> c) traffic entering an RPL >>>>=20 >>>> case (a) -- is the "set of cooperating nodes", and therefore is no >>> problem. >>>>=20 >>>> case (b) -- the flow label is set to get through the RPL/LLN, and = out >>> to >>>> the network, and the flow label has done it's job, and >>>> the RPL/LLN network could care less what happens to the >>> flow >>>> label at that point. The rest of the network might have >>> a >>>> problem (i.e. a bug) when RPL networks start sending >>>> non-zero flow labels, but that's the rest of the >>> network's >>>> problem. >>>>=20 >>>> case (c) - flow labels of zero are not a problem. There is either = a >>>> default RPLinstanceID to use (and traffic flows, perhaps not >>>> optimally), or there isn't (and ICMP Host unreachable >>> occurs). >>>>=20 >>>> - non-zero flow labels which do not map to an RPLinstanceID, >>>> are simply considered zero, see above. >>>> - non-zero flow labels which map to RPLinstanceIDs are used. >>>> *If* it is a problem for outsiders to invoke that LLN's >>>> DODAG, then there are bigger issues, which the flow label >>> can neither >>>> help nor hinder --- the flowlabel is not a magic security >>> cookie. >>>> A firewall may still be required. >>>>=20 >>>> The only real problem I can see is when a packet needs to do (b) = and >>>> (c). e.g. use label A to exit LLN alpha, and label B to enter LLN >>> beta. >>>>=20 >>>> I don't have a solution to this. Some have suggested IPIP tunnels, >>> which sound >>>> nice in theory, but in practice do not work in the wilderness found >>> behind the >>>> walls of walled gardens. >>>>=20 >>>> -- >>>> ] 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. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> = -------------------------------------------------------------------- >>>> IETF IPv6 working group mailing list >>>> ipv6@ietf.org >>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>>> = -------------------------------------------------------------------- >>> -------------------------------------------------------------------- >>> IETF IPv6 working group mailing list >>> ipv6@ietf.org >>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >>> -------------------------------------------------------------------- >>=20 >=20 From cabocabo@gmail.com Tue Aug 10 09:04:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E470F3A691A; Tue, 10 Aug 2010 09:04:03 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zqXGp0vwYc+S; Tue, 10 Aug 2010 09:04:03 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 7781F3A68FB; Tue, 10 Aug 2010 09:04:02 -0700 (PDT) Received: by bwz10 with SMTP id 10so2638349bwz.31 for ; Tue, 10 Aug 2010 09:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=BKnnpJLH8q4VTnZqYfykp2Oj5Qpi5d6xAwDl+T9/m40=; b=vb3IEs/W7TYnIatlB9wln3ztfToEhB4A9GFL89xfnxFMb91DCbL96v5B1DcGiXa4Y6 qsbjj2cYAIG43ZyNxsw+Drv2gTTCjVdAlYCYjH9NccuUZlmpZPIRhmuOZ9Ycu+9F0qGF URnU3Y0ZyYAiu9MmanZcV0sCzfMNbqdKC0Qek= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=DK78w776/mBX7z2vxdZUiETqP2z/7IRd4NndNEuDXzKTAnt1iCzCHiQlqy8uXvCvsc Xb8fiEVt1wrF1SKTkNQNzrTqygyNUe7zGPKwaX6SWxNl8E8OoYQnggtx66o2eWfflPyZ ULqwHY+Io8JP6F1ruVU9tSsCi6QHxAwMgPxJk= Received: by 10.204.119.134 with SMTP id z6mr4280835bkq.193.1281456277194; Tue, 10 Aug 2010 09:04:37 -0700 (PDT) Received: from [192.168.217.101] (p5489F689.dip.t-dialin.net [84.137.246.137]) by mx.google.com with ESMTPS id x13sm3777703bki.12.2010.08.10.09.04.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 10 Aug 2010 09:04:36 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <23319.1281445020@marajade.sandelman.ca> Date: Tue, 10 Aug 2010 18:04:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <23319.1281445020@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Sun, 15 Aug 2010 14:43:40 -0700 Cc: roll@ietf.org, ipv6@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 16:04:04 -0000 On Aug 10, 2010, at 14:57, Michael Richardson wrote: > The only case where there is a problem is when there is a packet that > arrives from the outside, to a ROLL "border router" (we don't have = such > a term in ROLL. The ROLL term would be grounded DODAG root). I haven't yet quite found out whether RPL tries to be useful for = networks with hosts, but if it does, the same kind if problem would = occur when a host sets the flow label. Gruesse, Carsten From cabocabo@gmail.com Tue Aug 10 09:15:45 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 259653A67F3; Tue, 10 Aug 2010 09:15:45 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fvs2H+uUc-r0; Tue, 10 Aug 2010 09:15:43 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id 4CADA3A6A03; Tue, 10 Aug 2010 09:15:43 -0700 (PDT) Received: by fxm18 with SMTP id 18so891775fxm.31 for ; Tue, 10 Aug 2010 09:16:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=HxCUT5ZP/LdNscvj9o3xZRHU2pnw+bdzqCoTuVWas5Q=; b=cSgo8eWk9gxfejzonkf6CHs90hxAEwAFChiI6Z56v/Nx/ml7HpbXaCGeVUm4HK7q1R 6U9NEdcmgmwT+0eW6mncd2YTCUfWNqY4OTYF9yW0K82+Zibz7W4DseIJ6D29O4hyZard WefaiVMPFIBcKmvrlr7EFnqeeoiFMUk4NnFGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=PAMlxLbyY40FiIu0cB4seostov8wxlZimWYLGPYEHmqhffG8V/AnSRo+VCNeobSr3k 67E4xChkIti/W0LjbTcuMKHgeF6wsGiNPV8ArgqglnUePX7G/OgW5jmdLzHnCPu7n2I8 fL/zHO069W6Gd6P/V3S+WANjXbq9T95jGJLzc= Received: by 10.223.105.197 with SMTP id u5mr18518700fao.14.1281456978056; Tue, 10 Aug 2010 09:16:18 -0700 (PDT) Received: from [192.168.217.101] (p5489F689.dip.t-dialin.net [84.137.246.137]) by mx.google.com with ESMTPS id 1sm1437611fas.2.2010.08.10.09.16.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 10 Aug 2010 09:16:17 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <23319.1281445020@marajade.sandelman.ca> Date: Tue, 10 Aug 2010 18:16:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <23319.1281445020@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Sun, 15 Aug 2010 14:43:40 -0700 Cc: roll@ietf.org, ipv6@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 16:15:45 -0000 On Aug 10, 2010, at 14:57, Michael Richardson wrote: > The rational for lots of bits would be to > encourage random allocation such that in the event that two > uncoordinated ROLL networks happened to merge (even for a few > minutes!!!) that the likelyhood of cross talk would be reduced. Hmm. If this is intended as a routine way to handle the situation, the = likelihood is still way to high. (If this is just intended as a mitigation to increase robustness in a = case that already is an error situation that is being actively avoided = by other means, your argument might be more interesting.) > A merge like I describe here is not directly envisaged by the current > set of requirements in my opinion, but I think that requirement will > emerge in the future. DANGER. Adding complexity to a protocol to cater for requirements that = don't exist yet leads to convoluted solutions. Never do that. (Note that this situation is different from the selection of one out of = a set of same-complexity alternatives, where it is quite useful to = conjecture about potential future requirements to generate a tie = breaker. Note also that extensibility by itself is a known current = requirement for any protocol, which is quite different from designing in = all conceivable future extensions.) Gruesse, Carsten From cabocabo@gmail.com Tue Aug 10 11:21:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B6E5E3A6AA2; Tue, 10 Aug 2010 11:21:28 -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=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8jr3YqPDRSWJ; Tue, 10 Aug 2010 11:21:27 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 6F53A3A67C3; Tue, 10 Aug 2010 11:21:27 -0700 (PDT) Received: by bwz10 with SMTP id 10so2750362bwz.31 for ; Tue, 10 Aug 2010 11:22:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=zTdmCIkN0SUGrxzBU+OQxmyMTmsCFv+YQ6gTw1EhmNQ=; b=rzdNuPNyw2joiLCrHi6PQI4+2Jwv/J7K/1Ot30eQ+EX3mitnkwEn8wIQZYeTrAdH7l AQA0btOLr+pOz8SXG3gKzZ5avf2z+eSjUfBlsKWa6/1B4bKrIuB3grjezXBhEj97IEUs kQXhr47FDmmlPbUwEAAFRkYyG8tR/8uT9tHhk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=qe7meFzEGM7RNaTcOnQtjEjBxp7uDxLORshJgubtImDhBYjZqhbuW3elQX2wvwZQ/8 j/Mqcd1TVwL9aBK0fKA5CQuXhtCg4ld9rN42HTBde2pv2BcTbqauweSV7yOLapsKyjTQ rdnXW2pRplFwSULndA9xsTTbu79he8CXMY40Y= Received: by 10.204.153.10 with SMTP id i10mr4399812bkw.1.1281464521849; Tue, 10 Aug 2010 11:22:01 -0700 (PDT) Received: from [192.168.217.101] (p5489F689.dip.t-dialin.net [84.137.246.137]) by mx.google.com with ESMTPS id a9sm4429257bky.11.2010.08.10.11.21.58 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 10 Aug 2010 11:22:00 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Carsten Bormann In-Reply-To: <1723.1281457687@marajade.sandelman.ca> Date: Tue, 10 Aug 2010 20:21:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <23319.1281445020@marajade.sandelman.ca> <1723.1281457687@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Sun, 15 Aug 2010 14:43:40 -0700 Cc: roll@ietf.org, ipv6@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 18:21:28 -0000 > RPL networks consists of leafs and routers. Both typically act as = hosts. > Routers are just hosts that happen to be between other nodes. > (Although, some hosts are too weak to be routers) OK, I'm not talking of "host" as in originates or terminates traffic, = but "host" in the sense of "does not participate in routing". It appears there is no such thing inside a RPL world then. (Note that the traditional usage I'm using here is slightly different = from the definition used in RFC2460, which says "does not forward" -- = the old 1980's "hosts with RIP routing" would be hosts in RFC2460, but = we have learned not to like these monsters. That's why IPv6 has a = separate ES-IS protocol called ND.) > Little to no traffic on the RPL is unaware of which RPLinstanceID to > use, because the applications there needs to send using a specific set > of constraints, which is encapsulated into the RPLinstanceID. Hosts (as in "don't participate in routing") would have little idea of = such concepts. What you are describing is somehow surprisingly remote from IP. In IP, hosts send packets to an IP address. Sometimes there are additional considerations, which we so far have been = addressing [sic] with the TOS byte, i.e., the DSCP today. I don't understand yet why RPL needs a different concept. (Note that Phil's point is also valid, but mostly orthogonal to mine.) Gruesse, Carsten From fred@cisco.com Tue Aug 10 12:06:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D651C3A686D; Tue, 10 Aug 2010 12:06:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.189 X-Spam-Level: X-Spam-Status: No, score=-110.189 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqNSieuBOCFN; Tue, 10 Aug 2010 12:06:34 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 485973A6840; Tue, 10 Aug 2010 12:06:34 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,349,1278288000"; d="scan'208";a="170156489" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 10 Aug 2010 19:07:09 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7AJ71Ep004290; Tue, 10 Aug 2010 19:07:03 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 10 Aug 2010 12:07:09 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 10 Aug 2010 12:07:09 -0700 Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: <987.1281456566@marajade.sandelman.ca> Date: Tue, 10 Aug 2010 12:06:54 -0700 Message-Id: <357087A8-7FD7-4696-88CA-F7D8E41209EE@cisco.com> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <48421D4F-0E73-4192-88EA-D7C6672768F5@free.fr> <6A2A459175DABE4BB11DE2026AA50A5D027CCE7B@XMB-AMS-107.cisco.com> <097F191C-3E28-48E3-AAAF-81730D2A49FD@free.fr> <987.1281456566@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 15 Aug 2010 14:43:40 -0700 Cc: =?us-ascii?Q?=3D=3Fiso-8859-1=3FQ=3FR=3DE9mi=5FDespr=3DE9s=3F=3D?= , 6man 6man , roll@ietf.org, Carsten Bormann Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 19:06:36 -0000 I would find that surprising. There are ample cases where the originator = of a high data rate flow (sensor data from a radio telescope to a number = cruncher, to pick one example) might want to use the flow label to send = data from one session down multiple paths. Multi-path TCP would be = another example. I suppose you could argue that consistently alternating = among N flow labels can be thought of as N separate flows, but if it's = TCP there are other ramifications. In any event, the requirement of the load balancer is not that the = originator gives things a tag; we can develop such tags from a hash of = the source and destination address quite well, thanks. The important = thing is that things are tagged in a manner that helps the load = balancer. There are two major uses of load balancers. In data centers, = we balance sessions to/from sets of servers, and the question when a new = session comes up is which server is most likely to be able to = effectively serve it (has the necessary resources including access to = the right disks, CPU cycles, etc). In bandwidth allocation uses = (spreading load across multiple otherwise-equivalent paths), the = question is how to use each of the paths most effectively - we want some = traffic on each of them and we want none of the paths to be overloaded = or introducing more delay or loss than others. Everyone's instinctive = knee-jerk response to the question seems to be "hash something and = depend on the law of large numbers to serve the need", and the = observation of numerous operators is that the law of large numbers is a = good start but is not an adequate solution. You really want the load = balancer to be able to be smarter than that. Which is why people that build load balancers frequently do so using NAT = technology or some other way of tagging individual sessions. And why = they are looking for mutable flow labels in this thread. On Aug 10, 2010, at 9:09 AM, Michael Richardson wrote: >=20 >>>>>> "R=E9mi" =3D=3D R=E9mi Despr=E9s writes: > R=E9mi> RFC 3697 isn't concerned with ASes, and doesn't need to be. > R=E9mi> The proposal is only that, where load balancing is = performed,=20 > R=E9mi> 0 FLs MAY be replaced by meaningful values for this = purpose. =20 > R=E9mi> A FL, once set to a non 0 value, never needs to be reset. >=20 > okay, so what you are saying is that load balancing uses of the FL are > only upset when they see zero. So for instance, if layer-4s (i.e. end > points) were mandated that they must now always set a FL consistently = on > a flow, and set it to a non-zero value, that this would satisfy the > requirements of load balancers. >=20 > In this context, permission would be given to set zero FL to a = non-zero > value.=20 >=20 > --=20 > ] 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.=20 > -------------------------------------------------------------------- > IETF IPv6 working group mailing list > ipv6@ietf.org > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 > -------------------------------------------------------------------- http://www.ipinc.net/IPv4.GIF From fred@cisco.com Tue Aug 10 13:53:09 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB3D83A67B1; Tue, 10 Aug 2010 13:53:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.201 X-Spam-Level: X-Spam-Status: No, score=-110.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HWnddNCbcjFK; Tue, 10 Aug 2010 13:53:08 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 9F06B3A65A6; Tue, 10 Aug 2010 13:53:08 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAtZYUyrR7Ht/2dsb2JhbACgLHGiWptMhToEhCaFGg X-IronPort-AV: E=Sophos;i="4.55,349,1278288000"; d="scan'208";a="238491224" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 10 Aug 2010 20:53:44 +0000 Received: from stealth-10-32-244-218.cisco.com (stealth-10-32-244-218.cisco.com [10.32.244.218]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7AKrZak021484; Tue, 10 Aug 2010 20:53:37 GMT Received: from [127.0.0.1] by stealth-10-32-244-218.cisco.com (PGP Universal service); Tue, 10 Aug 2010 13:53:44 -0700 X-PGP-Universal: processed; by stealth-10-32-244-218.cisco.com on Tue, 10 Aug 2010 13:53:44 -0700 Mime-Version: 1.0 (Apple Message framework v1081) From: Fred Baker In-Reply-To: Date: Tue, 10 Aug 2010 13:53:29 -0700 Message-Id: <645C41BE-BDB5-4D09-891A-9640FD1165AE@cisco.com> References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <23319.1281445020@marajade.sandelman.ca> <1723.1281457687@marajade.sandelman.ca> To: Carsten Bormann X-Mailer: Apple Mail (2.1081) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 15 Aug 2010 14:43:40 -0700 Cc: roll@ietf.org, ipv6@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 20:53:09 -0000 On Aug 10, 2010, at 11:21 AM, Carsten Bormann wrote: > OK, I'm not talking of "host" as in originates or terminates traffic, = but "host" in the sense of "does not participate in routing". > It appears there is no such thing inside a RPL world then. A RPL or Manet world doesn't have the 1970's-mentality limitation that = hosts have to be stupid. Of all networking architectures, the Internet = is the only one with that delusion. http://www.ipinc.net/IPv4.GIF From ipng@69706e6720323030352d30312d31340a.nosense.org Tue Aug 10 14:40:06 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F37FE28C0E5; Tue, 10 Aug 2010 14:40:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=0.306, BAYES_00=-2.599, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFy3n2je7r+N; Tue, 10 Aug 2010 14:40:05 -0700 (PDT) Received: from smtp3.adam.net.au (smtp3.adam.net.au [202.136.110.249]) by core3.amsl.com (Postfix) with ESMTP id B209428C0E6; Tue, 10 Aug 2010 14:40:04 -0700 (PDT) Received: from 219-90-255-65.ip.adam.com.au ([219.90.255.65] helo=opy.nosense.org) by smtp3.adam.net.au with esmtp (Exim 4.63) (envelope-from ) id 1OiwYi-0003xf-Ok; Wed, 11 Aug 2010 07:10:32 +0930 Received: from opy.nosense.org (localhost.localdomain [IPv6:::1]) by opy.nosense.org (Postfix) with ESMTP id 02EC63B31E; Wed, 11 Aug 2010 07:09:36 +0930 (CST) Date: Wed, 11 Aug 2010 07:09:34 +0930 From: Mark Smith To: "Pascal Thubert (pthubert)" Message-ID: <20100811070934.228760dd@opy.nosense.org> In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D027CCE7B@XMB-AMS-107.cisco.com> References: <4C50463E.7070107@tut.fi> <6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com> <14567.1280409076@marajade.sandelman.ca> <80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <48421D4F-0E73-4192-88EA-D7C6672768F5@free.fr> <6A2A459175DABE4BB11DE2026AA50A5D027CCE7B@XMB-AMS-107.cisco.com> X-Mailer: Claws Mail 3.7.6 (GTK+ 2.20.1; x86_64-unknown-linux-gnu) X-Location: Lower Mitcham, South Australia, 5062 Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 15 Aug 2010 14:43:40 -0700 Cc: 6man 6man , =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , roll@ietf.org, Michael, Carsten Bormann Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 21:40:06 -0000 Hi Pascal, On Tue, 10 Aug 2010 16:24:42 +0200 "Pascal Thubert (pthubert)" wrote: > Salut R=C3=A9mi, >=20 > Please see below: >=20 > Pascal >=20 > > -----Original Message----- > > From: R=C3=A9mi Despr=C3=A9s [mailto:remi.despres@free.fr] > > Sent: Monday, August 09, 2010 1:50 PM > > To: Pascal Thubert (pthubert) > > Cc: 6man 6man; Michael Richardson; roll@ietf.org; Carsten Bormann > > Subject: Re: Flow Label: 12 bits mutable and 8 bits immutable > >=20 > >=20 > > Le 9 ao=C3=BBt 2010 =C3=A0 12:17, Pascal Thubert (pthubert) a =C3=A9cri= t : > >=20 > > > Hi Michael: > > > > >=20 > [Pascal] We agree here. The point if that there might be enough room for = both, depending on what we are doing. > Note that for the latter, the discussion was also that it is not obvious = at the egress of the network to reset the FL to zero in order to enable the= next AS to reuse it. So the conclusion was rather to use the bits is a DSC= P fashion. >=20 The DSCP domain model use was my inspiration when I originally suggested the idea of having flow domains. If the flow label stays mutable in the network, the issue with the mandatory resetting to zero idea is that downstream domains probably aren't going to trust upstream domains to always do it - so they'll probably choose to do it themselves anyway. Which is similar to how upstream DSCP values are or rather aren't trusted. One use of IPv4 DSCP I've seen in the past was to label or classify packets for billing purposes. I disagreed with using DSCP for that, because it is specifically for QoS use. It seems to me that the IPv6 flow label field is or could be a more general purpose field, and if that DSCP labelling idea had been carried forward to IPv6, would be the field to use for it. Regards, Mark. From brian.e.carpenter@gmail.com Tue Aug 10 14:52:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85D6F3A6842; Tue, 10 Aug 2010 14:52:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.79 X-Spam-Level: X-Spam-Status: No, score=-102.79 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vGJpb+syAFYN; Tue, 10 Aug 2010 14:52:33 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 1F3B03A682F; Tue, 10 Aug 2010 14:52:32 -0700 (PDT) Received: by ewy22 with SMTP id 22so4701330ewy.31 for ; Tue, 10 Aug 2010 14:53:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=3ETAh/ELNQ7+yAUpS+v0vRJJgkxp4YNrsGzwgLBV8ns=; b=mqsaUlx1XwErYKeAVyfoKKhZmkjrAX/mjHhdyZ5InfqBVDA+uPoIa7qICmd37U2MOA DpQ34K2Xdhs4YX2DR/n85yUa3p1C66hHX/3UE4hCt/JUTZz17RCDLJ9wnDBd3FUou6at 9Qs3njcIZOybf1UomlF7MkWqfO2GUmvssnBfg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=pFJLGYDeT0CieS6EfKKi3u8IrFmoSBZdSZgGFpclCD4L8fbFXZ+21DrHlgf18Zm04E fFBV+nM4+V7WC6PuV7G/QKnsSVwOyPkJqvOyZApXUR/gT9zY0udRutS3BkvlyicvXtg5 22nqY9PN+65osXSFVpkRRuTUfNWyZYDKLnANQ= Received: by 10.213.28.194 with SMTP id n2mr4877949ebc.10.1281477188118; Tue, 10 Aug 2010 14:53:08 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id u9sm10495575eeh.5.2010.08.10.14.53.04 (version=SSLv3 cipher=RC4-MD5); Tue, 10 Aug 2010 14:53:07 -0700 (PDT) Message-ID: <4C61CA3D.80807@gmail.com> Date: Wed, 11 Aug 2010 09:53:01 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Fred Baker References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <23319.1281445020@marajade.sandelman.ca> <1723.1281457687@marajade.sandelman.ca> <645C41BE-BDB5-4D09-891A-9640FD1165AE@cisco.com> In-Reply-To: <645C41BE-BDB5-4D09-891A-9640FD1165AE@cisco.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Sun, 15 Aug 2010 14:43:40 -0700 Cc: Carsten Bormann , roll@ietf.org, ipv6@ietf.org Subject: [Roll] ROLL choice to not use the Flow Label X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Aug 2010 21:52:34 -0000 Thanks for all the enlightment about ROLL. My personal conclusion is that the ROLL considerations are too complex and too subtle to be compatible with using a general-purpose IPv6 header field (i.e. the flow label) for ROLL purposes. They seem to be an extreme case of the challenges of defining a local-use regime for the flow label, which have already been a stumbling block for the various versions of draft-carpenter-6man-flow-update. So IMHO, ROLL/RPL was quite wise to drop the IPv6 header flow label proposal. Brian On 2010-08-11 08:53, Fred Baker wrote: > On Aug 10, 2010, at 11:21 AM, Carsten Bormann wrote: > >> OK, I'm not talking of "host" as in originates or terminates traffic, but "host" in the sense of "does not participate in routing". >> It appears there is no such thing inside a RPL world then. > > A RPL or Manet world doesn't have the 1970's-mentality limitation that hosts have to be stupid. Of all networking architectures, the Internet is the only one with that delusion. > > http://www.ipinc.net/IPv4.GIF > > From remi.despres@free.fr Tue Aug 10 23:12:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0D7173A6A08; Tue, 10 Aug 2010 23:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.565 X-Spam-Level: X-Spam-Status: No, score=-1.565 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KopbCFDW8Rg8; Tue, 10 Aug 2010 23:12:02 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by core3.amsl.com (Postfix) with ESMTP id A22DC3A6A07; Tue, 10 Aug 2010 23:12:01 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id 2961A7000089; Wed, 11 Aug 2010 08:12:37 +0200 (CEST) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id 9D69B7000086; Wed, 11 Aug 2010 08:12:36 +0200 (CEST) X-SFR-UUID: 20100811061236644.9D69B7000086@msfrf2109.sfr.fr Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <987.1281456566@marajade.sandelman.ca> Date: Wed, 11 Aug 2010 08:12:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <48421D4F-0E73-4192-88EA-D7C6672768F5@free.fr> <6A2A459175DABE4BB11DE2026AA50A5D027CCE7B@XMB-AMS-107.cisco.com> <097F191C-3E28-48E3-AAAF-81730D2A49FD@free.fr> <987.1281456566@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Sun, 15 Aug 2010 14:43:40 -0700 Cc: Carsten Bormann , 6man 6man , roll@ietf.org Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 06:12:03 -0000 Le 10 ao=FBt 2010 =E0 18:09, Michael Richardson a =E9crit : >=20 >>>>>> "R=E9mi" =3D=3D R=E9mi Despr=E9s writes: > R=E9mi> RFC 3697 isn't concerned with ASes, and doesn't need to be. > R=E9mi> The proposal is only that, where load balancing is = performed,=20 > R=E9mi> 0 FLs MAY be replaced by meaningful values for this = purpose. =20 > R=E9mi> A FL, once set to a non 0 value, never needs to be reset. >=20 > okay, so what you are saying is that load balancing uses of the FL are > only upset when they see zero. So for instance, if layer-4s (i.e. end > points) were mandated that they must now always set a FL consistently = on > a flow, and set it to a non-zero value, that this would satisfy the > requirements of load balancers. Right. To be even more precise:=20 - Flow endpoints (sometimes layer 4 and sometimes layer 3) should from = now on be mandated to set FLs with non-0 values that statistically = differ from a flow to another. - However, we have to face that, so far, they are generally mandated to = set FLs to 0. - To mitigate the negative effect of this fact on uses of FLs as = heuristic flow discriminants, intermediate nodes may replace 0 values by = values that statistically differ from a flow to another. Note also that intermediate nodes typically don't reassemble = multi-packet datagrams.=20 In this common case, they can only identify the IPv6 flow of a packet = based on its two addresses and its next header.=20 Setting the FL with a hash of this ID is still useful for downstream = nodes to be able to use it (rather than treating the packet as if in the = carryall set of 0-FL packets, or having to recompute its flow ID).=20 Regards, RD >=20 > In this context, permission would be given to set zero FL to a = non-zero > value.=20 >=20 > --=20 > ] 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.=20 From remi.despres@free.fr Wed Aug 11 00:06:22 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4792E3A68C8; Wed, 11 Aug 2010 00:06:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.586 X-Spam-Level: X-Spam-Status: No, score=-1.586 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DZMD22iejZ5; Wed, 11 Aug 2010 00:06:21 -0700 (PDT) Received: from smtp21.services.sfr.fr (smtp21.services.sfr.fr [93.17.128.2]) by core3.amsl.com (Postfix) with ESMTP id BECAB3A6A20; Wed, 11 Aug 2010 00:06:20 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id 05E417000093; Wed, 11 Aug 2010 09:06:56 +0200 (CEST) Received: from [192.168.0.20] (per92-10-88-166-221-144.fbx.proxad.net [88.166.221.144]) by msfrf2109.sfr.fr (SMTP Server) with ESMTP id 6818E7000089; Wed, 11 Aug 2010 09:06:55 +0200 (CEST) X-SFR-UUID: 20100811070655426.6818E7000089@msfrf2109.sfr.fr Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <357087A8-7FD7-4696-88CA-F7D8E41209EE@cisco.com> Date: Wed, 11 Aug 2010 09:06:54 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <48421D4F-0E73-4192-88EA-D7C6672768F5@free.fr> <6A2A459175DABE4BB11DE2026AA50A5D027CCE7B@XMB-AMS-107.cisco.com> <097F191C-3E28-48E3-AAAF-81730D2A49FD@free.fr> <987.1281456566@marajade.sandelman.ca> <357087A8-7FD7-4696-88CA-F7D8E41209EE@cisco.com> To: Fred Baker X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Sun, 15 Aug 2010 14:43:40 -0700 Cc: Carsten Bormann , roll@ietf.org, 6man 6man Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Aug 2010 07:06:22 -0000 Le 10 ao=FBt 2010 =E0 21:06, Fred Baker a =E9crit : > I would find that surprising. There are ample cases where the = originator of a high data rate flow (sensor data from a radio telescope = to a number cruncher, to pick one example) might want to use the flow = label to send data from one session down multiple paths. Multi-path TCP = would be another example. > I suppose you could argue that consistently alternating among N flow = labels can be thought of as N separate flows, but if it's TCP there are = other ramifications. Packets that are expected to go down multiple paths should be identified = as belonging to different flows as far as FLs are concerned. In the case of multi-path TCP, where "one or both peers are expected to = have multiple addresses", this is already the case: different paths are = taken by packets of different MPTCP "subflows", i.e. packets having = different 5-tuples. >=20 > In any event, the requirement of the load balancer is not that the = originator gives things a tag; we can develop such tags from a hash of = the source and destination address quite well, thanks. Originators of TCP and UDP connections should clearly hash 5-tuples when = they exist (not 2-tuples in this case as you seem to assume). > The important thing is that things are tagged in a manner that helps = the load balancer. Agreed. > There are two major uses of load balancers. > In data centers, we balance sessions to/from sets of servers, and the = question when a new session comes up is which server is most likely to = be able to effectively serve it (has the necessary resources including = access to the right disks, CPU cycles, etc). In bandwidth allocation = uses (spreading load across multiple otherwise-equivalent paths), the = question is how to use each of the paths most effectively - we want some = traffic on each of them and we want none of the paths to be overloaded = or introducing more delay or loss than others. Everyone's instinctive = knee-jerk response to the question seems to be "hash something and = depend on the law of large numbers to serve the need", and the = observation of numerous operators is that the law of large numbers is a = good start but is not an adequate solution. "Hash something" (and possibly a 2-tuple even when a 5-tuple is = available) is clearly not as good as "hash 5 tuples if available", which = I propose to become a SHOULD. Taking a "good start" as starting point, and trying to improve from = there, is what I try to propose. =20 > You really want the load balancer to be able to be smarter than that. >=20 > Which is why people that build load balancers frequently do so using = NAT technology or some other way of tagging individual sessions. Are you arguing in favor of NATs in IPv6, adding load balancing as a = reason to use them :-(? As a convinced promoter of IPv6, and of its restored e2e transparency, I = find that IPv6 load balancing solutions that don't need NATs are worth = specifying. > And why they are looking for mutable flow labels in this thread. I don't see why 0-FL mutability wouldn't be sufficient for them = (provided new values must statistically different for different flows, = including subflows, micro-flows, whatever can be identified). But more data on what would be their problem are most welcome.=20 Regards, RD =20 >=20 > On Aug 10, 2010, at 9:09 AM, Michael Richardson wrote: >=20 >>=20 >>>>>>> "R=E9mi" =3D=3D R=E9mi Despr=E9s writes: >> R=E9mi> RFC 3697 isn't concerned with ASes, and doesn't need to be. >> R=E9mi> The proposal is only that, where load balancing is = performed,=20 >> R=E9mi> 0 FLs MAY be replaced by meaningful values for this = purpose. =20 >> R=E9mi> A FL, once set to a non 0 value, never needs to be reset. >>=20 >> okay, so what you are saying is that load balancing uses of the FL = are >> only upset when they see zero. So for instance, if layer-4s (i.e. = end >> points) were mandated that they must now always set a FL consistently = on >> a flow, and set it to a non-zero value, that this would satisfy the >> requirements of load balancers. >>=20 >> In this context, permission would be given to set zero FL to a = non-zero >> value.=20 >>=20 >> --=20 >> ] 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.=20 >> -------------------------------------------------------------------- >> IETF IPv6 working group mailing list >> ipv6@ietf.org >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 >> -------------------------------------------------------------------- >=20 > http://www.ipinc.net/IPv4.GIF >=20 From brian.e.carpenter@gmail.com Wed Aug 11 19:02:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D02C83A67A4; Wed, 11 Aug 2010 19:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.782 X-Spam-Level: X-Spam-Status: No, score=-102.782 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bRHb80lQZvn9; Wed, 11 Aug 2010 19:02:34 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id AA59E3A68A0; Wed, 11 Aug 2010 19:02:34 -0700 (PDT) Received: by qyk1 with SMTP id 1so5210002qyk.10 for ; Wed, 11 Aug 2010 19:03:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=oEVqTPdv/s6dSYxRzfGsGKdKHI4b+EkYf63gG7Hs7DY=; b=kRO3yXP29cEZuEftsAsHwzDdBDewHSapKz/v80YjyZlBnCbMiZgYVkjR3Dv/pWZmUz Cv+zw0mLUM+ggOVtgVA9uigSuxA/+fqt+p6PZOdDKSxSTdnWXa/Q+glCcpY8tmTzPcd0 koSKRNaPaFEvKrDzsLn0uRoM/72p6ZbD/Vah4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=i0cLhSfeETyd49BtDVF0EHEcFIsfMzSBkLUllfi3N3JwYVUhkYpIRkd270/9wzg6Qx Ya9790pdZnn5kTgQ5ghRA9YyamgroT2uvAd8YeTEsnpVAFolENwcEm57QQ1WNU9B/9pz ZRB4P4YxIXIPKWsv8DtUUdQ9UpmLw/1RHMMJU= Received: by 10.224.37.134 with SMTP id x6mr11548406qad.172.1281578590577; Wed, 11 Aug 2010 19:03:10 -0700 (PDT) Received: from [130.216.38.124] (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id t24sm1143355qcs.23.2010.08.11.19.03.06 (version=SSLv3 cipher=RC4-MD5); Wed, 11 Aug 2010 19:03:09 -0700 (PDT) Message-ID: <4C635637.70902@gmail.com> Date: Thu, 12 Aug 2010 14:02:31 +1200 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Philip Levis References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <48421D4F-0E73-4192-88EA-D7C6672768F5@free.fr> <6A2A459175DABE4BB11DE2026AA50A5D027CCE7B@XMB-AMS-107.cisco.com> <097F191C-3E28-48E3-AAAF-81730D2A49FD@free.fr> <987.1281456566@marajade.sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 15 Aug 2010 14:43:40 -0700 Cc: 6man 6man , =?UTF-8?B?UsOpbWkgRGVzcHLDqXM=?= , roll@ietf.org, Carsten Bormann Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 02:02:35 -0000 On 2010-08-12 11:34, Philip Levis wrote: > On Aug 10, 2010, at 11:12 PM, R=C3=A9mi Despr=C3=A9s wrote: >=20 >> Le 10 ao=C3=BBt 2010 =C3=A0 18:09, Michael Richardson a =C3=A9crit : >> >>>>>>>> "R=C3=A9mi" =3D=3D R=C3=A9mi Despr=C3=A9s = writes: >>> R=C3=A9mi> RFC 3697 isn't concerned with ASes, and doesn't need to = be. >>> R=C3=A9mi> The proposal is only that, where load balancing is perfo= rmed,=20 >>> R=C3=A9mi> 0 FLs MAY be replaced by meaningful values for this purp= ose. =20 >>> R=C3=A9mi> A FL, once set to a non 0 value, never needs to be reset= =2E >>> >>> okay, so what you are saying is that load balancing uses of the FL ar= e >>> only upset when they see zero. So for instance, if layer-4s (i.e. en= d >>> points) were mandated that they must now always set a FL consistently= on >>> a flow, and set it to a non-zero value, that this would satisfy the >>> requirements of load balancers. >> Right. >> >> To be even more precise:=20 >> - Flow endpoints (sometimes layer 4 and sometimes layer 3) should from= now on be mandated to set FLs with non-0 values that statistically diffe= r from a flow to another. >=20 > The intention is to have a BCP for network stack implementers to follow= ? I don't there is a clear intention just yet, but my personal view is comi= ng round to a 3697bis document, which would presumably be Proposed Standard,= not BCP. But certainly we need more precise normative guidance. >=20 >=20 >> - However, we have to face that, so far, they are generally mandated t= o set FLs to 0. >=20 > I apologize for the lack of context (I'm coming from ROLL): your senten= ce seems to suggest that flow labels today are mandated to be 0. This doe= sn't seem to be right: among other things, ping6 supports setting the flo= w label, and by default allocates a random flow label.[1] Basically, I'm = confused if you're talking in the present tense of what's done with flow = labels today, or the future tense of how flow labels should be used in th= e future. What 3697 says is "A Flow Label of zero is used to indicate packets not part of any flow. =2E.. A source node which does not assign traffic to flows MUST set the Flow Label to zero." It's a little self-referential, since flow *by definition* is a set of packets with the same flow label (and address pair). The rule is there to prevent accidental flow labels because the programmer simply forgot to zero the field. That being so, it isn't clear to me that we need a mandatory flow label, although I can make some arguments for a SHOULD. Brian From remi.despres@free.fr Thu Aug 12 05:54:14 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05D233A6A20; Thu, 12 Aug 2010 05:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.508 X-Spam-Level: X-Spam-Status: No, score=-1.508 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVgkPqHvFjMp; Thu, 12 Aug 2010 05:54:13 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by core3.amsl.com (Postfix) with ESMTP id EE2463A6781; Thu, 12 Aug 2010 05:54:12 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2207.sfr.fr (SMTP Server) with ESMTP id B1C2F7000094; Thu, 12 Aug 2010 14:54:49 +0200 (CEST) Received: from [192.168.1.29] (unknown [89.170.204.214]) by msfrf2207.sfr.fr (SMTP Server) with ESMTP id B26757000092; Thu, 12 Aug 2010 14:54:48 +0200 (CEST) X-SFR-UUID: 20100812125448730.B26757000092@msfrf2207.sfr.fr Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <6A2A459175DABE4BB11DE2026AA50A5D02862A68@XMB-AMS-107.cisco.com> Date: Thu, 12 Aug 2010 14:54:46 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <4C609233.8030207@gmail.com> <6A2A459175DABE4BB11DE2026AA50A5D027CCE4D@XMB-AMS-107.cisco.com> <26885.1281450459@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CD105@XMB-AMS-107.cisco.com> <6A2A459175DABE4BB11DE2026AA50A5D02862A68@XMB-AMS-107.cisco.com> To: Pascal Thubert (pthubert) X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Sun, 15 Aug 2010 14:43:40 -0700 Cc: ipv6@ietf.org, Carsten Bormann , roll@ietf.org, Brian E Carpenter Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 12:54:14 -0000 Le 12 ao=FBt 2010 =E0 10:47, Pascal Thubert (pthubert) a =E9crit : > We'll note that the Hop by Hop + IP in IP is costly but > solves the generic problem *within* the RPL network. The use of the = Flow > label *within* the RPL network would be an alternate so it could have = a > more limited applicability, like a more limited number of instances or = a > Rank floor that can be expressed in 1 octet or less, which is probably > more than enough considering that infinity is 16 in RIP. This could > cover a large number of foreseeable deployments. >=20 > There is certainly a strong benefit in Low Power Lossy Networks to = make > the flow label mutable. How strong the benefit isn't clear to me. Since RPL networks are recognized as such by hosts, it seems easy to add = a short field, just before the IP header, to contain whatever is useful = for this kind of network. Mixing functions with those of FLs would thus be avoided. Did I miss something? RD From remi.despres@free.fr Thu Aug 12 06:00:38 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BB573A68F2; Thu, 12 Aug 2010 06:00:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.563 X-Spam-Level: X-Spam-Status: No, score=-1.563 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQb7A4-q4C6z; Thu, 12 Aug 2010 06:00:37 -0700 (PDT) Received: from smtp22.services.sfr.fr (smtp22.services.sfr.fr [93.17.128.11]) by core3.amsl.com (Postfix) with ESMTP id 063863A682A; Thu, 12 Aug 2010 06:00:37 -0700 (PDT) Received: from filter.sfr.fr (localhost [127.0.0.1]) by msfrf2207.sfr.fr (SMTP Server) with ESMTP id BF81B7000085; Thu, 12 Aug 2010 15:01:13 +0200 (CEST) Received: from [192.168.1.29] (unknown [89.170.204.214]) by msfrf2207.sfr.fr (SMTP Server) with ESMTP id 416D67000081; Thu, 12 Aug 2010 15:01:13 +0200 (CEST) X-SFR-UUID: 20100812130113268.416D67000081@msfrf2207.sfr.fr Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: =?iso-8859-1?Q?R=E9mi_Despr=E9s?= In-Reply-To: <4C635637.70902@gmail.com> Date: Thu, 12 Aug 2010 15:01:12 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4C50463E.7070107@tut.fi><6A2A459175DABE4BB11DE2026AA50A5D026AD476@XMB-AMS-107.cisco.com><14567.1280409076@marajade.sandelman.ca><80D303E5-1564-44FA-9629-914F26311BA6@gmail.com> <11162.1280887515@marajade.sandelman.ca> <6A2A459175DABE4BB11DE2026AA50A5D027CCA1F@XMB-AMS-107.cisco.com> <48421D4F-0E73-4192-88EA-D7C6672768F5@free.fr> <6A2A459175DABE4BB11DE2026AA50A5D027CCE7B@XMB-AMS-107.cisco.com> <097F191C-3E28-48E3-AAAF-81730D2A49FD@free.fr> <987.1281456566@marajade.sandelman.ca> <4C635637.70902@gmail.com> To: Brian E Carpenter X-Mailer: Apple Mail (2.1081) X-Mailman-Approved-At: Sun, 15 Aug 2010 14:43:40 -0700 Cc: 6man 6man , Carsten Bormann , roll@ietf.org Subject: Re: [Roll] Flow Label: 12 bits mutable and 8 bits immutable X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Aug 2010 13:00:38 -0000 Le 12 ao=FBt 2010 =E0 04:02, Brian E Carpenter a =E9crit : > On 2010-08-12 11:34, Philip Levis wrote: >> On Aug 10, 2010, at 11:12 PM, R=E9mi Despr=E9s wrote: >>=20 >>> Le 10 ao=FBt 2010 =E0 18:09, Michael Richardson a =E9crit : >>>=20 >>>>>>>>> "R=E9mi" =3D=3D R=E9mi Despr=E9s = writes: >>>> R=E9mi> RFC 3697 isn't concerned with ASes, and doesn't need to = be. >>>> R=E9mi> The proposal is only that, where load balancing is = performed,=20 >>>> R=E9mi> 0 FLs MAY be replaced by meaningful values for this = purpose. =20 >>>> R=E9mi> A FL, once set to a non 0 value, never needs to be reset. >>>>=20 >>>> okay, so what you are saying is that load balancing uses of the FL = are >>>> only upset when they see zero. So for instance, if layer-4s (i.e. = end >>>> points) were mandated that they must now always set a FL = consistently on >>>> a flow, and set it to a non-zero value, that this would satisfy the >>>> requirements of load balancers. >>> Right. >>>=20 >>> To be even more precise:=20 >>> - Flow endpoints (sometimes layer 4 and sometimes layer 3) should = from now on be mandated to set FLs with non-0 values that statistically = differ from a flow to another. >>=20 >> The intention is to have a BCP for network stack implementers to = follow? >=20 > I don't there is a clear intention just yet, but my personal view is = coming > round to a 3697bis document, which would presumably be Proposed = Standard, > not BCP. +1 > But certainly we need more precise normative guidance. Yes. RD >=20 >>=20 >>=20 >>> - However, we have to face that, so far, they are generally mandated = to set FLs to 0. >>=20 >> I apologize for the lack of context (I'm coming from ROLL): your = sentence seems to suggest that flow labels today are mandated to be 0. = This doesn't seem to be right: among other things, ping6 supports = setting the flow label, and by default allocates a random flow label.[1] = Basically, I'm confused if you're talking in the present tense of what's = done with flow labels today, or the future tense of how flow labels = should be used in the future. >=20 > What 3697 says is > "A Flow Label of zero is used to indicate packets not part > of any flow. > ... > A source node which does not assign traffic to flows MUST set > the Flow Label to zero." >=20 > It's a little self-referential, since flow *by definition* is > a set of packets with the same flow label (and address pair). > The rule is there to prevent accidental flow labels because > the programmer simply forgot to zero the field. >=20 > That being so, it isn't clear to me that we need a mandatory > flow label, although I can make some arguments for a SHOULD. >=20 > Brian >=20 From jpv@cisco.com Sun Aug 15 15:25:06 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6262C3A67A2 for ; Sun, 15 Aug 2010 15:25:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.473 X-Spam-Level: X-Spam-Status: No, score=-110.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rG45FJNdykwB for ; Sun, 15 Aug 2010 15:25:03 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 0F7863A635F for ; Sun, 15 Aug 2010 15:25:00 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN8FaEytJV2b/2dsb2JhbACgRnGeKZpnhTsEiWKCaQ X-IronPort-AV: E=Sophos;i="4.55,373,1278288000"; d="scan'208";a="148100439" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-2.cisco.com with ESMTP; 15 Aug 2010 22:25:36 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o7FMPZaw001765; Sun, 15 Aug 2010 22:25:36 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Aug 2010 00:25:35 +0200 Received: from [10.104.131.154] ([10.55.82.208]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Aug 2010 00:25:34 +0200 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 16 Aug 2010 00:25:33 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 15 Aug 2010 22:25:34.0648 (UTC) FILETIME=[C7632380:01CB3CC8] Cc: Angel Lozano , vanesa.daza@upf.edu, Roger Alexander Subject: [Roll] WG Last Call on draft-ietf-roll-security-framework X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Aug 2010 22:25:06 -0000 Dear all, draft-ietf-roll-security-framework (http://datatracker.ietf.org/doc/draft-ietf-roll-security-framework/ ) has now been presented and discussed for a while and is ready for WG Last Call. This starts a 3-week Working Group Last Call that will end on September 6 at 9:00am ET. Please send your comments to the authors and copy the mailing list. Thanks. JP. From jpv@cisco.com Mon Aug 16 02:20:17 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB7FD3A688B for ; Mon, 16 Aug 2010 02:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.874 X-Spam-Level: X-Spam-Status: No, score=-108.874 tagged_above=-999 required=5 tests=[AWL=-1.476, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gJh5IxqXwuOK for ; Mon, 16 Aug 2010 02:20:15 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D130A3A6816 for ; Mon, 16 Aug 2010 02:20:15 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ+faEyrR7Hu/2dsb2JhbACgQHGeY5sJhTsEiWKCaYdQ X-IronPort-AV: E=Sophos;i="4.55,375,1278288000"; d="scan'208,217";a="240747386" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 16 Aug 2010 09:20:51 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7G9KiqR020122; Mon, 16 Aug 2010 09:20:51 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Aug 2010 11:20:47 +0200 Received: from [10.104.131.127] ([10.55.83.3]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Aug 2010 11:20:45 +0200 Message-Id: <77778AA2-25F1-4F95-9036-3C9EAFD6A271@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: <1FFABC6B-73B7-4549-A304-C34ABCB95366@cs.stanford.edu> Content-Type: multipart/alternative; boundary=Apple-Mail-196-848050119 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 16 Aug 2010 11:20:44 +0200 References: <5FB5C986-D72B-41D9-A193-275DEB1D71A3@cisco.com> <1FFABC6B-73B7-4549-A304-C34ABCB95366@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Aug 2010 09:20:45.0305 (UTC) FILETIME=[4E5D5E90:01CB3D24] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17572.006 X-TM-AS-Result: No--31.246700-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 09:20:17 -0000 --Apple-Mail-196-848050119 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Hi Phil, Look for JP> (I suppose that you incorporated other comments and only =20= focussed on the ones that require further discussion). On Aug 5, 2010, at 4:20 AM, Philip Levis wrote: > Comments inline. > > On Aug 3, 2010, at 6:36 AM, JP Vasseur wrote: > >>> >>> 5. If Trickle hears a transmission that is "inconsistent," the >>> Trickle timer resets. If I is greater than Imin, >>> >>> JP> how could that happen that I < Imin? > > It can't, but it can be equal to Imin. The inequality is to prevent =20= > starvation if a node keeps on resetting its interval. JP> Understood, but the sentence is a bit misleading. Why not: > 5. If Trickle hears a transmission that is "inconsistent," the > Trickle timer resets. Resetting a > Trickle timer sets I to Imin and begins a new interval. When =20= > I is > equal to Imin, resetting a Trickle timer does nothing. Trickle > may also reset the timer in response to external "events. > > >>> resetting a >>> Trickle timer sets I to Imin and begins a new interval. If =20= >>> I is >>> equal to Imin, resetting a Trickle timer does nothing. =20 >>> Trickle >>> may also reset the timer in response to external "events." >>> >>> The terms consistent, inconsistent and event are in quotes because >>> their meaning depends on the use of Trickle. >>> >>> >>> 5. Using Trickle >>> >>> A protocol specification that uses Trickle MUST specify: >>> >>> >>> >>> Levis, et al. Expires January 7, 2011 =20 >>> [Page 6] >>> Internet-Draft draft-ietf-roll-trickle-02 =20 >>> July 2010 >>> >>> >>> o Default values for Imin, Imax, and k. >>> >>> JP> s/Default values/Value > > Why this change? JP> Please ignore ... > >>> Because link layers can >>> vary widely in their properties, the default >>> >>> JP> remove "default" >>> value of Imin should >>> be specified in terms of the worst-case latency of a link layer >>> transmission. For example, a specification should say "the >>> default value of Imin is 4 times the worst case link layer >>> latency" >>> >>> JP> may be worth how you define "latency" >>> and should not say "the default value of Imin is 500 >>> milliseconds." Worst case latency is the time until the first >>> link-layer transmission of the frame assuming an idle channel >>> (does not include backoff, virtual carrier sense, etc.). >>> >>> o What constitutes a "consistent" transmission. >>> >>> o What constitutes an "inconsistent" transmission. >>> >>> o What "events," if any, besides inconsistent transmissions that >>> reset the Trickle timer. >>> >>> >>> 6. Operational Considerations >>> >>> It is RECOMMENDED that a protocol which uses Trickle include >>> mechanisms to inform nodes of configuration parameters at runtime. >>> However, it is not always possible to do so. In the cases where >>> different nodes have different configuration parameters, Trickle =20= >>> may >>> have unintended behaviors. This section outlines some of those >>> behaviors and operational considerations as educational exercises. >>> >>> 6.1. Mismatched redundancy constants >>> >>> If nodes do not agree on the redundancy constant k, then nodes =20 >>> with >>> higher values of k will transmit more often than nodes with lower >>> values of k. In some cases, this increased load can be =20 >>> independent >>> of the density. For example, consider a network where all nodes =20= >>> but >>> one have k=3D1, and this one node has k=3D2. The different node = can =20 >>> end >>> up transmitting on every interval: it is maintaining a =20 >>> communication >>> rate of 2 with only itself. Hence, the danger of mismatched k =20 >>> values >>> is uneven transmission load that can deplete the energy of some >>> nodes. >>> >>> JP> Still this does not lead to interoperability issues. >>> Don't we want to recommend consistent configuration ? If you =20 >>> agree, then >>> these comments should go at the end of this section (or beginning) =20= >>> but they >>> apply to several kind of mismatches > > I'm not sure I want to go as far as recommending consistent =20 > configuration. E.g., if I have some nodes with more energy, they =20 > might be willing to shoulder a greater energy burden and so have a =20 > smaller Imax. > JP>This is fine. At least the text explains the drawbacks of using =20 inconsistent values. > > >>> 6.2. Mismatched Imin If nodes do not agree on Imin, then some =20= >>> nodes, on hearing inconsistent messages, will transmit sooner =20 >>> than others. These faster nodes will have their intervals grow =20= >>> to similar size as the slower nodes within a single slow =20 >>> interval time, but in that period may suppress the slower =20 >>> nodes. However, such suppression will end after the first slow =20= >>> interval, when the nodes generally agree on the interval size. =20= >>> Hence, mismatched Imin values are usually not a Levis, et =20 >>> al. Expires January 7, 2011 [Page 7] =0C = Int=20 >>> ernet-Draft draft-ietf-roll-trickle-02 July =20 >>> 2010 significant concern. 6.3. Mismatched Imax If nodes do =20= >>> not agree on Imax, then this can cause long-term problems with =20 >>> transmission load. Nodes with small Imax values will transmit =20 >>> faster, suppressing those with larger Imax values. The nodes =20 >>> with larger Imax values, always suppressed, will never =20 >>> transmit. In the base case, when the network is consistent, =20 >>> this can cause long-term inequities in energy cost. 6.4. =20 >>> Mismatched definitions If nodes do not agree on what =20 >>> constitutes a consistent or inconsistent transmission, then =20 >>> Trickle may fail to operate properly. For example, if a receiver =20= >>> thinks a transmission is consistent, but the transmitter (if in =20= >>> the receivers situation) would have thought it inconsistent, =20 >>> then the receiver will not respond properly and inform the =20 >>> transmitter. This can lead the network to not reach a =20 >>> consistent state. For this reason, unlike the configuration =20 >>> constants k, Imin, and Imax, consistency definitions should be =20 >>> clearly stated in the protocol and should not be configured at =20 >>> runtime. >>> JP> I would suggest a MUST instead of a should in the sentence =20 >>> above. > > I'm wary of saying MUST; it would mean that an implementation is not =20= > compliant with this document even if, for good reason, it has =20 > different consistency definitions. JP>OK so let's at least make it a normative SHOULD. > > >>> 6.5. Specifying the constant k >>> >>> There are some edge cases where a protocol may wish to use Trickle >>> with its suppression disabled (k is set to infinity). In general, >>> this approach is highly dangerous and it is NOT RECOMMENDED. >>> >>> JP> I would strongly suggest to soften this statement. Just =20 >>> explain the >>> consequences. >>> Disabling suppression means that every node will always send on =20= >>> every >>> interval, and can lead to congestion in dense networks. This >>> approach is especially dangerous > > OK -- I will give an explanation. > JP>OK > >>> >>> JP> same comment >>> if many nodes reset their intervals >>> at the same time. In general, it is much more desirable to set =20= >>> k to >>> a high value (e.g., 5 or 10) than infinity. Typical values for =20= >>> k are >>> 1-5: these achieve a good balance between redundancy and low cost. >>> >>> >>> JP> I would suggest to add refs here. >>> Nevertheless, there are situations where a protocol may wish to =20= >>> turn >>> off Trickle suppression. Because k is a natural number >>> (Section 4.1), c=3D0 has no useful meaning. If a protocol allows =20= >>> k to >>> be dynamically configured, a value of 0 remains unused. For =20 >>> ease of >>> debugging and packet inspection, having the parameter describe =20 >>> (c-1) > > Disagree -- it's easier for debugging when the value equals the =20 > value. There's later text about k=3D0 and using it to represent k=3Dinf.= JP>I do not see which comment you disagree on ? JP. > > Phil --Apple-Mail-196-848050119 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi = Phil,

Look for JP> (I suppose that you incorporated other comments = and only focussed on the ones that require further = discussion).

On Aug 5, 2010, at 4:20 AM, = Philip Levis wrote:

Comments inline.

On Aug 3, 2010, at 6:36 AM, = JP Vasseur wrote:


  5.  If Trickle = hears a transmission that is "inconsistent," = the
      Trickle timer resets. =  If I is greater than Imin, =

JP> how could that happen = that I <  Imin?

It can't, but = it can be equal to Imin. The inequality is to prevent starvation if a = node keeps on resetting its = interval.

JP> = Understood, but the sentence is a bit misleading. Why = not:
   5.  If =
Trickle hears a transmission that is "inconsistent," the
       Trickle timer resets.  Resetting a
       Trickle timer sets I to Imin =
and begins a new interval.  When I is
       equal to Imin, resetting a Trickle timer does nothing.  Trickle
       may also reset the timer in response to external =
"events.



resetting a
=       Trickle timer sets I to Imin and = begins a new interval.  If I = is
      equal to Imin, = resetting a Trickle timer does nothing. =  Trickle
=       may also reset the timer in response = to external "events."

  The terms = consistent, inconsistent and event are in quotes = because
  their meaning depends on the use of = Trickle.


5.  Using = Trickle

  A protocol = specification that uses Trickle MUST = specify:



Levis, et al. =            Expires = January 7, 2011 =             &n= bsp;  [Page 6]
Internet-Draft =         draft-ietf-roll-trickle-02= =             &n= bsp;July 2010


  o  Default = values for Imin, Imax, and k. =  

JP> s/Default = values/Value

Why this = change?
JP>
Please ignore = ...


Because link layers = can
     vary widely in their = properties, the default

JP> remove = "default"
value of Imin = should
     be specified in terms of = the worst-case latency of a link = layer
     transmission.  For = example, a specification should say = "the
     default value of Imin is 4 = times the worst case link layer
=      latency" =

JP> may be worth how you = define "latency"
and should not say "the default = value of Imin is 500
=      milliseconds."  Worst case latency is = the time until the first
=      link-layer transmission of the frame = assuming an idle channel
=      (does not include backoff, virtual carrier = sense, etc.).

  o  What = constitutes a "consistent" = transmission.

  o  What = constitutes an "inconsistent" = transmission.

  o  What = "events," if any, besides inconsistent transmissions = that
     reset the Trickle = timer.


6.  Operational = Considerations

  It is RECOMMENDED = that a protocol which uses Trickle = include
  mechanisms to inform nodes of configuration = parameters at runtime.
  However, it is not = always possible to do so.  In the cases = where
  different nodes have different configuration = parameters, Trickle may
  have unintended = behaviors.  This section outlines some of = those
  behaviors and operational considerations as = educational exercises.

6.1.  Mismatched redundancy = constants

  If nodes do not = agree on the redundancy constant k, then nodes = with
  higher values of k will transmit more often = than nodes with lower
  values of k. =  In some cases, this increased load can be = independent
  of the density. =  For example, consider a network where all nodes = but
  one have k=3D1, and this one node has k=3D2. =  The different node can = end
  up transmitting on every interval: it is = maintaining a communication
  rate of 2 with only = itself.  Hence, the danger of mismatched k = values
  is uneven transmission load that can deplete = the energy of some
=   nodes.

JP> Still this does not lead = to interoperability issues.
Don't we want to recommend = consistent configuration ? If you agree, = then
these comments should go at the end of this section (or = beginning) but they
apply to several kind of = mismatches

I'm not sure I want to go as = far as recommending consistent configuration. E.g., if I have some nodes = with more energy, they might be willing to shoulder a greater energy = burden and so have a smaller = Imax.




6.2.  Mismatched Imin    If nodes do = not agree on Imin, then some nodes, on hearing   inconsistent = messages, will transmit sooner than others.  These =   faster nodes will have their intervals grow to similar size = as the   slower nodes within a single slow interval time, but = in that period   may suppress the slower nodes.  However, = such suppression will end   after the first slow interval, = when the nodes generally agree on the   interval size. =  Hence, mismatched Imin values are usually not a Levis, et al. =            Expires = January 7, 2011 =             &n= bsp;  [Page 7] =0C Internet-Draft =         draft-ietf-roll-trickle-02= =             &n= bsp;July 2010    significant concern. 6.3. =  Mismatched Imax    If nodes do not agree on Imax, = then this can cause long-term problems   with transmission = load.  Nodes with small Imax values will transmit =   faster, suppressing those with larger Imax values.  The = nodes with   larger Imax values, always suppressed, will never = transmit.  In the   base case, when the network is = consistent, this can cause long-term   inequities in energy = cost. 6.4.  Mismatched definitions    If nodes do = not agree on what constitutes a consistent or   inconsistent = transmission, then Trickle may fail to operate properly.   For = example, if a receiver thinks a transmission is consistent, but =   the transmitter (if in the receivers situation) would have = thought it   inconsistent, then the receiver will not respond = properly and inform   the transmitter.  This can lead the = network to not reach a consistent   state.  For this = reason, unlike the configuration constants k, Imin,   and = Imax, consistency definitions should be clearly stated in the =   protocol and should not be configured at runtime. =
JP> I would suggest a MUST instead of a should in the = sentence above.

I'm wary of saying = MUST; it would mean that an implementation is not compliant with this = document even if, for good reason, it has different consistency = definitions.



6.5.  Specifying the = constant k

  There are some edge = cases where a protocol may wish to use = Trickle
  with its suppression disabled (k is set to = infinity).  In general,
  this approach is = highly dangerous and it is NOT = RECOMMENDED.

JP> I would strongly suggest = to soften this statement. Just explain = the
consequences.
  Disabling = suppression means that every node will always send on = every
  interval, and can lead to congestion in dense = networks.  This
  approach is = especially dangerous

OK -- I will give = an explanation.




JP> same = comment
if many nodes reset their = intervals
  at the same time. =  In general, it is much more desirable to set k = to
  a high value (e.g., 5 or 10) than infinity. =  Typical values for k are
  1-5: these achieve = a good balance between redundancy and low = cost.


JP> I would suggest to add = refs here.
  Nevertheless, there = are situations where a protocol may wish to = turn
  off Trickle suppression.  Because k is a = natural number
  (Section 4.1), c=3D0 = has no useful meaning.  If a protocol allows k = to
  be dynamically configured, a value of 0 = remains unused.  For ease = of
  debugging and packet inspection, having the = parameter describe (c-1)

Disagree -- = it's easier for debugging when the value equals the value. There's later = text about k=3D0 and using it to represent = k=3Dinf.


Phil

= --Apple-Mail-196-848050119-- From jpv@cisco.com Mon Aug 16 02:22:16 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1E373A6816 for ; Mon, 16 Aug 2010 02:22:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.716 X-Spam-Level: X-Spam-Status: No, score=-109.716 tagged_above=-999 required=5 tests=[AWL=-0.607, BAYES_05=-1.11, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUI+VGZPxqCy for ; Mon, 16 Aug 2010 02:22:13 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id AB90D3A6982 for ; Mon, 16 Aug 2010 02:22:13 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: c7109a90aea2b412c275c383a4dbb181.png : 1663 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcFANqfaEyrR7H+/2dsb2JhbACBRJZkiBhxnmSbCYU7BIFViA2CaYdQ X-IronPort-AV: E=Sophos;i="4.55,375,1278288000"; d="png'150?scan'150,208,217,150";a="172425651" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 16 Aug 2010 09:22:49 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7G9MkwW001423; Mon, 16 Aug 2010 09:22:49 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Aug 2010 11:22:38 +0200 Received: from [10.104.131.127] ([10.55.83.3]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 16 Aug 2010 11:22:36 +0200 Message-Id: From: JP Vasseur To: Philip Levis In-Reply-To: <7FE6DAEC-91E4-4FB9-A78C-65F7601A7624@cs.stanford.edu> Content-Type: multipart/alternative; boundary=Apple-Mail-197-848161507 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 16 Aug 2010 11:22:35 +0200 References: <5FB5C986-D72B-41D9-A193-275DEB1D71A3@cisco.com> <7FE6DAEC-91E4-4FB9-A78C-65F7601A7624@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 16 Aug 2010 09:22:36.0801 (UTC) FILETIME=[90D24F10:01CB3D24] Cc: ROLL WG Subject: Re: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 09:22:16 -0000 --Apple-Mail-197-848161507 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit On Aug 10, 2010, at 8:46 PM, Philip Levis wrote: > > On Aug 3, 2010, at 6:36 AM, JP Vasseur wrote: > >> >> >> Begin forwarded message: >> >>> >>> >>> 4.2. Algorithm Description >>> >>> The Trickle algorithm has five rules: >>> >>> 1. When an interval begins, Trickle resets c to 0 and sets t to a >>> random point in the interval, taken from the range [I/2, I). >>> >>> JP> s/I)/I] > > Just as a note -- this is an example of why there's the strong > language about not tweaking Trickle. If you use [I/2, I] rather than > [I/2, I), then there's an ambiguity when intervals are synchronized: > a packet transmitted in interval X can suppress in interval X+1. > This could prevent Trickle from maintaining its minimum > communication rate, as an entire interval could pass with no > transmissions. For the WG, the misunderstanding was coming from the the use of different notation. In some countries we use [a,b[ instead: But that's OK let's use the [a,b) notation. For the record: (http://en.wikipedia.org/wiki/Interval_(mathematics)): The ISO notation International standard ISO 31-11 also defines another notation for intervals, which seems to be more commonly taught in Europe[citation needed] and South America. It uses an inwards pointing bracket to indicate inclusion of the endpoint, and outwards-pointing bracket for exclusion: Both notations may overlap with other uses of parentheses and brackets in mathematics. For instance, the notation (a,b) is often used to denote an ordered pair in set theory, the coordinates of a point or vector in analytic geometry and linear algebra, or (sometimes) a complex number in algebra. The notation [a,b] too is occasionally used for ordered pairs, especially in computer science. Some authors use ]a,b[ to denote the complement of the interval (a,b); namely, the set of all real numbers that are either less than or equal to a, or greater than or equal to b. In countries where numbers are written with a decimal comma, a semicolon may be used as a separator, to avoid ambiguity. Cheers. JP. > > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-197-848161507 Content-Type: multipart/related; boundary=Apple-Mail-198-848161508; type="text/html" --Apple-Mail-198-848161508 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable
On Aug 10, 2010, = at 8:46 PM, Philip Levis wrote:


On = Aug 3, 2010, at 6:36 AM, JP Vasseur wrote:



Begin forwarded = message:



4.2.  Algorithm = Description

  The Trickle = algorithm has five rules:

  1.  When an = interval begins, Trickle resets c to 0 and sets t to = a
      random point in the = interval, taken from the range [I/2, = I).

JP> = s/I)/I]

Just as a note -- this is an = example of why there's the strong language about not tweaking Trickle. = If you use [I/2, I] rather than [I/2, I), then there's an ambiguity when = intervals are synchronized: a packet transmitted in interval X can = suppress in interval X+1. This could prevent Trickle from maintaining = its minimum communication rate, as an entire interval could pass with no = transmissions.

For the WG, the = misunderstanding was coming from the the use of different notation. In = some countries we use [a,b[ instead:

But that's = OK let's use the [a,b) notation.

For the = record:

(http://en.wik= ipedia.org/wiki/Interval_(mathematics)):

The ISO notation

International standard ISO 31-11 also defines another notation for = intervals, which seems to be more commonly taught in Europecitation needed] and = South America. It uses an inwards pointing bracket to indicate inclusion of the endpoint, and = outwards-pointing bracket for exclusion:
3D"
Both notations may overlap with = other uses of parentheses and brackets in mathematics. For instance, the = notation ordered pair in set theory, the coordinates of a point or vector in analytic geometry and linear algebra, or (sometimes) a complex number in algebra. The notation [a,b] too is = occasionally used for ordered pairs, especially in computer science.
Some authors use In = countries where numbers are written with a decimal comma, a semicolon may be used as a separator, to avoid = ambiguity.

Cheers.
<= br>
JP.


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

= --Apple-Mail-198-848161508 Content-Disposition: inline; filename=c7109a90aea2b412c275c383a4dbb181.png Content-Transfer-Encoding: base64 Content-Type: image/png; x-unix-mode=0666; name="c7109a90aea2b412c275c383a4dbb181.png" Content-Id: <4F5707DD-5C36-4F89-BF21-F9A2A55ED5A8@cisco.com> iVBORw0KGgoAAAANSUhEUgAAAMEAAABrBAMAAAA86/snAAAAMFBMVEX///8AAAB0dHQWFhYMDAzm 5uYwMDCenp5AQEBiYmJQUFAiIiLMzMy2trYEBASKiorkWsOZAAAGCklEQVRoBe2aT2gcVRzHv9kw XWNmmyIErChuDQRzVZBYFHMp2oKwERFSFHroeqlCelMLEgyeVAgaofUUKT1UPIyXGCjiilICStno RQj0JqJUXMm9+H6/9//N2z9vuwGFncPOvN/7ze+7772Znc9+Gcydgr+tF34b+RdtHflSHwyyf+dT ldW02flXa0AogHeNAN6wub2PfnxQ9OsTHQVMdCIKr9tiAyvgUXHS9Jo801XYa0QUtnsoZC3bqY5e pX1tVnxMn6NDwFXYFO3SLPVQyNftDHIxYPdZOphaEh8xhR0RT1DIL6yKE7zt5tfc5AlyFN5a+Eym Hf+4GVf4+fLKvEjhdTDZtW01AtUrEvbflIUmrsw3nDFUivwB7qg9hHmpsP4kbXI4i0Beny5OtKSC ya5uiwhtuhe4pC+Fva3KORyR54t12GvhYU4Vs3exNIbqHTGtmNyqiRQqoLNnFht8ku3Fwfsqgk1U j6H2u2w2cYOatInZOxEq1M6LQhkmVimBFHT27Q2K0KZ7a3/ItvjcQUWU/OEjDjRxHPcXfHi0g/Oh AiqnqO8iJ5CCyf6kzjH6kL2YekJH/saRJeR6DPkjmNxoUN9yA3+W1+EMdV0V35THYLMxp38WVC9Q eZrrIJvF0S3cJ783mvksltt1KrOMmd9KY4C4H2o4iZeUgskGDq7RWaZXHM6cZInsGO6619KL+Py1 9q0NYLL18mpU4Z+fTkP08zpwNhUW26UP6VP30nF1p0W7Z7Ln5R1HZZv4deHsdXy3JC6798TSFJTh bmIMNx97ZaEhYrQOnK379zviSPdysPYt7XYfb0sFKtvkDqCu9jEF1cUK+rj/nu/pulWgb0PbiBVE WTWGbFUKlBU+UB1iR7M0+Da5Ju4VUVYpTOkzS2O4pbVTFe626H5H/6dodqWt1fnS0Y1+e/MU7Zc4 7h/PwHgGRjkD68HPRNi+dzJ2BA6JjB2FdDKubnSZTpeMXYVUMp5ZbJUUGJY9MnYVEsm4Ip/7noiE ZY+MXYU0Mp460/CKU0PBskfGQsGwbhIZr5zW9S0Za1j2yLiAYd0kMj5rAM+SsYFlj4wLw7r0v2Jw Mv7ePLQ1N8PCskfGhWHdNDLG/jdqljQZw8KyR8aFZd00Mob6vyN0FBnDwLJHxoVl3UQyxu5zahSS m0VDwbJPxsXwZAy52pqbSU7CcuaRcYHhyRgra6KqS8YKlj0yLu6FjOlr+2QMhmWPjPU9XefskXOr KKsVOoejIMoqhWQy/oX/EK+p7xXbaTJWCodHxgifmmEbYzKOLdA4Np6B/+oMhP92w7ZAoFF7xtrn MFOirV8RMHhhOrsc9PSMSwqJnvHbLOqSsVuRyNhtc3IPRxdlz/iAfQOPjN2KRMZuu59C2TOeu8bn eGTsViQydtt9FMqe8aYUkKZ6N884qjCYZ5xtbvB3AjwybgZkzApDecbZ1boSgEfGoWccjmFwzzh/ qqUVPDIOPeNAIcEzRu1GW0l4ZBx6xoFCimes/wEBHhk3AzIurUOCZ4x8vUOj8Mk49IzDMSR5xpCr 7ZNxMyDjmIJmX/pd6u0ZI7tMg/DIOPSMYwraFSaFPp4x1e/jGccU5GkJv618QjfPeMQKYuVVRUPG JYWBPeMas/KiHjA0GauKhoxLCqP2jMtP0TEZm1UZH4xn4P8wA8G/2/I9PSwZV6835PgLOw3sGZd+ l4YhY65U/aukwJ5xSaEXGUc8YxmaoOc1IaTYnDEglYwjnrEKUSV6wtPmKiSSccQz1iGqFFNII+OI Z2xCPEF2DJ5nXFoHyouRccQztiFyn+0YfM+YFQYg44hnbEPsPuMCTRWtg34/QnrG4Ri6kXHEM3ZC 5D7j9qpS0O9HSM84UOhKxhHP2Ib4vQzkL7TlGMz7EewZBwrdyTjiGZsQV4JiiNAzLq1DVzKOeMY6 xO4zFAeFnnE4hh5kHPGMVYjfy7DXku8ZxxS6kXHEM5Yhfi/DKvhvU8QUupIxXyu6lxvyg9/LsAoy WFcJMQXVNbjrIE+w9zS3O4etkEzGEc84DClIVr+th0DGM3fktPR9ig5Lxuop+i+ToK8AYw7+lQAA AABJRU5ErkJggg== --Apple-Mail-198-848161508-- --Apple-Mail-197-848161507-- From trac@tools.ietf.org Mon Aug 16 02:25:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9CA3A6816 for ; Mon, 16 Aug 2010 02:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRa6sYAhxOKa for ; Mon, 16 Aug 2010 02:25:29 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B9B4B3A67DB for ; Mon, 16 Aug 2010 02:25:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OkvxC-0004Qf-2j; Mon, 16 Aug 2010 02:26:03 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pal@cs.stanford.edu, jpv@cisco.com X-Trac-Project: roll Date: Mon, 16 Aug 2010 09:26:02 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/76 Message-ID: <055.369a9a0a4d0e12730c5be4d815375f6a@tools.ietf.org> X-Trac-Ticket-ID: 76 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pal@cs.stanford.edu, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #76: Trickle LC Standard Track X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 09:25:31 -0000 #76: Trickle LC Standard Track -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pal@… Type: defect | Status: new Priority: major | Milestone: Component: trickle | Version: Severity: In WG Last Call | Keywords: -----------------------------+---------------------------------------------- Version -02 of draft-ietf-roll-trickle-02 suggested Information Track, thus leading to a downrefs in draft-ietf-roll-rpl (where this document is listed as a normative reference). -- Ticket URL: roll From trac@tools.ietf.org Mon Aug 16 02:26:20 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F38503A6990 for ; Mon, 16 Aug 2010 02:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQSlmuQ7wpgi for ; Mon, 16 Aug 2010 02:26:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 67CFF3A698B for ; Mon, 16 Aug 2010 02:26:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Okvxy-00084f-Mt; Mon, 16 Aug 2010 02:26:50 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pal@cs.stanford.edu, jpv@cisco.com X-Trac-Project: roll Date: Mon, 16 Aug 2010 09:26:50 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/76#comment:1 Message-ID: <064.538c7778be316577b4f89f36b7b62b05@tools.ietf.org> References: <055.369a9a0a4d0e12730c5be4d815375f6a@tools.ietf.org> X-Trac-Ticket-ID: 76 In-Reply-To: <055.369a9a0a4d0e12730c5be4d815375f6a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pal@cs.stanford.edu, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #76: Trickle LC Standard Track X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 09:26:20 -0000 #76: Trickle LC Standard Track -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pal@… Type: defect | Status: closed Priority: major | Milestone: Component: trickle | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: new => closed * resolution: => fixed Comment: There is a WG consensus to move the document to standard track -- Ticket URL: roll From pal@cs.stanford.edu Mon Aug 16 09:53:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB603A685A for ; Mon, 16 Aug 2010 09:53:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.858 X-Spam-Level: X-Spam-Status: No, score=-5.858 tagged_above=-999 required=5 tests=[AWL=-0.459, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hYyRp64KFU2R for ; Mon, 16 Aug 2010 09:53:55 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 320513A67C2 for ; Mon, 16 Aug 2010 09:53:55 -0700 (PDT) Received: from dn0a2100e3.sunet ([10.33.0.227]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Ol2xC-0003TT-T6; Mon, 16 Aug 2010 09:54:31 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <77778AA2-25F1-4F95-9036-3C9EAFD6A271@cisco.com> Date: Mon, 16 Aug 2010 09:02:47 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <37998A50-F016-43BF-94A3-8086EB05B714@cs.stanford.edu> References: <5FB5C986-D72B-41D9-A193-275DEB1D71A3@cisco.com> <1FFABC6B-73B7-4549-A304-C34ABCB95366@cs.stanford.edu> <77778AA2-25F1-4F95-9036-3C9EAFD6A271@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 980022258218d8e0da9e8fd80fb6777b Cc: ROLL WG Subject: Re: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Aug 2010 16:53:56 -0000 On Aug 16, 2010, at 2:20 AM, JP Vasseur wrote: >>>>=20 >>>>=20 >>>> JP> I would suggest to add refs here. >>>> Nevertheless, there are situations where a protocol may wish to = turn >>>> off Trickle suppression. Because k is a natural number >>>> (Section 4.1), c=3D0 has no useful meaning. If a protocol allows = k to >>>> be dynamically configured, a value of 0 remains unused. For ease = of >>>> debugging and packet inspection, having the parameter describe = (c-1) >>=20 >> Disagree -- it's easier for debugging when the value equals the = value. There's later text about k=3D0 and using it to represent k=3Dinf. >=20 > JP>I do not see which comment you disagree on ? Having the parameter describe c-1. I think it's easier if you have the = parameter describe c, and define c=3D0 as a special case. Phil From jpv@cisco.com Tue Aug 17 01:01:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E90C3A68A7 for ; Tue, 17 Aug 2010 01:01:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.856 X-Spam-Level: X-Spam-Status: No, score=-109.856 tagged_above=-999 required=5 tests=[AWL=-0.457, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17QaOezYjwsR for ; Tue, 17 Aug 2010 01:01:02 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A2B0D3A6877 for ; Tue, 17 Aug 2010 01:01:02 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABXfaUxAZnwM/2dsb2JhbACgO3GhA5wYhTcEiWeCaYdR X-IronPort-AV: E=Sophos;i="4.55,381,1278288000"; d="scan'208";a="148511728" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 17 Aug 2010 08:01:38 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7H81X65025017; Tue, 17 Aug 2010 08:01:37 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); Tue, 17 Aug 2010 10:01:29 +0200 Received: from [192.168.1.10] ([10.55.83.155]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Aug 2010 10:01:28 +0200 Message-Id: <26B70EE3-049C-48A2-9DB4-F2E497758C42@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: <37998A50-F016-43BF-94A3-8086EB05B714@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Aug 2010 10:01:28 +0200 References: <5FB5C986-D72B-41D9-A193-275DEB1D71A3@cisco.com> <1FFABC6B-73B7-4549-A304-C34ABCB95366@cs.stanford.edu> <77778AA2-25F1-4F95-9036-3C9EAFD6A271@cisco.com> <37998A50-F016-43BF-94A3-8086EB05B714@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Aug 2010 08:01:28.0443 (UTC) FILETIME=[657794B0:01CB3DE2] Cc: ROLL WG Subject: Re: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 08:01:03 -0000 On Aug 16, 2010, at 6:02 PM, Philip Levis wrote: > > On Aug 16, 2010, at 2:20 AM, JP Vasseur wrote: > >>>>> >>>>> >>>>> JP> I would suggest to add refs here. >>>>> Nevertheless, there are situations where a protocol may wish to >>>>> turn >>>>> off Trickle suppression. Because k is a natural number >>>>> (Section 4.1), c=0 has no useful meaning. If a protocol allows >>>>> k to >>>>> be dynamically configured, a value of 0 remains unused. For >>>>> ease of >>>>> debugging and packet inspection, having the parameter describe >>>>> (c-1) >>> >>> Disagree -- it's easier for debugging when the value equals the >>> value. There's later text about k=0 and using it to represent k=inf. >> >> JP>I do not see which comment you disagree on ? > > Having the parameter describe c-1. I think it's easier if you have > the parameter describe c, and define c=0 as a special case. What I am suggesting is to clarify the sentence ... (hard to parse) ... why "counter-productive" ? Just a question of wording, we agree on the content. Thanks. JP. > > Phil > From jpv@cisco.com Tue Aug 17 01:04:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A14453A68D7 for ; Tue, 17 Aug 2010 01:04:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.452 X-Spam-Level: X-Spam-Status: No, score=-110.452 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3AWW9mFROywq for ; Tue, 17 Aug 2010 01:04:29 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 55DD63A68B8 for ; Tue, 17 Aug 2010 01:04:29 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABXfaUxAZnwN/2dsb2JhbACgO3GhA5wYhTcEiWeCaYdR X-IronPort-AV: E=Sophos;i="4.55,381,1278288000"; d="scan'208";a="148512904" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 17 Aug 2010 08:05:04 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7H84nrI015360; Tue, 17 Aug 2010 08:05:04 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Aug 2010 10:04:56 +0200 Received: from [192.168.1.10] ([10.55.83.155]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Aug 2010 10:04:55 +0200 Message-Id: From: JP Vasseur To: Philip Levis In-Reply-To: <12766418-F99F-4AB0-98F7-087C95720231@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Aug 2010 10:04:56 +0200 References: <5FB5C986-D72B-41D9-A193-275DEB1D71A3@cisco.com> <1FFABC6B-73B7-4549-A304-C34ABCB95366@cs.stanford.edu> <12766418-F99F-4AB0-98F7-087C95720231@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Aug 2010 08:04:55.0986 (UTC) FILETIME=[E12C2120:01CB3DE2] Cc: ROLL WG Subject: Re: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 08:04:30 -0000 On Aug 5, 2010, at 8:04 PM, Philip Levis wrote: > > On Aug 4, 2010, at 7:20 PM, Philip Levis wrote: > >> This can lead the network to not reach a consistent state. For >> this reason, unlike the configuration constants k, Imin, and >> Imax, consistency definitions should be clearly stated in the >> protocol and should not be configured at runtime. >>>> JP> I would suggest a MUST instead of a should in the sentence >>>> above. >> >> I'm wary of saying MUST; it would mean that an implementation is >> not compliant with this document even if, for good reason, it has >> different consistency definitions. > > Sorry, I miswrote. I agree that the sentence should say MUST, and > SHOULD NOT. So, > >> For this reason, unlike the configuration constants k, Imin, and >> Imax, consistency definitions MUST be clearly stated in the >> protocol and SHOULD NOT be configured at runtime. > > Sound good? Although the MUST is redundant with prior text... Yes, better, thanks. JP. > > Phil From jpv@cisco.com Tue Aug 17 01:10:11 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B6ED3A6819 for ; Tue, 17 Aug 2010 01:10:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.953 X-Spam-Level: X-Spam-Status: No, score=-107.953 tagged_above=-999 required=5 tests=[AWL=-2.354, BAYES_00=-2.599, GB_SUMOF=5, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QqIqbOO3mSit for ; Tue, 17 Aug 2010 01:10:06 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id F16C83A6879 for ; Tue, 17 Aug 2010 01:10:04 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGvhaUytJV2b/2dsb2JhbACgO3GhCJwZhTcEiWeCaYdR X-IronPort-AV: E=Sophos;i="4.55,381,1278288000"; d="scan'208";a="148514537" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rtp-iport-1.cisco.com with ESMTP; 17 Aug 2010 08:10:40 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by rcdn-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id o7H8AU2J019304; Tue, 17 Aug 2010 08:10:39 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Aug 2010 10:10:36 +0200 Received: from [192.168.1.10] ([10.55.83.155]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Aug 2010 10:10:36 +0200 Message-Id: <924028EC-0491-44AF-9E21-AF735079C84C@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: <18EB6233-3FC3-4CEB-B284-EC21ACA5563B@cs.stanford.edu> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Aug 2010 10:10:36 +0200 References: <18EB6233-3FC3-4CEB-B284-EC21ACA5563B@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Aug 2010 08:10:36.0410 (UTC) FILETIME=[AC14B5A0:01CB3DE3] Cc: roll@ietf.org, T.Clausen@computer.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 08:10:11 -0000 On Jul 29, 2010, at 11:49 AM, Philip Levis wrote: > Yoav, my comments are inline. > On Jul 29, 2010, at 8:58 AM, Yoav Ben-Yehezkel wrote: > >> Authors/ROLL WG, >> >> Find below some minor comments/clarifications I have on the Trickle =20= >> draft. >> >> Suggest to replace the term =93wireless=94 with =93LLN=94 (trickle is = =20 >> potentially not used solely by wireless =96 though it was developed =20= >> on a wireless platform I understand). >> >> It appears in the abstract, in the intro, at the last para of =20 >> section 3., at section 6.7. >> =93Abstract >> >> The Trickle algorithm allows wireless nodes to exchange information >> in a highly robust,...=94 >> >> >> =931. Introduction >> >> The Trickle algorithm is designed for wireless networks.=94 >> >> =933. Trickle Algorithm Overview >> =85 Sparser networks require more transmissions per node, but >> utilization of the radio channel over space will not increase. =20 >> This >> is an important property in wireless networks, where the channel =20= >> is a >> valuable shared resource.=94 >> >> =936.7. Tweaks and improvements to Trickle >> =85 However, in dynamic network environments such as wireless, >> the coordination needed to compute the=85 > > This is a good point. What this text is trying to get at is that =20 > Trickle is designed for, and well-suited to, lossy broadcast media. =20= > We've never really examined its use in low-loss switched networks =20 > (e.g., Ethernet). When the algorithm was designed, lossy broadcast =20 > media basically meant wireless, and not just low-power wireless. =20 > E.g., Trickle is well suited to 802.11. We didn't really consider =20 > PLC -- in the context of ROLL, however, it should definitely be =20 > considered. > > Correspondingly, I don't think LLN is the right term either. How =20 > about "lossy broadcast-based networks," with a few examples (e.g., =20 > wireless, PLC)? I would much prefer LLN: * This is the term used across all documents in ROLL * PLC are also low power and lossy > >> >> >> Last paragraph of section 3 is a little unclear to me. >> =93 A single, disconnected node must transmit at the communication =20= >> rate.=94 >> Can you clarify this sentence? What do you mean by =93must transmit =20= >> at the communication rate=94? The communication rate is the output of = =20 >> the number of transmissions a disconnected node makes, not the =20 >> other way around. > > Ah -- I see. This sentence is referring to the prior paragraph, =20 > which reads: > > "As long as the network is connected and there is some minimum =20 > communication rate for each node, the network will reach eventual =20 > consistency." > > The point is that communication is either transmission or reception =20= > and that the edge case of a solitary node, its communication will be =20= > all transmissions. In networks of multiple nodes, a node's =20 > communication can be some mix of receptions and transmissions. > > Would it make more sense if the text read "Trickle communication =20 > rate" rather than "communication rate?" I think so. > > > >> >> =93 In a lossless, single-hop network of size n, the sum of =20 >> transmissions >> over the network is the communication rate, so for each node it is >> 1/n.=94 >> I think =93the sum of transmissions=94 should be =93the sum of =20 >> transmission rates=94, right? This property is true only if all nodes = =20 >> have the same arrival rates. Is this always the case, or just the =20 >> case when using trickle? You probably mean that this is a long term =20= >> average, not always, right? > > I don't understand -- the same arrival rates? It's a lossless, =20 > single-hop network: when a node transmits, every other node hears =20 > the transmission. So the communication (reception+transmission) =20 > rates across the network are uniform. > > >> >> Sparser networks require more transmissions per node, but >> utilization of the radio channel over space will not increase. =20 >> This >> is an important property in wireless networks, where the channel =20= >> is a >> valuable shared resource. Additionally, reducing transmissions in >> dense networks conserves system energy.=94 >> I think the word Trickle is missing in the above to emphasize the =20 >> fact that what you describe is true for the trickle mechanism, not =20= >> in a network consisting of both trickle control data together with =20= >> application data. > > Which sentence do you think is unclear? Is it that application data =20= > does not necessarily follow this property of scaling? I'd like to =20 > think there is some context, and that it doesn't have to be that =20 > every sentence says Trickle in it. > > >> >> >> I have some questions/clarifications for section 4.2: >> Generally, what I think required is a more precise description of =20 >> the term =93interval=94. >> When does an interval start? When did the previous ended? After the =20= >> previous I expires or when t is reached (and transmission or =20 >> suppression of transmission is decided on)? It is not so clear in =20 >> the text. If it is when I expires, then after the transmission a =20 >> node must wait from the randomized time t till I expires and then =20 >> re-randomize the next t, and that leads to the question of what =20 >> happens with all the (in)consistencies it hears till the next =20 >> interval starts? Should they be counted as well (in step 2 it says =20= >> to count all consistencies and in step 1 it says to set c to 0, =20 >> i.e. disregard counts from t till I expires)? Some clarification =20 >> would be helpful. > > =46rom -02: > > o I, the current interval size > > 1. When an interval begins, Trickle resets c to 0 and sets t to a > random point in the interval, taken from the range [I/2, I). > > I'm not sure how this can be more precise... would changing the text =20= > to > > 1. When an interval begins, Trickle resets c to 0 and sets t to a > random point in the interval, taken from the range [I/2, I). The > interval ends at I. > > be helpful? > >> >> One comment on operational considerations (section 6): >> Do you see value in describing some typical =93events=94 that can be =20= >> used to reset the timer? What are the guidelines/limitations for =20 >> doing these resets, what could be considered good events and what =20 >> could be considered bad events? >> > > I'm really a bit wary of doing this -- almost any recommendations we =20= > could come up with would be wrong in some cases. E.g., the =20 > recommendations for multicast are very different than protocol =20 > acknowledgment timing. Perhaps the document can point to references =20= > of a few examples of its use, from which a reader might benefit? > > Phil > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Tue Aug 17 01:13:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60AD73A6819 for ; Tue, 17 Aug 2010 01:13:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.933 X-Spam-Level: X-Spam-Status: No, score=-107.933 tagged_above=-999 required=5 tests=[AWL=-2.335, BAYES_00=-2.599, GB_SUMOF=5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8iTRHH8k99al for ; Tue, 17 Aug 2010 01:13:28 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DC0B23A6768 for ; Tue, 17 Aug 2010 01:13:26 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOPhaUxAZnwN/2dsb2JhbACBRJ53caESnBmFNwSJZ4Jph1E X-IronPort-AV: E=Sophos;i="4.55,381,1278288000"; d="scan'208,217";a="148695255" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 17 Aug 2010 08:14:01 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7H8E1gJ022044; Tue, 17 Aug 2010 08:14:01 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Aug 2010 10:14:01 +0200 Received: from [192.168.1.10] ([10.55.83.155]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Aug 2010 10:14:00 +0200 Message-Id: <35B7D21E-5419-4932-9E24-C0E4EED66E50@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-205-930445976 Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Aug 2010 10:14:00 +0200 References: <18EB6233-3FC3-4CEB-B284-EC21ACA5563B@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Aug 2010 08:14:00.0521 (UTC) FILETIME=[25BD9390:01CB3DE4] Cc: ROLL WG , T.Clausen@computer.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 08:13:34 -0000 --Apple-Mail-205-930445976 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable On Jul 29, 2010, at 12:47 PM, Yoav Ben-Yehezkel wrote: > Thanks Phil, > > I think now I understand better some of the points. With these =20 > understandings, I=92d like to bring up some more the topics for =20 > further discussion. I=92m OK with all your explanations excluding the =20= > ones that are in the below list. > > ---- > > Suggest to replace the term =93wireless=94 with =93LLN=94 (trickle = is =20 > potentially not used solely by wireless =96 though it was developed on = =20 > a wireless platform I understand). > =85 > Phil: "Correspondingly, I don't think LLN is the right term either. =20= > How about "lossy broadcast-based networks," with a few examples =20 > (e.g., wireless, PLC)?" > > Yoav: I definitely support the examples. > I'm not familiar with the term "lossy broadcast-based networks", is =20= > this a commonly used term? Nope > To me, something like "lossy and partially connected networks" would =20= > make more sense. But if people understand what that means, I =20 > wouldn't object. > ---- > > Last paragraph of section 3 is a little unclear to me. > =85 > > Phil: Would it make more sense if the text read "Trickle =20 > communication rate" rather than "communication rate?" > > Yoav: It would make sense to explain some terminology. This is a good suggestion since the question was asked for several =20 terms: Phil, would you mind adding a short terminology section ? > For example, communication rate, maybe also: (in)consistency, event, =20= > maybe also =93lossy broadcast-based networks=94 that you spoke of =20 > earlier. Specifically, to me the term =93communication rate=94 was not = =20 > self-explanatory and I would appreciate it if you described it =20 > somewhere. > > Yoav: Something like: =94communication rate =96 the communication rate = =20 > of a node is the sum of transmission and reception rates of this =20 > node.=94 > Yoav: maybe also: =93Trickle communication rate =96 the trickle =20 > communication rate equals the communication rate of trickle messages =20= > only.=94 > > With this understanding in mind, I still think that the sentence: > =93 A single, disconnected node must transmit at the communication =20= > rate.=94 > > Yoav: Is somewhat misleading, and mixes the outcome with the given =20 > scenario. > > Yoav: Would you consider a re-write in the form of: > Yoav: "In the case of a single, disconnected node, the communication =20= > rate is equal to the transmission rate." > > Yoav: Is this what you were trying to say? > ---- > > > > =93 In a lossless, single-hop network of size n, the sum of =20 > transmissions > > over the network is the communication rate, so for each node it =20= > is > > 1/n.=94 > =85 > Yoav: How does one sum up transmissions? It is not a numeric value. =20= > One can count them, or sum their rates. > > Yoav: I agree that the transmission rates will be uniformly =20 > distributed when using the trickle and the same communication rates =20= > will be the sum of the transmission rates. > > Yoav: Trying to follow this logic, I would like to propose the =20 > following re-write here: > Yoav: " In a lossless, single-hop network of size n, the sum of =20 > transmission rates of trickle messages (summed over all nodes) =20 > equals the trickle communication rate of each node separately. The =20 > trickle mechanism balances the load in such a scenario, such that =20 > for each node, the transmission rate of trickle messages is 1/n =20 > times the trickle communication rate." > > Yoav: Is the above correct? Does it clarify my point better? > ---- > > I have some questions/clarifications for section 4.2: > =85 > Phil: I'm not sure how this can be more precise... would changing =20 > the text to > > Phil: 1. When an interval begins, Trickle resets c to 0 and sets =20= > t to a > random point in the interval, taken from the range [I/2, I). =20= > The > interval ends at I. > > Phil: be helpful? > > Yoav: Yes! So is my understanding that between t and I, there's no =20 > meaning to counting consistencies correct? Would it promote this =20 > understanding (not so much implementation or correctness) if you =20 > change rule 2. to: > > Yoav: " 2. Whenever Trickle hears a transmission that is =20 > "consistent," it > increments counter c." to: > > Yoav: " 2. Whenever Trickle hears a transmission that is =20 > "consistent," until t expires, it > increments counter c." > ---- > > One comment on operational considerations (section 6): > =85 > Phil: Perhaps the document can point to references of a few examples =20= > of its use, from which a reader might benefit? > > Yoav: that would be good enough for me. > ---- > > Thanks for the productive response. > > Best Regards, > Yoav > > > -----Original Message----- > From: Philip Levis [mailto:pal@cs.stanford.edu] > Sent: Thursday, July 29, 2010 12:50 PM > To: Yoav Ben-Yehezkel > Cc: T.Clausen@computer.org; jhui@archrock.com; =20 > gnawali@cs.stanford.edu;jgko@cs.jhu.edu; roll@ietf.org > Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 > > Yoav, my comments are inline. > On Jul 29, 2010, at 8:58 AM, Yoav Ben-Yehezkel wrote: > > > Authors/ROLL WG, > > > > Find below some minor comments/clarifications I have on the =20 > Trickle draft. > > > > Suggest to replace the term =93wireless=94 with =93LLN=94 (trickle = is =20 > potentially not used solely by wireless =96 though it was developed on = =20 > a wireless platform I understand). > > > > It appears in the abstract, in the intro, at the last para of =20 > section 3., at section 6.7. > > =93Abstract > > > > The Trickle algorithm allows wireless nodes to exchange =20 > information > > in a highly robust,...=94 > > > > > > =931. Introduction > > > > The Trickle algorithm is designed for wireless networks.=94 > > > > =933. Trickle Algorithm Overview > > =85 Sparser networks require more transmissions per node, but > > utilization of the radio channel over space will not increase. =20= > This > > is an important property in wireless networks, where the =20 > channel is a > > valuable shared resource.=94 > > > > =936.7. Tweaks and improvements to Trickle > > =85 However, in dynamic network environments such as wireless, > > the coordination needed to compute the=85 > > This is a good point. What this text is trying to get at is that =20 > Trickle is designed for, and well-suited to, lossy broadcast media. =20= > We've never really examined its use in low-loss switched networks =20 > (e.g., Ethernet). When the algorithm was designed, lossy broadcast =20 > media basically meant wireless, and not just low-power wireless. =20 > E.g., Trickle is well suited to 802.11. We didn't really consider =20 > PLC -- in the context of ROLL, however, it should definitely be =20 > considered. > > Correspondingly, I don't think LLN is the right term either. How =20 > about "lossy broadcast-based networks," with a few examples (e.g., =20 > wireless, PLC)? > > > > > > > Last paragraph of section 3 is a little unclear to me. > > =93 A single, disconnected node must transmit at the communication =20= > rate.=94 > > Can you clarify this sentence? What do you mean by =93must transmit =20= > at the communication rate=94? The communication rate is the output of =20= > the number of transmissions a disconnected node makes, not the other =20= > way around. > > Ah -- I see. This sentence is referring to the prior paragraph, =20 > which reads: > > "As long as the network is connected and there is some minimum =20 > communication rate for each node, the network will reach eventual =20 > consistency." > > The point is that communication is either transmission or reception =20= > and that the edge case of a solitary node, its communication will be =20= > all transmissions. In networks of multiple nodes, a node's =20 > communication can be some mix of receptions and transmissions. > > Would it make more sense if the text read "Trickle communication =20 > rate" rather than "communication rate?" > > > > > > > =93 In a lossless, single-hop network of size n, the sum of =20 > transmissions > > over the network is the communication rate, so for each node it =20= > is > > 1/n.=94 > > I think =93the sum of transmissions=94 should be =93the sum of =20 > transmission rates=94, right? This property is true only if all nodes =20= > have the same arrival rates. Is this always the case, or just the =20 > case when using trickle? You probably mean that this is a long term =20= > average, not always, right? > > I don't understand -- the same arrival rates? It's a lossless, =20 > single-hop network: when a node transmits, every other node hears =20 > the transmission. So the communication (reception+transmission) =20 > rates across the network are uniform. > > > > > > Sparser networks require more transmissions per node, but > > utilization of the radio channel over space will not increase. =20= > This > > is an important property in wireless networks, where the =20 > channel is a > > valuable shared resource. Additionally, reducing transmissions =20= > in > > dense networks conserves system energy.=94 > > I think the word Trickle is missing in the above to emphasize the =20= > fact that what you describe is true for the trickle mechanism, not =20 > in a network consisting of both trickle control data together with =20 > application data. > > Which sentence do you think is unclear? Is it that application data =20= > does not necessarily follow this property of scaling? I'd like to =20 > think there is some context, and that it doesn't have to be that =20 > every sentence says Trickle in it. > > > > > > > > I have some questions/clarifications for section 4.2: > > Generally, what I think required is a more precise description of =20= > the term =93interval=94. > > When does an interval start? When did the previous ended? After =20 > the previous I expires or when t is reached (and transmission or =20 > suppression of transmission is decided on)? It is not so clear in =20 > the text. If it is when I expires, then after the transmission a =20 > node must wait from the randomized time t till I expires and then re-=20= > randomize the next t, and that leads to the question of what happens =20= > with all the (in)consistencies it hears till the next interval =20 > starts? Should they be counted as well (in step 2 it says to count =20 > all consistencies and in step 1 it says to set c to 0, i.e. =20 > disregard counts from t till I expires)? Some clarification would be =20= > helpful. > > =46rom -02: > > o I, the current interval size > > 1. When an interval begins, Trickle resets c to 0 and sets t to a > random point in the interval, taken from the range [I/2, I). > > I'm not sure how this can be more precise... would changing the text =20= > to > > 1. When an interval begins, Trickle resets c to 0 and sets t to a > random point in the interval, taken from the range [I/2, I). =20= > The > interval ends at I. > > be helpful? > > > > > One comment on operational considerations (section 6): > > Do you see value in describing some typical =93events=94 that can be = =20 > used to reset the timer? What are the guidelines/limitations for =20 > doing these resets, what could be considered good events and what =20 > could be considered bad events? > > > > I'm really a bit wary of doing this -- almost any recommendations we =20= > could come up with would be wrong in some cases. E.g., the =20 > recommendations for multicast are very different than protocol =20 > acknowledgment timing. Perhaps the document can point to references =20= > of a few examples of its use, from which a reader might benefit? > > Phil > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --Apple-Mail-205-930445976 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
On Jul 29, 2010, = at 12:47 PM, Yoav Ben-Yehezkel wrote:

Thanks Phil,

I think now I understand better some of the = points. With these understandings, I=92d like to bring up some more the = topics for further discussion. I=92m OK with all your explanations = excluding the ones that are in the below list.

 

----
> Suggest to replace the = term =93wireless=94 with =93LLN=94 (trickle is potentially not used = solely by wireless =96 though it was developed on a wireless platform I = understand).
=85
Phil: "Correspondingly, I don't think = LLN is the right term either. How about "lossy broadcast-based = networks," with a few examples (e.g., wireless, PLC)?"

 

Yoav: I definitely support the = examples.
I'm not familiar with the term "lossy = broadcast-based networks", is this a commonly used term? =

Nope

To me, something like "lossy and partially = connected networks" would make more sense. But if people understand what = that means, I wouldn't object.
----
> Last paragraph of = section 3 is a little unclear to me.
=85

Phil: Would it make more sense if the text read = "Trickle communication rate" rather than "communication rate?"

 

Yoav: It would make sense to explain = some terminology. =

This is a good = suggestion since the question was asked for several terms: Phil, would = you mind adding a short terminology section ?

For example, communication rate, maybe also: = (in)consistency, event, maybe also =93lossy broadcast-based networks=94 = that you spoke of earlier. Specifically, to me the term =93communication = rate=94 was not self-explanatory and I would appreciate it if you = described it somewhere.

Yoav: Something like: =94communication rate =96 = the communication rate of a node is the sum of transmission and = reception rates of this node.=94

Yoav: maybe also: =93Trickle = communication rate =96 the trickle communication rate equals the = communication rate of trickle messages only.=94

 

With this understanding in mind, I = still think that the sentence:
 =93  A single, disconnected = node must transmit at the communication rate.=94

 

Yoav: Is somewhat misleading, and mixes = the outcome with the given scenario.

Yoav: Would you consider a re-write in the form = of:

Yoav: "In the case of a single, disconnected = node, the communication rate is equal to the transmission rate."

 

Yoav: Is this what you were trying to = say?
----
> 
> =93  In a = lossless, single-hop network of size n, the sum of = transmissions
>    over the network is the = communication rate, so for each node it is
>    = 1/n.=94  
=85
Yoav: How does one sum up = transmissions? It is not a numeric value. One can count them, or sum = their rates.

 

Yoav: I agree that the = transmission rates will be uniformly distributed when using the trickle = and the same communication rates will be the sum of the transmission = rates.

 

Yoav: Trying to follow this = logic, I would like to propose the following re-write here:
Yoav: " In = a lossless, single-hop network of size n, the sum of transmission rates = of trickle messages (summed over all nodes) equals the trickle = communication rate of each node separately. The trickle mechanism = balances the load in such a scenario, such that for each node, the = transmission rate of trickle messages is 1/n times the trickle = communication rate."

 

Yoav: Is = the above correct? Does it clarify my point better?
> I have some questions/clarifications for = section 4.2:
=85
Phil: I'm not sure how this can be more = precise... would changing the text to

Phil:   1.  When an interval = begins, Trickle resets c to 0 and sets t to a

       = interval ends at I.

 

Phil: be = helpful?

 

Yoav: Yes! So is my = understanding that between t and I, there's no meaning to counting = consistencies correct? Would it promote this understanding (not so much = implementation or correctness) if you change rule 2. to:

 

Yoav: " 2.  Whenever Trickle hears = a transmission that is "consistent," it

 

Yoav: " 2. Whenever Trickle = hears a transmission that is "consistent," until t expires, = it
> One comment on operational considerations = (section 6):
=85
Phil: Perhaps the document can point to = references of a few examples of its use, from which a reader might = benefit?

 

Yoav: that would be good = enough for me.
----

Thanks for the productive response.

 

Best Regards,
 

-----Original Message-----
From: Philip = Levis [mailto:pal@cs.stanford.edu] 
Sent: Thursday, July = 29, 2010 12:50 PM
To: Yoav Ben-Yehezkel
Cc: T.Clausen@computer.org; jhui@archrock.com; gnawali@cs.stanford.edu;jgko@cs.jhu.edu; roll@ietf.org
Subject: Re: [Roll] WG Last Call on = draft-ietf-roll-trickle-02

Yoav, my comments are inline.

On Jul 29, = 2010, at 8:58 AM, Yoav Ben-Yehezkel wrote:

> Authors/ROLL WG,

> Find below some minor = comments/clarifications I have on the Trickle draft.
> Suggest to replace the term =93wireless=94 = with =93LLN=94 (trickle is potentially not used solely by wireless =96 = though it was developed on a wireless platform I understand).
> It appears in the abstract, in the intro, = at the last para of section 3., at section 6.7.
> = =93Abstract
> 
>    The Trickle = algorithm allows wireless nodes to exchange information
> 
> =931.  Introduction
>    The Trickle algorithm is = designed for wireless networks.=94
> 
> =933. Trickle Algorithm = Overview
>    =85 Sparser networks = require more transmissions per node, but
>    = utilization of the radio channel over space will not increase.  = This
>    is an important property = in wireless networks, where the channel is a
> =936.7.  Tweaks and improvements to = Trickle
>    =85 However, in dynamic = network environments such as wireless,
>    the = coordination needed to compute the=85

This is a good point. What this text is trying = to get at is that Trickle is designed for, and well-suited to, lossy = broadcast media. We've never really examined its use in low-loss = switched networks (e.g., Ethernet). When the algorithm was designed, = lossy broadcast media basically meant wireless, and not just low-power = wireless. E.g., Trickle is well suited to 802.11. We didn't really = consider PLC -- in the context of ROLL, however, it should definitely be = considered.

 

Correspondingly, I don't = think LLN is the right term either. How about "lossy broadcast-based = networks," with a few examples (e.g., wireless, PLC)?

 

> 
> 
> Last = paragraph of section 3 is a little unclear to me.
> = =93  A single, disconnected node must transmit at the communication = rate.=94
> Can you clarify this sentence? What do you = mean by =93must transmit at the communication rate=94? The communication = rate is the output of the number of transmissions a disconnected node = makes, not the other way around.

Ah -- I see. This sentence is referring to the = prior paragraph, which reads:

"As long as the network is connected and there = is some minimum communication rate for each node, the network will reach = eventual consistency."

 

The point = is that communication is either transmission or reception and that the = edge case of a solitary node, its communication will be all = transmissions. In networks of multiple nodes, a node's communication can = be some mix of receptions and transmissions.

 

Would it make more sense if the text = read "Trickle communication rate" rather than "communication = rate?"

 

 

> 
> = =93  In a lossless, single-hop network of size n, the sum of = transmissions
>    over the network is the = communication rate, so for each node it is
>    = 1/n.=94
> I think =93the sum of transmissions=94 = should be =93the sum of transmission rates=94, right? This property is = true only if all nodes have the same arrival rates. Is this always the = case, or just the case when using trickle? You probably mean that this = is a long term average, not always, right?

I don't understand -- the same arrival rates? = It's a lossless, single-hop network: when a node transmits, every other = node hears the transmission. So the communication = (reception+transmission) rates across the network are uniform.

 

> 

>    Sparser networks = require more transmissions per node, but
>    = utilization of the radio channel over space will not increase.  = This
>    is an important property = in wireless networks, where the channel is a
>    dense networks = conserves system energy.=94
> I think the word Trickle is = missing in the above to emphasize the fact that what you describe is = true for the trickle mechanism, not in a network consisting of both = trickle control data together with application data.

 

Which sentence do you think is unclear? = Is it that application data does not necessarily follow this property of = scaling? I'd like to think there is some context, and that it doesn't = have to be that every sentence says Trickle in it.

 

> 

> 
> I have some = questions/clarifications for section 4.2:
> Generally, what I think = required is a more precise description of the term =93interval=94.
> When = does an interval start? When did the previous ended? After the previous = I expires or when t is reached (and transmission or suppression of = transmission is decided on)? It is not so clear in the text. If it = is  when I expires, then after the transmission a node must wait = from the randomized time t till I expires and then re-randomize the next = t, and that leads to the question of what happens with all the = (in)consistencies it hears till the next interval starts? Should they be = counted as well (in step 2 it says to count all consistencies and in = step 1 it says to set c to 0, i.e. disregard counts from t till I = expires)? Some clarification would be helpful.

 

=46rom -02:

 

   o I, the current interval = size

 

   1.  When = an interval begins, Trickle resets c to 0 and sets t to a
I'm not sure how this can be more precise... = would changing the text to

   1.  When an interval begins, = Trickle resets c to 0 and sets t to a

       = interval ends at I.

 

be = helpful?

 

> 
> One = comment on operational considerations (section 6):
> Do = you see value in describing some typical =93events=94 that can be used = to reset the timer? What are the guidelines/limitations for doing these = resets, what could be considered good events and what could be = considered bad events?
>

I'm really a bit wary of doing this -- almost = any recommendations we could come up with would be wrong in some cases. = E.g., the recommendations for multicast are very different than protocol = acknowledgment timing. Perhaps the document can point to references of a = few examples of its use, from which a reader might benefit?

 

Phil

Roll@ietf.org
From: JP Vasseur To: Philip Levis In-Reply-To: <75AAB6AE-B4ED-435E-9F37-5135356165D4@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Aug 2010 10:22:59 +0200 References: <4C57317E.3070900@gmail.com> <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> <75AAB6AE-B4ED-435E-9F37-5135356165D4@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Aug 2010 08:23:00.0266 (UTC) FILETIME=[677420A0:01CB3DE5] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17574.005 X-TM-AS-Result: No--9.580400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 08:22:28 -0000 On Aug 5, 2010, at 2:22 AM, Philip Levis wrote: > > On Aug 4, 2010, at 10:08 AM, Ulrich Herberg wrote: > >> >> That sounds reasonable. Would all nodes in the network have to >> agree (i.e. by preconfiguration) on the same multicast address? I >> guess so... > > Hm -- I actually think it would be specified by the protocol using > Trickle. E.g., some protocols might just use the link-local > multicast address, while RPL, say, uses the All-RPL-Nodes local > multicast address. It's not inconceivable that a protocol allows > this address to be configured, but my feeling is that such a > statement belongs outside this particular draft. Indeed, it is out of the scope of this document (this is why we have it a separate document, not tied to a specific protocol). > Does that make sense? > > Phil > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Tue Aug 17 01:26:13 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB073A68DE for ; Tue, 17 Aug 2010 01:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.415 X-Spam-Level: X-Spam-Status: No, score=-110.415 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qYdK0xqzvoyi for ; Tue, 17 Aug 2010 01:26:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D2D673A6784 for ; Tue, 17 Aug 2010 01:26:10 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHbkaUyrRN+J/2dsb2JhbACgO3GhBpwXhTcEiWeCaQ X-IronPort-AV: E=Sophos;i="4.55,381,1278288000"; d="scan'208";a="352701446" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 17 Aug 2010 08:26:46 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o7H8QZUI019285; Tue, 17 Aug 2010 08:26:46 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Aug 2010 10:26:44 +0200 Received: from [192.168.1.10] ([10.55.83.155]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Aug 2010 10:26:44 +0200 Message-Id: From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C5A86A0.7000101@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Aug 2010 10:26:43 +0200 References: <4C57317E.3070900@gmail.com> <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> bc58199e3b35de85c3e16aec79b13992@mail.gmail.com <3895b8f23b1fa4216210be0d92c8d064@mail.gmail.com> <4C59C196.7020303@gmail.com> <4C5A86A0.7000101@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Aug 2010 08:26:44.0197 (UTC) FILETIME=[ECED4950:01CB3DE5] Cc: roll@ietf.org Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 08:26:13 -0000 On Aug 5, 2010, at 11:38 AM, Alexandru Petrescu wrote: > Le 05/08/2010 00:20, Philip Levis a =E9crit : >> >> On Aug 4, 2010, at 12:37 PM, Alexandru Petrescu wrote: >> >>> Le 04/08/2010 00:34, Philip Levis a =E9crit : >>>> >>>> On Aug 2, 2010, at 10:40 PM, Yoav Ben-Yehezkel wrote: >>>> >>>>> One more thing - >>>>> >>>>> Maybe in your description you should consider also saying that >>>>> trickle can also be used by link layers when the destination is >>>>> broadcast or multicast. As you've noted trickle is a mechanism >>>>> that doesn't really have to be bound to RPL nor to IP. >>>>> >>>>> What do you think? >>>> >>>> I agree 100%. The point is that it's to a set of nearby nodes: >>> >>> One would like to make sure _all_ nearby nodes that author needs >>> to receive the Trickle message _will_ receive, otherwise I guess >>> Trickle will fail to maintain consistency, no? >> >> Sort of. You won't reach consistency in a disconnected neighbor, but >> the reliable delivery of individual messages is not that critical. >> This is an important consideration, given the lossy nature of >> wireless. >> >> >>> >>> (draft Trickle says: >>>> 5. If Trickle hears a transmission that is "inconsistent," the >>>> Trickle timer resets. >>> what if a Trickle nodes does not hear a transmission which it >>> would otherwise qualify as inconsistent.) >>> >>> ("near" is also a hard to define term when we talk IP). >>> >>> Phil said: >>>> how this manifests in terms of addressing greatly depends on what >>>> the underlying technologies are. I'll work on some text to try to >>>> communicate this fact. >>> >>> Phil - just to continue on this discussion. >>> >>> Currently IPv6 isn't specified to run on anything which does not >>> support link layer multicast. (exceptions are point-to-point links >>> such as ppp and or IP-IP or GRE or other IP tunnel interfaces, >>> where the addressing model is very simple: only two points are >>> hearing each other.) >>> >>> IPv6 went to a great deal of effort to specify how the link layer >>> addressing (MAC and such) converts to IPv6 link-local addresses: >>> mapping functions of rfc2464, rfc4191, and more. These cases can >>> be enumerated and implemented, not left to unspecified cases. >>> >>> Trickle not being a protocol, it is supposed to use one. If that >>> protocol is IPv6 (e.g. ND, RPL, DHCP) then it won't work on >>> something not using link layer multicast. >>> >>> Trickle running on something else than IP (i.e. Trickle on top of >>> MAC messages of IEEE.x) is yet another question. It is possible >>> that Trickle-straight-over-MAC may work without link-layer >>> multicast. But not using IP one may wonder about specifying >>> Trickle StdsTrack, or at IETF alltogether. >>> >>> Trickle over the adaptation layer mentioned in 6LoWPAN is probably >>> such an underlying technology one thinks of running Trickle on. >>> 802.15.4 high data rate does use link-layer multicast. >>> >>> IPv4 is indeed another question. >>> >>> Just some thoughts, biased of course :-) >> >> Given that this is the IETF, I think the right thing is to make sure >> the text is in that content. E.g., link-layer broadcast isn't >> important to cover. What makes this wording a little complex is the >> All-RPL-Nodes multicast address. > > Right, how about suggesting text on the list. I could dare to =20 > suggest: > > "Trickle is an algorithm. It is used by an IP protocol (RPL > [], more) to exchange formatted data related to IP routing; when RPL > uses Trickle, RPL sends data to all-rpl-routers multicast address; > when protocolX uses Trickle, protocolX sends data to addressX; a > protocol undefined yet, contemplating the use of Trickle, could send > data to an address yet to be defined.". I do not think that we need to say any word about addressing here. As =20= you said, Trickle is an algorithm. We just need to say that it applies to LLNs networks with a =20= bit of (obvious) explanations. > > Or something like this; it is good enough to me, although a bit =20 > long. Listening to what you think the text should be. > > Alex > >> >> Phil > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From jpv@cisco.com Tue Aug 17 01:26:14 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC7B83A6784 for ; Tue, 17 Aug 2010 01:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.417 X-Spam-Level: X-Spam-Status: No, score=-110.417 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OZBoOmSVgQ4A for ; Tue, 17 Aug 2010 01:26:10 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 192523A68C5 for ; Tue, 17 Aug 2010 01:26:09 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALLkaUyrRN+J/2dsb2JhbACgO3GhB5wXhTcEiWeCaQ X-IronPort-AV: E=Sophos;i="4.55,381,1278288000"; d="scan'208";a="574529612" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 17 Aug 2010 08:26:44 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o7H8QZUE019285; Tue, 17 Aug 2010 08:26:44 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Aug 2010 10:26:41 +0200 Received: from [192.168.1.10] ([10.55.83.155]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 17 Aug 2010 10:26:40 +0200 Message-Id: <0D8E5926-A3E0-44D9-91C3-C07425CC912B@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C5A86A0.7000101@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Tue, 17 Aug 2010 10:24:40 +0200 References: <4C57317E.3070900@gmail.com> <205C2F88-8310-471E-B907-63C5F99006AD@cs.stanford.edu> bc58199e3b35de85c3e16aec79b13992@mail.gmail.com <3895b8f23b1fa4216210be0d92c8d064@mail.gmail.com> <4C59C196.7020303@gmail.com> <4C5A86A0.7000101@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Aug 2010 08:26:40.0838 (UTC) FILETIME=[EAECBE60:01CB3DE5] Cc: roll@ietf.org Subject: Re: [Roll] Some comments on Trickle I-D as response to Trickle LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 08:26:14 -0000 On Aug 5, 2010, at 11:38 AM, Alexandru Petrescu wrote: > Le 05/08/2010 00:20, Philip Levis a =E9crit : >> >> On Aug 4, 2010, at 12:37 PM, Alexandru Petrescu wrote: >> >>> Le 04/08/2010 00:34, Philip Levis a =E9crit : >>>> >>>> On Aug 2, 2010, at 10:40 PM, Yoav Ben-Yehezkel wrote: >>>> >>>>> One more thing - >>>>> >>>>> Maybe in your description you should consider also saying that >>>>> trickle can also be used by link layers when the destination is >>>>> broadcast or multicast. As you've noted trickle is a mechanism >>>>> that doesn't really have to be bound to RPL nor to IP. >>>>> >>>>> What do you think? >>>> >>>> I agree 100%. The point is that it's to a set of nearby nodes: >>> >>> One would like to make sure _all_ nearby nodes that author needs >>> to receive the Trickle message _will_ receive, otherwise I guess >>> Trickle will fail to maintain consistency, no? >> >> Sort of. You won't reach consistency in a disconnected neighbor, but >> the reliable delivery of individual messages is not that critical. >> This is an important consideration, given the lossy nature of >> wireless. >> >> >>> >>> (draft Trickle says: >>>> 5. If Trickle hears a transmission that is "inconsistent," the >>>> Trickle timer resets. >>> what if a Trickle nodes does not hear a transmission which it >>> would otherwise qualify as inconsistent.) >>> >>> ("near" is also a hard to define term when we talk IP). >>> >>> Phil said: >>>> how this manifests in terms of addressing greatly depends on what >>>> the underlying technologies are. I'll work on some text to try to >>>> communicate this fact. >>> >>> Phil - just to continue on this discussion. >>> >>> Currently IPv6 isn't specified to run on anything which does not >>> support link layer multicast. (exceptions are point-to-point links >>> such as ppp and or IP-IP or GRE or other IP tunnel interfaces, >>> where the addressing model is very simple: only two points are >>> hearing each other.) >>> >>> IPv6 went to a great deal of effort to specify how the link layer >>> addressing (MAC and such) converts to IPv6 link-local addresses: >>> mapping functions of rfc2464, rfc4191, and more. These cases can >>> be enumerated and implemented, not left to unspecified cases. >>> >>> Trickle not being a protocol, it is supposed to use one. If that >>> protocol is IPv6 (e.g. ND, RPL, DHCP) then it won't work on >>> something not using link layer multicast. >>> >>> Trickle running on something else than IP (i.e. Trickle on top of >>> MAC messages of IEEE.x) is yet another question. It is possible >>> that Trickle-straight-over-MAC may work without link-layer >>> multicast. But not using IP one may wonder about specifying >>> Trickle StdsTrack, or at IETF alltogether. >>> >>> Trickle over the adaptation layer mentioned in 6LoWPAN is probably >>> such an underlying technology one thinks of running Trickle on. >>> 802.15.4 high data rate does use link-layer multicast. >>> >>> IPv4 is indeed another question. >>> >>> Just some thoughts, biased of course :-) >> >> Given that this is the IETF, I think the right thing is to make sure >> the text is in that content. E.g., link-layer broadcast isn't >> important to cover. What makes this wording a little complex is the >> All-RPL-Nodes multicast address. > > Right, how about suggesting text on the list. I could dare to =20 > suggest: > > "Trickle is an algorithm. It is used by an IP protocol (RPL > [], more) to exchange formatted data related to IP routing; when RPL > uses Trickle, RPL sends data to all-rpl-routers multicast address; > when protocolX uses Trickle, protocolX sends data to addressX; a > protocol undefined yet, contemplating the use of Trickle, could send > data to an address yet to be defined.". I do not think that we need to say any word about addressing here. As =20= you said, Trickle is an algorithm. We just need to say that it applies to LLNs networks with a =20= bit of (obvious) explanations. > > Or something like this; it is good enough to me, although a bit =20 > long. Listening to what you think the text should be. > > Alex > >> >> Phil > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Tue Aug 17 10:59:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 17D233A698D for ; Tue, 17 Aug 2010 10:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.229 X-Spam-Level: X-Spam-Status: No, score=-5.229 tagged_above=-999 required=5 tests=[AWL=-1.044, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DBxjBc31q0wt for ; Tue, 17 Aug 2010 10:59:26 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id C510A3A69F1 for ; Tue, 17 Aug 2010 10:59:26 -0700 (PDT) Received: from dn0a21010a.sunet ([10.33.1.10]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OlQSA-0003QE-2V; Tue, 17 Aug 2010 11:00:02 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Tue, 17 Aug 2010 11:00:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5FB5C986-D72B-41D9-A193-275DEB1D71A3@cisco.com> <7FE6DAEC-91E4-4FB9-A78C-65F7601A7624@cs.stanford.edu> To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 3acef658708772c1d00935e7d4d752c5 Cc: ROLL WG Subject: Re: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 17:59:28 -0000 On Aug 16, 2010, at 2:22 AM, JP Vasseur wrote: >=20 > On Aug 10, > For the WG, the misunderstanding was coming from the the use of = different notation. In some countries we use [a,b[ instead: >=20 > But that's OK let's use the [a,b) notation. >=20 > For the record: >=20 > (http://en.wikipedia.org/wiki/Interval_(mathematics)): > The ISO notation > International standard ISO 31-11 also defines another notation for = intervals, which seems to be more commonly taught in Europe[citation = needed] and South America. It uses an inwards pointing bracket to = indicate inclusion of the endpoint, and outwards-pointing bracket for = exclusion: > > Both notations may overlap with other uses of parentheses and brackets = in mathematics. For instance, the notation (a,b) is often used to denote = an ordered pair in set theory, the coordinates of a point or vector in = analytic geometry and linear algebra, or (sometimes) a complex number in = algebra. The notation [a,b] too is occasionally used for ordered pairs, = especially in computer science. > Some authors use ]a,b[ to denote the complement of the interval (a,b); = namely, the set of all real numbers that are either less than or equal = to a, or greater than or equal to b. > In countries where numbers are written with a decimal comma, a = semicolon may be used as a separator, to avoid ambiguity. Fascinating! Sorry for the confusion -- I had thought that at least = mathematics was an international language. :) I will add a sentence of = natural language to explain it. Phil= From pal@cs.stanford.edu Tue Aug 17 11:16:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6B953A6B0B for ; Tue, 17 Aug 2010 11:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.788 X-Spam-Level: X-Spam-Status: No, score=-5.788 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSfdtDWotEoY for ; Tue, 17 Aug 2010 11:15:56 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 2638F3A6B02 for ; Tue, 17 Aug 2010 11:14:19 -0700 (PDT) Received: from dn0a21010a.sunet ([10.33.1.10]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OlQgJ-00058q-SO; Tue, 17 Aug 2010 11:14:40 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <26B70EE3-049C-48A2-9DB4-F2E497758C42@cisco.com> Date: Tue, 17 Aug 2010 11:14:35 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4EEB160F-FEBC-40CE-9BFC-ECD1CB28848D@cs.stanford.edu> References: <5FB5C986-D72B-41D9-A193-275DEB1D71A3@cisco.com> <1FFABC6B-73B7-4549-A304-C34ABCB95366@cs.stanford.edu> <77778AA2-25F1-4F95-9036-3C9EAFD6A271@cisco.com> <37998A50-F016-43BF-94A3-8086EB05B714@cs.stanford.edu> <26B70EE3-049C-48A2-9DB4-F2E497758C42@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 127ff6e1eac6b45a32dc112250ed777d Cc: ROLL WG Subject: Re: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 18:16:29 -0000 On Aug 17, 2010, at 1:01 AM, JP Vasseur wrote: >=20 > On Aug 16, 2010, at 6:02 PM, Philip Levis wrote: >=20 >>=20 >> On Aug 16, 2010, at 2:20 AM, JP Vasseur wrote: >>=20 >>>>>>=20 >>>>>>=20 >>>>>> JP> I would suggest to add refs here. >>>>>> Nevertheless, there are situations where a protocol may wish to = turn >>>>>> off Trickle suppression. Because k is a natural number >>>>>> (Section 4.1), c=3D0 has no useful meaning. If a protocol allows = k to >>>>>> be dynamically configured, a value of 0 remains unused. For ease = of >>>>>> debugging and packet inspection, having the parameter describe = (c-1) >>>>=20 >>>> Disagree -- it's easier for debugging when the value equals the = value. There's later text about k=3D0 and using it to represent k=3Dinf. >>>=20 >>> JP>I do not see which comment you disagree on ? >>=20 >> Having the parameter describe c-1. I think it's easier if you have = the parameter describe c, and define c=3D0 as a special case. >=20 > What I am suggesting is to clarify the sentence ... (hard to parse) = ... why "counter-productive" ? > Just a question of wording, we agree on the content. How about "confusing" rather than "counter-productive?" I.e.: Nevertheless, there are situations where a protocol may wish to turn off Trickle suppression. Because k is a natural number (), k=3D0 has no useful meaning. If a protocol allows k to be dynamically configured, a value of 0 remains unused. For ease of debugging and packet inspection, having the parameter describe (k-1) can be confusing. Instead, it is RECOMMENDED that protocols which require turning off suppression reserve k=3D0 to mean k=3Dinfinity. How does that sound? Phil= From pal@cs.stanford.edu Tue Aug 17 11:36:11 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59AFA3A69A1 for ; Tue, 17 Aug 2010 11:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9+lxKgkt9fgd for ; Tue, 17 Aug 2010 11:36:10 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 527173A686B for ; Tue, 17 Aug 2010 11:36:10 -0700 (PDT) Received: from dn0a21010a.sunet ([10.33.1.10]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OlR1h-0001gY-Es; Tue, 17 Aug 2010 11:36:45 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: <924028EC-0491-44AF-9E21-AF735079C84C@cisco.com> Date: Tue, 17 Aug 2010 11:36:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4D8ADA77-31BE-4148-B1FB-E09C089927E8@cs.stanford.edu> References: <18EB6233-3FC3-4CEB-B284-EC21ACA5563B@cs.stanford.edu> <924028EC-0491-44AF-9E21-AF735079C84C@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 882c50607b8592e4560fe9069cd502a5 Cc: roll@ietf.org, T.Clausen@computer.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 18:36:11 -0000 On Aug 17, 2010, at 1:10 AM, JP Vasseur wrote: >=20 > On Jul 29, 2010, at 11:49 AM, Philip Levis wrote: >=20 >> Yoav, my comments are inline. >> On Jul 29, 2010, at 8:58 AM, Yoav Ben-Yehezkel wrote: >>=20 >>> Authors/ROLL WG, >>>=20 >>> Find below some minor comments/clarifications I have on the Trickle = draft. >>>=20 >>> Suggest to replace the term =93wireless=94 with =93LLN=94 (trickle = is potentially not used solely by wireless =96 though it was developed = on a wireless platform I understand). >>>=20 >>> It appears in the abstract, in the intro, at the last para of = section 3., at section 6.7. >>> =93Abstract >>>=20 >>> The Trickle algorithm allows wireless nodes to exchange information >>> in a highly robust,...=94 >>>=20 >>>=20 >>> =931. Introduction >>>=20 >>> The Trickle algorithm is designed for wireless networks.=94 >>>=20 >>> =933. Trickle Algorithm Overview >>> =85 Sparser networks require more transmissions per node, but >>> utilization of the radio channel over space will not increase. = This >>> is an important property in wireless networks, where the channel is = a >>> valuable shared resource.=94 >>>=20 >>> =936.7. Tweaks and improvements to Trickle >>> =85 However, in dynamic network environments such as wireless, >>> the coordination needed to compute the=85 >>=20 >> This is a good point. What this text is trying to get at is that = Trickle is designed for, and well-suited to, lossy broadcast media. = We've never really examined its use in low-loss switched networks (e.g., = Ethernet). When the algorithm was designed, lossy broadcast media = basically meant wireless, and not just low-power wireless. E.g., Trickle = is well suited to 802.11. We didn't really consider PLC -- in the = context of ROLL, however, it should definitely be considered. >>=20 >> Correspondingly, I don't think LLN is the right term either. How = about "lossy broadcast-based networks," with a few examples (e.g., = wireless, PLC)? >=20 > I would much prefer LLN: > * This is the term used across all documents in ROLL > * PLC are also low power and lossy I currently have the text as: The Trickle algorithm allows nodes in a lossy shared medium to exchange information in a highly robust, energy efficient, simple, and scalable manner. How about: The Trickle algorithm allows nodes in a lossy shared medium (e.g., = low power and lossy networks) to exchange information in a highly robust, = energy efficient, simple, and scalable manner. I'd say "LLNs" but don't want to put a reference in the abstract. Phil= From jpv@cisco.com Tue Aug 17 15:19:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E303A681E for ; Tue, 17 Aug 2010 15:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.418 X-Spam-Level: X-Spam-Status: No, score=-110.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Aa331Dk3KCiX for ; Tue, 17 Aug 2010 15:19:39 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9C8383A67D7 for ; Tue, 17 Aug 2010 15:19:39 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACuoakyrR7Hu/2dsb2JhbACgQXGkUptuhTcEiWeCaYdS X-IronPort-AV: E=Sophos;i="4.56,224,1280707200"; d="scan'208";a="352996801" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-1.cisco.com with ESMTP; 17 Aug 2010 22:20:15 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7HMK7fL011707; Tue, 17 Aug 2010 22:20:14 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 00:20:13 +0200 Received: from [192.168.1.10] ([10.55.83.155]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 00:20:12 +0200 Message-Id: <648480C3-C279-4152-A7B5-F66E457A663C@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Aug 2010 00:20:12 +0200 References: <5FB5C986-D72B-41D9-A193-275DEB1D71A3@cisco.com> <7FE6DAEC-91E4-4FB9-A78C-65F7601A7624@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Aug 2010 22:20:12.0803 (UTC) FILETIME=[5C60FD30:01CB3E5A] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17576.002 X-TM-AS-Result: No--11.904100-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 22:19:41 -0000 Great, thanks. JP. On Aug 17, 2010, at 8:00 PM, Philip Levis wrote: > On Aug 16, 2010, at 2:22 AM, JP Vasseur wrote: > >> >> On Aug 10, >> For the WG, the misunderstanding was coming from the the use of >> different notation. In some countries we use [a,b[ instead: >> >> But that's OK let's use the [a,b) notation. >> >> For the record: >> >> (http://en.wikipedia.org/wiki/Interval_(mathematics)): >> The ISO notation >> International standard ISO 31-11 also defines another notation for >> intervals, which seems to be more commonly taught in >> Europe[citation needed] and South America. It uses an inwards >> pointing bracket to indicate inclusion of the endpoint, and >> outwards-pointing bracket for exclusion: >> >> Both notations may overlap with other uses of parentheses and >> brackets in mathematics. For instance, the notation (a,b) is often >> used to denote an ordered pair in set theory, the coordinates of a >> point or vector in analytic geometry and linear algebra, or >> (sometimes) a complex number in algebra. The notation [a,b] too is >> occasionally used for ordered pairs, especially in computer science. >> Some authors use ]a,b[ to denote the complement of the interval >> (a,b); namely, the set of all real numbers that are either less >> than or equal to a, or greater than or equal to b. >> In countries where numbers are written with a decimal comma, a >> semicolon may be used as a separator, to avoid ambiguity. > > Fascinating! Sorry for the confusion -- I had thought that at least > mathematics was an international language. :) I will add a sentence > of natural language to explain it. > > Phil From jpv@cisco.com Tue Aug 17 15:20:31 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 997A43A67F3 for ; Tue, 17 Aug 2010 15:20:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.82 X-Spam-Level: X-Spam-Status: No, score=-109.82 tagged_above=-999 required=5 tests=[AWL=-0.421, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wvMfDbUC1qnH for ; Tue, 17 Aug 2010 15:20:30 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C940E3A67D7 for ; Tue, 17 Aug 2010 15:20:30 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKKoakyrR7Hu/2dsb2JhbACgQXGkUJtuhTcEiWeCaYdS X-IronPort-AV: E=Sophos;i="4.56,224,1280707200"; d="scan'208";a="574979307" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 17 Aug 2010 22:21:06 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7HML5wG012440; Tue, 17 Aug 2010 22:21:05 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 00:21:04 +0200 Received: from [192.168.1.10] ([10.55.83.155]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 00:21:04 +0200 Message-Id: From: JP Vasseur To: Philip Levis In-Reply-To: <4EEB160F-FEBC-40CE-9BFC-ECD1CB28848D@cs.stanford.edu> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Aug 2010 00:21:04 +0200 References: <5FB5C986-D72B-41D9-A193-275DEB1D71A3@cisco.com> <1FFABC6B-73B7-4549-A304-C34ABCB95366@cs.stanford.edu> <77778AA2-25F1-4F95-9036-3C9EAFD6A271@cisco.com> <37998A50-F016-43BF-94A3-8086EB05B714@cs.stanford.edu> <26B70EE3-049C-48A2-9DB4-F2E497758C42@cisco.com> <4EEB160F-FEBC-40CE-9BFC-ECD1CB28848D@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Aug 2010 22:21:04.0225 (UTC) FILETIME=[7B075D10:01CB3E5A] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17576.002 X-TM-AS-Result: No--17.447600-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: ROLL WG Subject: Re: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 22:20:31 -0000 On Aug 17, 2010, at 8:14 PM, Philip Levis wrote: > > On Aug 17, 2010, at 1:01 AM, JP Vasseur wrote: > >> >> On Aug 16, 2010, at 6:02 PM, Philip Levis wrote: >> >>> >>> On Aug 16, 2010, at 2:20 AM, JP Vasseur wrote: >>> >>>>>>> >>>>>>> >>>>>>> JP> I would suggest to add refs here. >>>>>>> Nevertheless, there are situations where a protocol may wish >>>>>>> to turn >>>>>>> off Trickle suppression. Because k is a natural number >>>>>>> (Section 4.1), c=0 has no useful meaning. If a protocol >>>>>>> allows k to >>>>>>> be dynamically configured, a value of 0 remains unused. For >>>>>>> ease of >>>>>>> debugging and packet inspection, having the parameter describe >>>>>>> (c-1) >>>>> >>>>> Disagree -- it's easier for debugging when the value equals the >>>>> value. There's later text about k=0 and using it to represent >>>>> k=inf. >>>> >>>> JP>I do not see which comment you disagree on ? >>> >>> Having the parameter describe c-1. I think it's easier if you have >>> the parameter describe c, and define c=0 as a special case. >> >> What I am suggesting is to clarify the sentence ... (hard to >> parse) ... why "counter-productive" ? >> Just a question of wording, we agree on the content. > > How about "confusing" rather than "counter-productive?" > > I.e.: > > Nevertheless, there are situations where a protocol may wish to > turn off Trickle suppression. Because k is a natural number ( target="Parameters"/>), k=0 has no useful meaning. If a protocol > allows k to be dynamically configured, a value of 0 remains > unused. For ease of debugging and packet inspection, having the > parameter describe (k-1) can be confusing. Instead, it is RECOMMENDED > that protocols which require turning off suppression reserve k=0 to > mean k=infinity. > > How does that sound? Crystal clear. Thanks. JP. > > Phil From jpv@cisco.com Tue Aug 17 15:21:38 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014D83A68AC for ; Tue, 17 Aug 2010 15:21:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.416 X-Spam-Level: X-Spam-Status: No, score=-110.416 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-8yi3nE6fc3 for ; Tue, 17 Aug 2010 15:21:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 78EFB3A67F3 for ; Tue, 17 Aug 2010 15:21:36 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKKoakyrR7H+/2dsb2JhbACgQXGkUJtuhTcEiWeCaYdS X-IronPort-AV: E=Sophos;i="4.56,224,1280707200"; d="scan'208";a="574980022" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 17 Aug 2010 22:22:12 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7HMMB98025955; Tue, 17 Aug 2010 22:22:11 GMT Received: from xfe-ams-102.cisco.com ([144.254.231.94]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 00:22:10 +0200 Received: from [192.168.1.10] ([10.55.83.155]) by xfe-ams-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 00:22:10 +0200 Message-Id: <55E742E3-BC9C-433A-9FFC-4A9756B13099@cisco.com> From: JP Vasseur To: Philip Levis In-Reply-To: <4D8ADA77-31BE-4148-B1FB-E09C089927E8@cs.stanford.edu> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Aug 2010 00:22:09 +0200 References: <18EB6233-3FC3-4CEB-B284-EC21ACA5563B@cs.stanford.edu> <924028EC-0491-44AF-9E21-AF735079C84C@cisco.com> <4D8ADA77-31BE-4148-B1FB-E09C089927E8@cs.stanford.edu> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 17 Aug 2010 22:22:10.0037 (UTC) FILETIME=[A2417A50:01CB3E5A] X-TM-AS-Product-Ver: SMEX-8.0.0.1181-6.500.1024-17576.002 X-TM-AS-Result: No--14.627400-8.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Cc: roll@ietf.org, T.Clausen@computer.org Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Aug 2010 22:21:38 -0000 That works. JP. On Aug 17, 2010, at 8:36 PM, Philip Levis wrote: > > On Aug 17, 2010, at 1:10 AM, JP Vasseur wrote: > >> >> On Jul 29, 2010, at 11:49 AM, Philip Levis wrote: >> >>> Yoav, my comments are inline. >>> On Jul 29, 2010, at 8:58 AM, Yoav Ben-Yehezkel wrote: >>> >>>> Authors/ROLL WG, >>>> >>>> Find below some minor comments/clarifications I have on the =20 >>>> Trickle draft. >>>> >>>> Suggest to replace the term =93wireless=94 with =93LLN=94 (trickle = is =20 >>>> potentially not used solely by wireless =96 though it was developed = =20 >>>> on a wireless platform I understand). >>>> >>>> It appears in the abstract, in the intro, at the last para of =20 >>>> section 3., at section 6.7. >>>> =93Abstract >>>> >>>> The Trickle algorithm allows wireless nodes to exchange information >>>> in a highly robust,...=94 >>>> >>>> >>>> =931. Introduction >>>> >>>> The Trickle algorithm is designed for wireless networks.=94 >>>> >>>> =933. Trickle Algorithm Overview >>>> =85 Sparser networks require more transmissions per node, but >>>> utilization of the radio channel over space will not increase. =20 >>>> This >>>> is an important property in wireless networks, where the channel =20= >>>> is a >>>> valuable shared resource.=94 >>>> >>>> =936.7. Tweaks and improvements to Trickle >>>> =85 However, in dynamic network environments such as wireless, >>>> the coordination needed to compute the=85 >>> >>> This is a good point. What this text is trying to get at is that =20 >>> Trickle is designed for, and well-suited to, lossy broadcast =20 >>> media. We've never really examined its use in low-loss switched =20 >>> networks (e.g., Ethernet). When the algorithm was designed, lossy =20= >>> broadcast media basically meant wireless, and not just low-power =20 >>> wireless. E.g., Trickle is well suited to 802.11. We didn't really =20= >>> consider PLC -- in the context of ROLL, however, it should =20 >>> definitely be considered. >>> >>> Correspondingly, I don't think LLN is the right term either. How =20 >>> about "lossy broadcast-based networks," with a few examples (e.g., =20= >>> wireless, PLC)? >> >> I would much prefer LLN: >> * This is the term used across all documents in ROLL >> * PLC are also low power and lossy > > I currently have the text as: > > The Trickle algorithm allows nodes in a lossy shared medium to > exchange information in a highly robust, energy efficient, simple, > and scalable manner. > > How about: > > The Trickle algorithm allows nodes in a lossy shared medium (e.g., =20= > low power > and lossy networks) to exchange information in a highly robust, =20 > energy efficient, simple, > and scalable manner. > > I'd say "LLNs" but don't want to put a reference in the abstract. > > Phil From jpv@cisco.com Wed Aug 18 12:29:36 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A55973A6A81 for ; Wed, 18 Aug 2010 12:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.418 X-Spam-Level: X-Spam-Status: No, score=-110.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ldT56-g9sHpX for ; Wed, 18 Aug 2010 12:29:35 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id B8FC23A67D4 for ; Wed, 18 Aug 2010 12:29:35 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANLRa0yrRN+J/2dsb2JhbACgU3GlFpt1hTcEiW2CbA X-IronPort-AV: E=Sophos;i="4.56,229,1280707200"; d="scan'208";a="173750771" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 18 Aug 2010 19:30:11 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o7IJUAAo015754 for ; Wed, 18 Aug 2010 19:30:10 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 21:30:09 +0200 Received: from [192.168.1.10] ([10.55.83.155]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 21:30:09 +0200 Message-Id: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Aug 2010 21:30:09 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Aug 2010 19:30:09.0528 (UTC) FILETIME=[C52A8780:01CB3F0B] Subject: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:29:36 -0000 Dear all, draft-dt-roll-p2p-rpl-02.txt has been presented several times and discussed on the mailing list. Could you let us know whether or not you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a ROLL Working Group document (feel free to justify) ? Thanks. JP. From Jerald.P.Martocci@jci.com Wed Aug 18 12:47:11 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E73C3A6A96; Wed, 18 Aug 2010 12:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.76 X-Spam-Level: X-Spam-Status: No, score=-2.76 tagged_above=-999 required=5 tests=[AWL=0.738, BAYES_00=-2.599, HTML_IMAGE_ONLY_20=1.546, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NClsQThrA5AJ; Wed, 18 Aug 2010 12:47:09 -0700 (PDT) Received: from exprod8og120.obsmtp.com (exprod8og120.obsmtp.com [64.18.3.40]) by core3.amsl.com (Postfix) with ESMTP id D929D3A6A98; Wed, 18 Aug 2010 12:47:05 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob120.postini.com ([64.18.7.12]) with SMTP ID DSNKTGw43MgEjWoVbzp1bCmgJ8+2Dpo4aVag@postini.com; Wed, 18 Aug 2010 12:47:41 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010081814493287-2126724 ; Wed, 18 Aug 2010 14:49:32 -0500 In-Reply-To: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> References: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> To: JP Vasseur MIME-Version: 1.0 X-KeepSent: FD26D9E1:C83D806A-86257783:006C3E1C; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 FP4 December 11, 2009 From: Jerald.P.Martocci@jci.com Message-ID: Date: Wed, 18 Aug 2010 14:47:42 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 08/18/2010 02:47:32 PM, Serialize complete at 08/18/2010 02:47:32 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/18/2010 02:49:32 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/18/2010 02:49:41 PM, Serialize complete at 08/18/2010 02:49:41 PM Content-Type: multipart/related; boundary="=_related 006CB86A86257783_=" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:47:11 -0000 This is a multipart message in MIME format. --=_related 006CB86A86257783_= Content-Type: text/html; charset="US-ASCII"
Yes.  I would like the P2P draft promoted to a WG document.  

BTW.  Mukul's 'Measurement' draft is really an excerpt from the original P2P draft.  It was extracted as a separate document at the request of reviewers.  I think it would be beneficial to reviewers if both documents were promoted to WG level simultaneously since they complement each other.

Jerry





From: JP Vasseur <jpv@cisco.com>
To: ROLL WG <roll@ietf.org>
Date: 08/18/2010 02:30 PM
Subject: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group        document ?




Dear all,

draft-dt-roll-p2p-rpl-02.txt has been presented several times and  
discussed on the mailing list. Could you let us know whether or not  
you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a  
ROLL Working Group document (feel free to justify) ?

Thanks.

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

--=_related 006CB86A86257783_= Content-Transfer-Encoding: base64 Content-Type: image/jpeg Content-ID: <_2_09C0A0B809C09E78006CB86A86257783> /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= --=_related 006CB86A86257783_=-- From d.sturek@att.net Wed Aug 18 12:48:49 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD61F3A69A5 for ; Wed, 18 Aug 2010 12:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.085 X-Spam-Level: * X-Spam-Status: No, score=1.085 tagged_above=-999 required=5 tests=[AWL=-0.700, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, MSGID_MULTIPLE_AT=1.449, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fOxttgqpB9PI for ; Wed, 18 Aug 2010 12:48:49 -0700 (PDT) Received: from smtp125.sbc.mail.sp1.yahoo.com (smtp125.sbc.mail.sp1.yahoo.com [69.147.65.184]) by core3.amsl.com (Postfix) with SMTP id F3E893A67AC for ; Wed, 18 Aug 2010 12:48:48 -0700 (PDT) Received: (qmail 62878 invoked from network); 18 Aug 2010 19:49:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1282160961; bh=9qUU4T+H7ABdqsKu9cD8i5DWRoBvI769I9hfR2l/tyE=; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Reply-To:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language; b=UKSpvi69wZZ4uJO+SnP/ZP2v4dbH083ZnKdabVi1NF4F3eUPzzqEy02SNRA4MtJA3CNiycqEbqo7pdkHwx4vDpWi/PxoPFFfNSIg4Afx3jFDcdOKLNDvPV0NIFNeIZk6LiLMVzYCe997aSWEBdPULmUE48/6pS0rX2Xsk68b5mU= Received: from Studio (d.sturek@174.78.56.227 with login) by smtp125.sbc.mail.sp1.yahoo.com with SMTP; 18 Aug 2010 12:49:21 -0700 PDT X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- X-YMail-OSG: UkbhG6AVM1m1G7.CABDSP6X.1TNTjqmc4OXGs1LeOaYm.tv 0UT720uHhGAsUSe14PUkA.LiY18kijGdrhmYauRbczU4BIMojZyoFKydmVIp 6P8bLYwgmNukRK0R_WBNdySiuZwH5KTcnsrZUyJGt00SIcCpQP328GZpn72s ZYrYryAYMdoQdB9u.U2ei.6487d8FN3LtIH52R0K86Ryn4plQMx9JLFyGRfh wp9tosGz0JIlzedARvqoA0Ot2fOwerGliR8l_8.fo9UxVCeCM6AwOes1CCfa Mwra9wOLWlcxPBYv2A.A- X-Yahoo-Newman-Property: ymail-3 From: "Don Sturek" To: "'JP Vasseur'" , "'ROLL WG'" References: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> In-Reply-To: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> Date: Wed, 18 Aug 2010 12:49:16 -0700 Message-ID: <010901cb3f0e$715132f0$53f398d0$@sturek@att.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs/C8kG7+nbAqXtT9WsGgN8/4TcCgAAp5Ng Content-Language: en-us Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: d.sturek@att.net List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:48:49 -0000 +1 I am in favor of the p2p draft being adopted by ROLL Don -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP Vasseur Sent: Wednesday, August 18, 2010 12:30 PM To: ROLL WG Subject: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? Dear all, draft-dt-roll-p2p-rpl-02.txt has been presented several times and discussed on the mailing list. Could you let us know whether or not you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a ROLL Working Group document (feel free to justify) ? Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Wed Aug 18 12:53:21 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BD5F3A6A89 for ; Wed, 18 Aug 2010 12:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.578 X-Spam-Level: X-Spam-Status: No, score=-6.578 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A5eLJMiUwdy1 for ; Wed, 18 Aug 2010 12:53:20 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id DC2793A6A9E for ; Wed, 18 Aug 2010 12:53:19 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.127]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Olohu-0005yJ-FB; Wed, 18 Aug 2010 12:53:55 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Wed, 18 Aug 2010 12:53:53 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <3E969E8A-EC99-429D-8738-F54A2756B790@cs.stanford.edu> References: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> To: Jerald.P.Martocci@jci.com X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 5fb79390a4aad79c01ba7e4883e5f1df Cc: ROLL WG Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:53:21 -0000 On Aug 18, 2010, at 12:47 PM, Jerald.P.Martocci@jci.com wrote: > BTW. Mukul's 'Measurement' draft is really an excerpt from the = original P2P draft. It was extracted as a separate document at the = request of reviewers. I think it would be beneficial to reviewers if = both documents were promoted to WG level simultaneously since they = complement each other.=20 Which draft is this? Can you send a URL? Phil= From pal@cs.stanford.edu Wed Aug 18 12:54:32 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5B7C3A6AA4 for ; Wed, 18 Aug 2010 12:54:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BflnuJf+-mCQ for ; Wed, 18 Aug 2010 12:54:31 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id CB1433A6AA7 for ; Wed, 18 Aug 2010 12:54:31 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.127]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Oloj5-00061F-4L; Wed, 18 Aug 2010 12:55:07 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> Date: Wed, 18 Aug 2010 12:55:06 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <31628B3F-219D-4E36-A800-0DAC1DE860E0@cs.stanford.edu> References: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-Scan-Signature: c6b7461a7773f457175e025605fe13fe Cc: ROLL WG Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 19:54:33 -0000 On Aug 18, 2010, at 12:30 PM, JP Vasseur wrote: > Dear all, >=20 > draft-dt-roll-p2p-rpl-02.txt has been presented several times and = discussed on the mailing list. Could you let us know whether or not you = think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a ROLL = Working Group document (feel free to justify) ? I support making the P2P draft a WG document.=20 Phil= From root@core3.amsl.com Wed Aug 18 13:00:01 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9384D3A6A59; Wed, 18 Aug 2010 13:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100818200001.9384D3A6A59@core3.amsl.com> Date: Wed, 18 Aug 2010 13:00:01 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-trickle-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 20:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : The Trickle Algorithm Author(s) : P. Levis, et al. Filename : draft-ietf-roll-trickle-03.txt Pages : 13 Date : 2010-08-18 The Trickle algorithm allows nodes in a lossy shared medium (e.g., low power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allows Trickle's communication rate to scale logarithmically with density. This document describes Trickle and considerations in its use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-trickle-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-trickle-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-18125112.I-D@ietf.org> --NextPart-- From jeonggil.ko@gmail.com Wed Aug 18 13:00:43 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 484E13A6A92 for ; Wed, 18 Aug 2010 13:00:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxXTwyISvEY0 for ; Wed, 18 Aug 2010 13:00:39 -0700 (PDT) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by core3.amsl.com (Postfix) with ESMTP id 2773C3A6AA3 for ; Wed, 18 Aug 2010 13:00:39 -0700 (PDT) Received: by qwc9 with SMTP id 9so952604qwc.31 for ; Wed, 18 Aug 2010 13:01:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:sender:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=FqG19Uce65JfkN+MwB8PdPESBXGwm9lUFwpxG1TWedM=; b=f52LeVJMRNxmlq8cD6zc5KaAIzN1XdbBTHrmoShNbssYnu5Y72lwykHjTwWRyF0qQN dEschvb644h9344d9eVKtuApufHh3iedtIic+YO35pSPULdEde2akQJZqC/jD8FFtDT6 lznNWyeRcx+0wE0fgYHQJ+VJSiaUkbdarkx3k= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=jm4vfSCbpBDXUONG4F5dxkq+Dcgcps+VV6A9rRpDILXKLO1aKBehcjkFGmF4m/1MSL Y9nNBEnkEYfoBv+5m72HM/Ix9RE0UKxEzJvAmsdDla5wdCoEof4Vdt5YO93Lt/alYUmJ BopUTzOcqalH8kJCiTSggTSa4/g2XJdjF39n0= Received: by 10.224.10.197 with SMTP id q5mr5805077qaq.129.1282161674064; Wed, 18 Aug 2010 13:01:14 -0700 (PDT) Received: from jgko.cs.jhu.edu (jgko.cs.jhu.edu [128.220.71.105]) by mx.google.com with ESMTPS id r1sm677668qcq.10.2010.08.18.13.01.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 18 Aug 2010 13:01:13 -0700 (PDT) Sender: "JeongGil (John) Ko" Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: "JeongGil Ko (John)" In-Reply-To: <31628B3F-219D-4E36-A800-0DAC1DE860E0@cs.stanford.edu> Date: Wed, 18 Aug 2010 16:01:11 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> <31628B3F-219D-4E36-A800-0DAC1DE860E0@cs.stanford.edu> To: Philip Levis X-Mailer: Apple Mail (2.1078) Cc: roll WG Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 20:00:43 -0000 +1=20 -John On Aug 18, 2010, at 3:55 PM, Philip Levis wrote: >=20 > On Aug 18, 2010, at 12:30 PM, JP Vasseur wrote: >=20 >> Dear all, >>=20 >> draft-dt-roll-p2p-rpl-02.txt has been presented several times and = discussed on the mailing list. Could you let us know whether or not you = think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a ROLL = Working Group document (feel free to justify) ? >=20 > I support making the P2P draft a WG document.=20 >=20 > Phil > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 ------ JeongGil Ko (John) Ph.D. Student Department of Computer Science Johns Hopkins University http://www.cs.jhu.edu/~jgko From prvs=839f6dbf6=mukul@uwm.edu Wed Aug 18 13:27:19 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0CE93A67FC; Wed, 18 Aug 2010 13:27:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.152 X-Spam-Level: X-Spam-Status: No, score=-3.152 tagged_above=-999 required=5 tests=[AWL=-0.553, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24XoraL16XcV; Wed, 18 Aug 2010 13:27:17 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 459493A67FB; Wed, 18 Aug 2010 13:27:17 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 18 Aug 2010 15:27:51 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 27A3E2B3F12; Wed, 18 Aug 2010 15:27:21 -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 GUPwc7IGM9Tc; Wed, 18 Aug 2010 15:27:20 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id AD27E2B3F16; Wed, 18 Aug 2010 15:27:19 -0500 (CDT) Date: Wed, 18 Aug 2010 15:27:49 -0500 (CDT) From: Mukul Goyal To: Jerald P Martocci Message-ID: <1829314419.698587.1282163269233.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_698585_872095612.1282163269231" X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 20:27:19 -0000 ------=_Part_698585_872095612.1282163269231 Content-Type: multipart/related; boundary="----=_Part_698586_735060109.1282163269231" ------=_Part_698586_735060109.1282163269231 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Jerry Sorry for the confusion. The measurement draft is not yet posted. I will do= so as soon as I can. Thanks Mukul ----- Original Message ----- From: "Jerald P Martocci" To: "JP Vasseur" Cc: "ROLL WG" , roll-bounces@ietf.org Sent: Wednesday, August 18, 2010 2:47:42 PM Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working=09G= roup=09document ? Yes. =C2=A0I would like the P2P draft promoted to a WG document. =C2=A0=20 BTW. =C2=A0Mukul's 'Measurement' draft is really an excerpt from the origin= al P2P draft. =C2=A0It was extracted as a separate document at the request = of reviewers. =C2=A0I think it would be beneficial to reviewers if both doc= uments were promoted to WG level simultaneously since they complement each = other.=20 Jerry=20 From: =09JP Vasseur =20 To: =09ROLL WG =20 Date: =0908/18/2010 02:30 PM=20 Subject: =09[Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Grou= p =C2=A0 =C2=A0 =C2=A0 =C2=A0document ?=20 Dear all,=20 draft-dt-roll-p2p-rpl-02.txt has been presented several times and =C2=A0=20 discussed on the mailing list. Could you let us know whether or not =C2=A0= =20 you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a =C2=A0= =20 ROLL Working Group document (feel free to justify) ?=20 Thanks.=20 JP.=20 _______________________________________________=20 Roll mailing list=20 Roll@ietf.org=20 https://www.ietf.org/mailman/listinfo/roll=20 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_Part_698586_735060109.1282163269231-- ------=_Part_698585_872095612.1282163269231-- From jpv@cisco.com Wed Aug 18 14:30:22 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B693A6A1D; Wed, 18 Aug 2010 14:30:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.419 X-Spam-Level: X-Spam-Status: No, score=-110.419 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iqc0YPj82zFc; Wed, 18 Aug 2010 14:30:21 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id ED7553A698D; Wed, 18 Aug 2010 14:30:20 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYGAHHua0yrR7Hu/2dsb2JhbACTPI0acaVKm3WFNwSJbYJs X-IronPort-AV: E=Sophos;i="4.56,229,1280707200"; d="scan'208,217";a="575500146" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 18 Aug 2010 21:30:56 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7ILUrGX008971; Wed, 18 Aug 2010 21:30:55 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 23:30:53 +0200 Received: from [192.168.1.10] ([10.55.83.155]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 18 Aug 2010 23:30:53 +0200 Message-Id: From: JP Vasseur To: Jerald.P.Martocci@jci.com In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-87-1064658401 Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 18 Aug 2010 23:30:52 +0200 References: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 18 Aug 2010 21:30:53.0137 (UTC) FILETIME=[A2B18C10:01CB3F1C] Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 21:30:22 -0000 --Apple-Mail-87-1064658401 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Hi Jerry, On Aug 18, 2010, at 9:47 PM, Jerald.P.Martocci@jci.com wrote: > > Yes. I would like the P2P draft promoted to a WG document. > Thanks for the feed-back. > BTW. Mukul's 'Measurement' draft Which document are you referring to ? Thanks. JP. > is really an excerpt from the original P2P draft. It was extracted > as a separate document at the request of reviewers. I think it > would be beneficial to reviewers if both documents were promoted to > WG level simultaneously since they complement each other. > > Jerry > > > > > > From: JP Vasseur > To: ROLL WG > Date: 08/18/2010 02:30 PM > Subject: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working > Group document ? > > > > > Dear all, > > draft-dt-roll-p2p-rpl-02.txt has been presented several times and > discussed on the mailing list. Could you let us know whether or not > you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a > ROLL Working Group document (feel free to justify) ? > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --Apple-Mail-87-1064658401 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hi Jerry,

On = Aug 18, 2010, at 9:47 PM, Jerald.P.Martocci@jci.com = wrote:


Yes.  I = would like the P2P draft promoted to a WG document.  
=

Thanks for the = feed-back.

BTW.  Mukul's 'Measurement' draft =

Which document are you referring = to = ?

Thanks.

JP.

<= blockquote type=3D"cite">is really = an excerpt from the original P2P draft.  It was extracted as a = separate document at the request of reviewers.  I think it would be = beneficial to reviewers if both documents were promoted to WG level = simultaneously since they complement each other.

Jerry


= <mime-attachment.jpeg>


From: JP Vasseur <jpv@cisco.com>
To: ROLL WG <roll@ietf.org>
Date: 08/18/2010 02:30 PM
Subject: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as = Working Group        document = ?



=
Dear all,

draft-dt-roll-p2p-rpl-02.txt = has been presented several times and  
discussed on the mailing = list. Could you let us know whether or not  
you think that = draft-dt-roll-p2p-rpl-02.txt should be adopted as a  
ROLL = Working Group document (feel free to justify) ?

Thanks.
=
JP.
_______________________________________________
Roll = mailing list
Roll@ietf.org
= https://www.ietf.org/mailman/listinfo/roll<= font size=3D"2">
=

= --Apple-Mail-87-1064658401-- From iesg-secretary@ietf.org Wed Aug 18 15:28:46 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E33E63A6A20; Wed, 18 Aug 2010 15:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.575 X-Spam-Level: X-Spam-Status: No, score=-102.575 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kxAxrAkmGDwc; Wed, 18 Aug 2010 15:28:46 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 107973A67FC; Wed, 18 Aug 2010 15:28:46 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no Message-ID: <20100818222846.13825.49680.idtracker@localhost> Date: Wed, 18 Aug 2010 15:28:46 -0700 Cc: roll@ietf.org Subject: [Roll] Last Call: (RPL: IPv6 Routing Protocol for Low power and Lossy Networks) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 22:28:47 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'RPL: IPv6 Routing Protocol for Low power and Lossy Networks' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-09-01. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/ The following IPR Declarations may be related to this I-D: /ipr/1270/ /ipr/1356/ /ipr/1366/ From prvs=840cb0eff=mukul@uwm.edu Thu Aug 19 00:01:49 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 135833A68AD for ; Thu, 19 Aug 2010 00:01:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.123 X-Spam-Level: X-Spam-Status: No, score=-3.123 tagged_above=-999 required=5 tests=[AWL=-0.524, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tAro9+cnE0O5 for ; Thu, 19 Aug 2010 00:01:48 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 2A6A53A67E5 for ; Thu, 19 Aug 2010 00:01:48 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 19 Aug 2010 02:02:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 857D62B3F0B for ; Thu, 19 Aug 2010 02:01:52 -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 hvHF4RJAbX6j for ; Thu, 19 Aug 2010 02:01:52 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 16DBB2B3F08 for ; Thu, 19 Aug 2010 02:01:52 -0500 (CDT) Date: Thu, 19 Aug 2010 02:02:22 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <600112991.710656.1282201342095.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <20100819065907.DFA863A68AD@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Fwd: New Version Notification for draft-goyal-roll-p2p-measurement-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:01:49 -0000 Hi all Here is the Measurement draft. I request WG status for this draft as well as the ability to measure the quality of an existing P2P route is a critical part of the overall P2P solution. Thanks Mukul ----- Forwarded Message ----- From: "IETF I-D Submission Tool" To: mukul@uwm.edu Cc: "Emmanuel Baccelli" Sent: Thursday, August 19, 2010 1:59:07 AM Subject: New Version Notification for draft-goyal-roll-p2p-measurement-00 A new version of I-D, draft-goyal-roll-p2p-measurement-00.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository. Filename: draft-goyal-roll-p2p-measurement Revision: 00 Title: A Mechanism to Measure the Quality of a Point-to-point Route in a Low Power and Lossy Network Creation_date: 2010-08-19 WG ID: Independent Submission Number_of_pages: 13 Abstract: This document specifies a mechanism that enables an RPL node to measure the quality of an existing route to/from another RPL node in a low power and lossy network, thereby allowing the node to decide if it wants to initiate the discovery of a more optimal route. The IETF Secretariat. From pal@cs.stanford.edu Thu Aug 19 00:16:00 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E69F3A689E for ; Thu, 19 Aug 2010 00:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.579 X-Spam-Level: X-Spam-Status: No, score=-6.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgMvEIfn22Jw for ; Thu, 19 Aug 2010 00:15:59 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id BC7FE3A6896 for ; Thu, 19 Aug 2010 00:15:59 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.127]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OlzMY-00038N-Pg; Thu, 19 Aug 2010 00:16:34 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <600112991.710656.1282201342095.JavaMail.root@mail02.pantherlink.uwm.edu> Date: Thu, 19 Aug 2010 00:16:34 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <600112991.710656.1282201342095.JavaMail.root@mail02.pantherlink.uwm.edu> To: Mukul Goyal X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3 Cc: roll Subject: Re: [Roll] Fwd: New Version Notification for draft-goyal-roll-p2p-measurement-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:16:00 -0000 On Aug 19, 2010, at 12:02 AM, Mukul Goyal wrote: > Hi all >=20 > Here is the Measurement draft. I request WG status for this draft as = well as the ability to measure the quality of an existing P2P route is a = critical part of the overall P2P solution. >=20 > Thanks > Mukul Mukul, I'm against adopting this as a WG document before there's been = significant discussion and refinement. Phil= From prvs=840cb0eff=mukul@uwm.edu Thu Aug 19 00:23:08 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E90DF3A6843 for ; Thu, 19 Aug 2010 00:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.097 X-Spam-Level: X-Spam-Status: No, score=-3.097 tagged_above=-999 required=5 tests=[AWL=-0.498, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XnG8kMqaMr3 for ; Thu, 19 Aug 2010 00:23:03 -0700 (PDT) Received: from ip1mta.uwm.edu (ip1mta.uwm.edu [129.89.7.18]) by core3.amsl.com (Postfix) with ESMTP id 86ED13A67B7 for ; Thu, 19 Aug 2010 00:23:02 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip1mta.uwm.edu with ESMTP; 19 Aug 2010 02:23:37 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 305CC2B3F05; Thu, 19 Aug 2010 02:23:07 -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 krTFm17oKTYb; Thu, 19 Aug 2010 02:23:06 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id BC51D2B3F03; Thu, 19 Aug 2010 02:23:06 -0500 (CDT) Date: Thu, 19 Aug 2010 02:23:36 -0500 (CDT) From: Mukul Goyal To: Philip Levis Message-ID: <1596178480.710704.1282202616729.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.92] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] Fwd: New Version Notification for draft-goyal-roll-p2p-measurement-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:23:08 -0000 Phil Looking forward to your comments. Thanks Mukul ----- Original Message ----- From: "Philip Levis" To: "Mukul Goyal" Cc: "roll" Sent: Thursday, August 19, 2010 2:16:34 AM Subject: Re: [Roll] Fwd: New Version Notification for draft-goyal-roll-p2p-measurement-00 On Aug 19, 2010, at 12:02 AM, Mukul Goyal wrote: > Hi all > > Here is the Measurement draft. I request WG status for this draft as well as the ability to measure the quality of an existing P2P route is a critical part of the overall P2P solution. > > Thanks > Mukul Mukul, I'm against adopting this as a WG document before there's been significant discussion and refinement. Phil From abr@sdesigns.dk Thu Aug 19 00:34:57 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA0E93A6843; Thu, 19 Aug 2010 00:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.091 X-Spam-Level: X-Spam-Status: No, score=0.091 tagged_above=-999 required=5 tests=[AWL=-0.089, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_IMAGE_ONLY_32=1.778, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEFMQb-TiX7G; Thu, 19 Aug 2010 00:34:32 -0700 (PDT) Received: from mail.zen-sys.com (mail.zen-sys.com [195.215.56.170]) by core3.amsl.com (Postfix) with ESMTP id 9C5B03A67E1; Thu, 19 Aug 2010 00:34:30 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; boundary="----_=_NextPart_001_01CB3F71.09FF5B7A"; type="multipart/alternative" Date: Thu, 19 Aug 2010 09:35:04 +0200 Message-ID: <6D9687E95918C04A8B30A7D6DA805A3E01CCD2D7@zensys17.zensys.local> In-Reply-To: X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document ? Thread-Index: Acs/Dj/RVdpKG7FPSlulXTGYRJdTwwAYsR2w References: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> From: "Anders Brandt" To: , "JP Vasseur" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:34:57 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3F71.09FF5B7A Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CB3F71.09FF5B7A" ------_=_NextPart_002_01CB3F71.09FF5B7A Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: Wednesday, August 18, 2010 21:48 To: JP Vasseur Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document ? =09 =09 Yes. I would like the P2P draft promoted to a WG document. =20 =09 BTW. Mukul's 'Measurement' draft is really an excerpt from the original P2P draft. It was extracted as a separate document at the request of reviewers. I think it would be beneficial to reviewers if both documents were promoted to WG level simultaneously since they complement each other.=20 =09 Jerry=20 =09 =09 =20 =09 =09 =09 From: JP Vasseur =20 To: ROLL WG =20 Date: 08/18/2010 02:30 PM=20 Subject: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? ________________________________ Dear all, =09 draft-dt-roll-p2p-rpl-02.txt has been presented several times and =20 discussed on the mailing list. Could you let us know whether or not =20 you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a =20 ROLL Working Group document (feel free to justify) ? =09 Thanks. =09 JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 =09 =09 =09 ------_=_NextPart_002_01CB3F71.09FF5B7A Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1

From: roll-bounces@ietf.org=20 [mailto:roll-bounces@ietf.org] On Behalf Of=20 Jerald.P.Martocci@jci.com
Sent: Wednesday, August 18, = 2010=20 21:48
To: JP Vasseur
Cc: ROLL WG;=20 roll-bounces@ietf.org
Subject: Re: [Roll] Adoption of=20 draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document = ?


Yes.  I would = like the P2P=20 draft promoted to a WG document.  

BTW.  Mukul's 'Measurement' draft is really an excerpt = from the=20 original P2P draft.  It was extracted as a separate document at = the=20 request of reviewers.  I think it would be beneficial to = reviewers if=20 both documents were promoted to WG level simultaneously since they = complement=20 each other.

Jerry=20





From:=20 JP Vasseur = <jpv@cisco.com>=20
To:=20 ROLL WG = <roll@ietf.org>=20
Date:=20 08/18/2010 02:30 PM=20
Subject:=20 [Roll] Adoption of=20 draft-dt-roll-p2p-rpl-02.txt as Working Group     =  =20  document ?




Dear = all,

draft-dt-roll-p2p-rpl-02.txt has=20 been presented several times and  
discussed on the mailing = list.=20 Could you let us know whether or not  
you think that=20 draft-dt-roll-p2p-rpl-02.txt should be adopted as a  
ROLL = Working=20 Group document (feel free to justify)=20 = ?

Thanks.

JP.
__________________________________________= _____
Roll=20 mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll


------_=_NextPart_002_01CB3F71.09FF5B7A-- ------_=_NextPart_001_01CB3F71.09FF5B7A Content-Type: image/jpeg; name="ATT226885.jpg" Content-Transfer-Encoding: base64 Content-ID: <614543407@19082010-0A89> Content-Description: ATT226885.jpg Content-Location: ATT226885.jpg /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= ------_=_NextPart_001_01CB3F71.09FF5B7A-- From emmanuel.baccelli@gmail.com Thu Aug 19 00:39:47 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70CD3A68F3 for ; Thu, 19 Aug 2010 00:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zciK56DLhRXo for ; Thu, 19 Aug 2010 00:39:46 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 26BC63A68F0 for ; Thu, 19 Aug 2010 00:39:45 -0700 (PDT) Received: by ewy22 with SMTP id 22so1077423ewy.31 for ; Thu, 19 Aug 2010 00:40:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:content-type; bh=FICSvbEY8vo+aBUplOiRNqiVNrtEN210RZaDZ/N4Spg=; b=APQiZdX9NGJ+HqVVLDfqWs8UQQfnZ06F7YlAh9FdyJhUp4nkKUoGZHpJdcycA8PkVi THF53+DbKkrAJaSBZtcuxk41LLXDLLejwupcmtHs4ueTPxNuD8JAnmE27hZQ1X1A4h6j N8uviDkSkOKq1JucijUnqT+p68n/px8r9Jk/c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:content-type; b=o6Xqza4LZLh/ZEH8c0YZ6SXZ+ly1sdMtqpkR2X7uo15p7r8E+5dx0a5rKwclcecXgd SlfaYbRyqSIcRdGUsmRnUkgGx8ZQcl98pSmnoZ7JB/oGO46abHS03CgXyJhgdo7STRMw 2A+8ETEQ0EbbUo22M2ftWr2l8MzALKkhe/VJk= Received: by 10.213.36.15 with SMTP id r15mr403463ebd.23.1282203620475; Thu, 19 Aug 2010 00:40:20 -0700 (PDT) MIME-Version: 1.0 Sender: emmanuel.baccelli@gmail.com Received: by 10.14.37.16 with HTTP; Thu, 19 Aug 2010 00:40:00 -0700 (PDT) In-Reply-To: <6D9687E95918C04A8B30A7D6DA805A3E01CCD2D7@zensys17.zensys.local> References: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD2D7@zensys17.zensys.local> From: Emmanuel Baccelli Date: Thu, 19 Aug 2010 09:40:00 +0200 X-Google-Sender-Auth: FGdnYuY-LbQkBqcD7hmqiwOZ5uk Message-ID: To: ROLL WG Content-Type: multipart/related; boundary=0015174be68c540700048e284b05 Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:39:47 -0000 --0015174be68c540700048e284b05 Content-Type: multipart/alternative; boundary=0015174be68c5406fb048e284b04 --0015174be68c5406fb048e284b04 Content-Type: text/plain; charset=ISO-8859-1 +1 too. On Thu, Aug 19, 2010 at 9:35 AM, Anders Brandt wrote: > +1 > > ------------------------------ > *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf Of > *Jerald.P.Martocci@jci.com > *Sent:* Wednesday, August 18, 2010 21:48 > *To:* JP Vasseur > *Cc:* ROLL WG; roll-bounces@ietf.org > *Subject:* Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as > WorkingGroup document ? > > > Yes. I would like the P2P draft promoted to a WG document. > > BTW. Mukul's 'Measurement' draft is really an excerpt from the original > P2P draft. It was extracted as a separate document at the request of > reviewers. I think it would be beneficial to reviewers if both documents > were promoted to WG level simultaneously since they complement each other. > > Jerry > > > > > > From: JP Vasseur To: ROLL WG Date: 08/18/2010 > 02:30 PM Subject: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as > Working Group document ? > ------------------------------ > > > > Dear all, > > draft-dt-roll-p2p-rpl-02.txt has been presented several times and > discussed on the mailing list. Could you let us know whether or not > you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a > ROLL Working Group document (feel free to justify) ? > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --0015174be68c5406fb048e284b04 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1 too.

On Thu, Aug 19, 2010 at 9:35 AM, = Anders Brandt <abr@= sdesigns.dk> wrote:
+1

From: roll-bounces@ietf.org=20 [mailto:roll-b= ounces@ietf.org] On Behalf Of=20 Jerald= .P.Martocci@jci.com
Sent: Wednesday, August 18, 2010=20 21:48
To: JP Vasseur
Cc: ROLL WG;=20 roll-bounces@i= etf.org
Subject: Re: [Roll] Adoption of=20 draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document ?


Yes. =A0I would like = the P2P=20 draft promoted to a WG document. =A0

BTW. =A0Mukul's 'Measurement' draft is really a= n excerpt from the=20 original P2P draft. =A0It was extracted as a separate document at the=20 request of reviewers. =A0I think it would be beneficial to reviewers if= =20 both documents were promoted to WG level simultaneously since they comple= ment=20 each other.

Jerry=20





From:=20 JP Vasseur <jpv@cisco.com>=20
To:= =20 ROLL WG <roll@ietf.org>=20
Date:=20 08/18/2010 02:30 PM=20
Subject:=20 [Roll] Adoption of=20 draft-dt-roll-p2p-rpl-02.txt as Working Group =A0 =A0 =A0=20 =A0document ?




Dear all,

draft-dt-roll-p2p-rpl-0= 2.txt has=20 been presented several times and =A0
discussed on the mailing list.=20 Could you let us know whether or not =A0
you think that=20 draft-dt-roll-p2p-rpl-02.txt should be adopted as a =A0
ROLL Working= =20 Group document (feel free to justify)=20 ?

Thanks.

JP.
__________________________________________= _____
Roll=20 mailing list
Roll@i= etf.org
https://www.ietf.org/mailman/= listinfo/roll



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


--0015174be68c5406fb048e284b04-- --0015174be68c540700048e284b05 Content-Type: image/jpeg; name="ATT226885.jpg" Content-Transfer-Encoding: base64 Content-ID: <614543407@19082010-0A89> X-Attachment-Id: d1802f0367abfe96_0.0.1 /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= --0015174be68c540700048e284b05-- From pthubert@cisco.com Thu Aug 19 01:19:14 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3290F3A67E1 for ; Thu, 19 Aug 2010 01:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.977 X-Spam-Level: X-Spam-Status: No, score=-9.977 tagged_above=-999 required=5 tests=[AWL=-0.379, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aCOZWV9g3988 for ; Thu, 19 Aug 2010 01:19:13 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 14E843A6821 for ; Thu, 19 Aug 2010 01:19:13 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: image001.jpg : 12611 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwMAEuGbEyrR7Hu/2dsb2JhbAB0UJxfgjZxoDabdIU3BIxe X-IronPort-AV: E=Sophos;i="4.56,232,1280707200"; d="jpg'145?scan'145,208,217,145";a="242324698" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 19 Aug 2010 08:19:47 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7J8JjWC024008; Thu, 19 Aug 2010 08:19:47 GMT Received: from xmb-ams-107.cisco.com ([144.254.74.82]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Aug 2010 10:19:42 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/related; type="multipart/alternative"; boundary="----_=_NextPart_001_01CB3F77.46190587" Date: Thu, 19 Aug 2010 10:19:39 +0200 Message-ID: <6A2A459175DABE4BB11DE2026AA50A5D02901134@XMB-AMS-107.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document ? Thread-Index: Acs/cc6xS9iiMCBrT+yPa5sbzzlNiAABW/wg References: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com><6D9687E95918C04A8B30A7D6DA805A3E01CCD2D7@zensys17.zensys.local> From: "Pascal Thubert (pthubert)" To: "Emmanuel Baccelli" , "ROLL WG" X-OriginalArrivalTime: 19 Aug 2010 08:19:42.0428 (UTC) FILETIME=[465BF1C0:01CB3F77] Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 08:19:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3F77.46190587 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01CB3F77.46190587" ------_=_NextPart_002_01CB3F77.46190587 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Same here, +1 =20 Pascal =20 From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Emmanuel Baccelli Sent: Thursday, August 19, 2010 9:40 AM To: ROLL WG Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document ? =20 +1 too. On Thu, Aug 19, 2010 at 9:35 AM, Anders Brandt wrote: +1 =20 ________________________________ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: Wednesday, August 18, 2010 21:48 To: JP Vasseur Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document ? =09 Yes. I would like the P2P draft promoted to a WG document. =20 =09 BTW. Mukul's 'Measurement' draft is really an excerpt from the original P2P draft. It was extracted as a separate document at the request of reviewers. I think it would be beneficial to reviewers if both documents were promoted to WG level simultaneously since they complement each other.=20 =09 Jerry=20 =09 =09 =20 =09 =09 From:=20 JP Vasseur =20 To:=20 ROLL WG =20 Date:=20 08/18/2010 02:30 PM=20 Subject:=20 [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? =20 ________________________________ =09 =09 =09 Dear all, =09 draft-dt-roll-p2p-rpl-02.txt has been presented several times and =20 discussed on the mailing list. Could you let us know whether or not =20 you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a =20 ROLL Working Group document (feel free to justify) ? =09 Thanks. =09 JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 =09 =09 _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_002_01CB3F77.46190587 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Same here, +1

 

Pascal

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Emmanuel Baccelli
Sent: Thursday, August 19, 2010 9:40 = AM
To: ROLL WG
Subject: Re: [Roll] Adoption of = draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document = ?

 

+1 too.

On Thu, Aug 19, 2010 at 9:35 AM, Anders Brandt <abr@sdesigns.dk> = wrote:

+1=

 

From:= = roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com
Sent: = Wednesday, August 18, 2010 21:48
To: JP Vasseur
Cc: = ROLL WG; roll-bounces@ietf.org
Subject: Re: = [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document = ?


Yes.  I = would like the P2P draft promoted to a WG document.   =

BTW. =  Mukul's 'Measurement' draft is really an excerpt from the original = P2P draft.  It was extracted as a separate document at the request = of reviewers.  I think it would be beneficial to reviewers if both = documents were promoted to WG level simultaneously since they complement = each other.

Jerry =




= From:

JP Vasseur = <jpv@cisco.com> =

= To:

ROLL WG = <roll@ietf.org> =

= Date:

08/18/2010 = 02:30 PM

= Subject:

[Roll] = Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group     =    document ?

 




Dear all,

draft-dt-roll-p2p-rpl-02.txt has been presented = several times and  
discussed on the mailing list. = Could you let us know whether or not  
you think that = draft-dt-roll-p2p-rpl-02.txt should be adopted as a =  
ROLL Working Group document (feel free to justify) = ?

Thanks.

JP.
_______________= ________________________________
Roll mailing = list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll


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

 

------_=_NextPart_002_01CB3F77.46190587-- ------_=_NextPart_001_01CB3F77.46190587 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: Content-Description: image001.jpg Content-Location: image001.jpg /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= ------_=_NextPart_001_01CB3F77.46190587-- From jpv@cisco.com Thu Aug 19 03:09:43 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C832E3A68F1 for ; Thu, 19 Aug 2010 03:09:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.42 X-Spam-Level: X-Spam-Status: No, score=-110.42 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4x2KPcPZqpno for ; Thu, 19 Aug 2010 03:09:40 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id ACD703A6879 for ; Thu, 19 Aug 2010 03:09:40 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiwHABOgbEyrR7Ht/2dsb2JhbACBRJZ7iBtxoCabe4U3BIlxgm2HVg X-IronPort-AV: E=Sophos;i="4.56,232,1280707200"; d="scan'208,217";a="174061594" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 19 Aug 2010 10:10:05 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7JA9sQY003348; Thu, 19 Aug 2010 10:10:04 GMT Received: from xfe-ams-101.cisco.com ([144.254.231.93]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Aug 2010 12:09:53 +0200 Received: from [192.168.1.10] ([10.61.90.160]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Aug 2010 12:09:53 +0200 Message-Id: From: JP Vasseur To: Philip Levis Content-Type: multipart/alternative; boundary=Apple-Mail-113--1037284496 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 12:09:53 +0200 References: X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Aug 2010 10:09:53.0180 (UTC) FILETIME=[AAACA5C0:01CB3F86] Cc: ROLL WG Subject: [Roll] Fwd: Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 10:09:43 -0000 --Apple-Mail-113--1037284496 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Thanks Phil for the changes agreed on the mailing and incorporated in =20= Trickle -03. There just a few things still to update before I can send the =20 publication request the IESG: 1) Can you add a terminology section (define Trickle communication =20 rate, ...) =3D> See Yoav/JP comments on the list 2) When listing a reference, add parenthesis. Example OLD: include RPL[I-D.ietf-roll-rpl] NEW: include RPL ([I-D.ietf-roll-rpl]) 3) Several comments below have not been incorporated (see JP>) Begin forwarded message: > From: JP Vasseur > Date: August 3, 2010 3:36:04 PM CEDT > To: ROLL WG > Subject: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 > > > > Begin forwarded message: > >> From: JP Vasseur >> Date: August 3, 2010 3:35:41 PM CEDT >> To: JP Vasseur >> Cc: ROLL WG >> Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 >> >> Please find below comments on draft-ietf-roll-trickle-02 (search =20 >> for JP>). >> Co-chair hat on (shepherding the document) >> >> Networking Working Group P. =20= >> Levis >> Internet-Draft Stanford =20 >> University >> Intended status: Informational T. =20 >> Clausen >> JP> So far good consensus to move to Std track. Let's wait until >> end of LC. >> Expires: January 7, 2011 LIX, Ecole =20 >> Polytechnique >> =20 >> J. Hui >> Arch Rock =20 >> Corporation >> O. =20 >> Gnawali >> Stanford =20 >> University >> =20= >> J. Ko >> Johns Hopkins =20 >> University >> July 6, =20= >> 2010 >> >> >> The Trickle Algorithm >> draft-ietf-roll-trickle-02 >> >> Abstract >> >> The Trickle algorithm allows wireless nodes to exchange =20 >> information >> >> JP> Not restricted to wireless. Even if we do not use some =20 >> features, dynamic >> timer adjustments are still useful in PLC/wired environments. >> in a highly robust, energy efficient, simple, and scalable manner. >> Dynamically adjusting transmission windows allows Trickle to =20 >> spread >> new information on the scale of link-layer transmission times =20 >> while >> sending only a few messages per hour >> JP> I would suggest to be more generic (not specify "hour", "mn", =20 >> since >> that all depends on the parameter settings) JP> Comment above >> when information does not >> change. A simple suppression mechanism and transmission point >> selection allows Trickle's communication rate to scale >> logarithmically with density. This document describes Trickle >> JP> s/trickle/the trickle algorithm JP> Comment above >> and >> considerations in its use. >> >> Status of this Memo >> >> This Internet-Draft is submitted to IETF in full conformance =20 >> with the >> provisions of BCP 78 and BCP 79. >> >> Internet-Drafts are working documents of the Internet Engineering >> Task Force (IETF), its areas, and its working groups. Note that >> other groups may also distribute working documents as Internet- >> Drafts. >> >> Internet-Drafts are draft documents valid for a maximum of six =20 >> months >> and may be updated, replaced, or obsoleted by other documents at =20= >> any >> time. It is inappropriate to use Internet-Drafts as reference >> material or to cite them other than as "work in progress." >> >> The list of current Internet-Drafts can be accessed at >> http://www.ietf.org/ietf/1id-abstracts.txt. >> >> The list of Internet-Draft Shadow Directories can be accessed at >> http://www.ietf.org/shadow.html. >> >> >> >> Levis, et al. Expires January 7, 2011 =20 >> [Page 1] >> =0C >> Internet-Draft draft-ietf-roll-trickle-02 July =20= >> 2010 >> >> >> This Internet-Draft will expire on January 7, 2011. >> >> Copyright Notice >> >> Copyright (c) 2010 IETF Trust and the persons identified as the >> document authors. All rights reserved. >> >> This document is subject to BCP 78 and the IETF Trust's Legal >> Provisions Relating to IETF Documents >> (http://trustee.ietf.org/license-info) in effect on the date of >> publication of this document. Please review these documents >> carefully, as they describe your rights and restrictions with =20 >> respect >> to this document. Code Components extracted from this document =20= >> must >> include Simplified BSD License text as described in Section 4.e of >> the Trust Legal Provisions and are provided without warranty as >> described in the BSD License. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Levis, et al. Expires January 7, 2011 =20 >> [Page 2] >> =0C >> Internet-Draft draft-ietf-roll-trickle-02 July =20= >> 2010 >> >> >> Table of Contents >> >> 1. =20 >> Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 2. =20 >> Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 >> 3. Trickle Algorithm =20 >> Overview . . . . . . . . . . . . . . . . . . 3 >> 4. Trickle =20 >> Algorithm . . . . . . . . . . . . . . . . . . . . . . . 4 >> 4.1. Parameters and =20 >> Variables . . . . . . . . . . . . . . . . . 4 >> 4.2. Algorithm =20 >> Description . . . . . . . . . . . . . . . . . . . 5 >> 5. Using =20 >> Trickle . . . . . . . . . . . . . . . . . . . . . . . . . 5 >> 6. Operational =20 >> Considerations . . . . . . . . . . . . . . . . . . 6 >> 6.1. Mismatched redundancy =20 >> constants . . . . . . . . . . . . . . 6 >> 6.2. Mismatched =20 >> Imin . . . . . . . . . . . . . . . . . . . . . . 6 >> 6.3. Mismatched =20 >> Imax . . . . . . . . . . . . . . . . . . . . . . 7 >> 6.4. Mismatched =20 >> definitions . . . . . . . . . . . . . . . . . . 7 >> 6.5. Specifying the constant =20 >> k . . . . . . . . . . . . . . . . . 7 >> 6.6. Relationship between k and =20 >> Imin . . . . . . . . . . . . . . 7 >> 6.7. Tweaks and improvements to =20 >> Trickle . . . . . . . . . . . . 8 >> 7. =20 >> Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 >> 8. IANA =20 >> Considerations . . . . . . . . . . . . . . . . . . . . . . 8 >> 9. Security =20 >> Considerations . . . . . . . . . . . . . . . . . . . . 8 >> 10. =20 >> References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 >> 10.1. Normative =20 >> References . . . . . . . . . . . . . . . . . . . 8 >> 10.2. Informative =20 >> References . . . . . . . . . . . . . . . . . . 9 >> Authors' =20 >> Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> Levis, et al. Expires January 7, 2011 =20 >> [Page 3] >> =0C >> Internet-Draft draft-ietf-roll-trickle-02 July =20= >> 2010 >> >> >> 1. Introduction >> >> The Trickle algorithm is designed for wireless networks. >> JP> please use the LLN terminology and point to [I-D-ietf.roll-=20 >> terminology] ID. >> It >> establishes a density-aware local broadcast with an underlying >> consistency model that guides when a node communicates. When a >> node's data does not agree >> JP> you may want to clarify the term "agree" JP> Comment above (need to define the term "agree") >> with its neighbors, it communicates >> quickly to resolve the inconsistency. >> JP> Please define "inconsistency" (an example should suffice) JP> The first you use the term "inconsistency" can you point to =20 Section 6.8 >> When nodes agree, they slow >> their communication rate exponentially, such that nodes send at =20= >> most >> a few packets per hour. >> JP> See comments on "hour" >> JP> Same here This primitive allows Trickle to scale to thousand-fold variations =20= in network density, quickly propagate updates, distribute transmission load evenly, be robust to transient disconnections, handle network repopulations, and impose a very low maintenance overhead: common uses require on the order of a few packets per hour yet can respond in milliseconds. Avoid using a unit value (hour) unless it is clear that this is given =20= as an example. 4) Checking references for intended status: Proposed Standard =20 = --------------------------------------------------------------------------= -- (See RFCs 3967 and 4897 for information about using normative =20 references to lower-maturity documents in RFCs) =3D=3D Outdated reference: A later version (-11) exists of draft-ietf-roll-rpl-10 Thanks. JP. --Apple-Mail-113--1037284496 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Thanks Phil for the changes = agreed on the mailing and incorporated in Trickle = -03.

There just a few things still to update before I = can send the publication request the IESG:
1) Can you add a = terminology section (define Trickle communication rate, ...) =3D> See = Yoav/JP comments on the list
2) When listing a reference, add = parenthesis.

Example

OLD= : include = RPL[I-D.ietf-roll-rpl]

NEW: include RPL ([I-D.ietf-roll-rpl])

3) Several comments below have not = been incorporated (see JP>)

Begin = forwarded message:

From: = JP Vasseur <jpv@cisco.com>
Date: = August 3, 2010 3:36:04 PM CEDT
To: ROLL WG = <roll@ietf.org>
Subject: = [Roll] Fwd:  = WG Last Call on draft-ietf-roll-trickle-02



Begin = forwarded message:

From: = JP Vasseur <jpv@cisco.com>
Date: = August 3, 2010 3:35:41 PM CEDT
To: JP = Vasseur <jpv@cisco.com>
Cc: ROLL WG = <roll@ietf.org>
Subject: = Re: [Roll] WG Last Call on = draft-ietf-roll-trickle-02

Please find below comments = on draft-ietf-roll-trickle-02 (search for JP>).
Co-chair hat on = (shepherding the document)

Networking =
Working Group                                        P. Levis
Internet-Draft                                       Stanford University
Intended status: Informational                                T. =
Clausen
JP> So far good =
consensus to move to Std track. Let's wait until
end of LC.
Expires: =
January 7, 2011                        LIX, Ecole Polytechnique
                                                                  J. Hui
                                                   Arch Rock Corporation
                                                              O. Gnawali
                                                     Stanford University
                                                                   J. Ko
                                                Johns Hopkins University
                                                            July 6, 2010


                         The Trickle Algorithm
                       draft-ietf-roll-trickle-02

Abstract

   The Trickle algorithm allows wireless nodes to exchange information

JP> Not =
restricted to wireless. Even if we do not use some features, =
dynamic
timer =
adjustments are still useful in PLC/wired =
environments.
   in a highly robust, energy =
efficient, simple, and scalable manner.
   Dynamically adjusting transmission windows allows Trickle to spread
   new information on the scale of link-layer transmission times while
   sending only a few messages per hour 
JP> I would suggest to =
be more generic (not specify "hour", "mn", since 
that all depends on the parameter =
settings)
<= /div>

JP> Comment = above
when =
information does not
   change.  A simple suppression mechanism and transmission point
   selection allows Trickle's communication rate to scale
   logarithmically with density.  This document describes =
Trickle 
JP> s/trickle/the trickle =
algorithm
<= /div>
JP> Comment = above
and
   considerations in its use.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ie=
tf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.



Levis, et al.            Expires January 7, 2011                [Page 1]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


   This Internet-Draft will expire on January 7, 2011.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/lice=
nse-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the BSD License.



































Levis, et al.            Expires January 7, 2011                [Page 2]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Trickle Algorithm Overview  . . . . . . . . . . . . . . . . . . 3
   4.  Trickle Algorithm . . . . . . . . . . . . . . . . . . . . . . . 4
     4.1.  Parameters and Variables  . . . . . . . . . . . . . . . . . 4
     4.2.  Algorithm Description . . . . . . . . . . . . . . . . . . . 5
   5.  Using Trickle . . . . . . . . . . . . . . . . . . . . . . . . . 5
   6.  Operational Considerations  . . . . . . . . . . . . . . . . . . 6
     6.1.  Mismatched redundancy constants . . . . . . . . . . . . . . 6
     6.2.  Mismatched Imin . . . . . . . . . . . . . . . . . . . . . . 6
     6.3.  Mismatched Imax . . . . . . . . . . . . . . . . . . . . . . 7
     6.4.  Mismatched definitions  . . . . . . . . . . . . . . . . . . 7
     6.5.  Specifying the constant k . . . . . . . . . . . . . . . . . 7
     6.6.  Relationship between k and Imin . . . . . . . . . . . . . . 7
     6.7.  Tweaks and improvements to Trickle  . . . . . . . . . . . . 8
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8
   9.  Security Considerations . . . . . . . . . . . . . . . . . . . . 8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . . 8
     10.1. Normative References  . . . . . . . . . . . . . . . . . . . 8
     10.2. Informative References  . . . . . . . . . . . . . . . . . . 9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . . . 9



























Levis, et al.            Expires January 7, 2011                [Page 3]
=0C
Internet-Draft         draft-ietf-roll-trickle-02              July 2010


1.  Introduction

   The Trickle algorithm is designed for wireless networks. =
 
JP> please =
use the LLN terminology and point to [I-D-ietf.roll-terminology] =
ID.
It
   establishes a density-aware local broadcast with an underlying
   consistency model that guides when a node communicates.  When a
   node's data does not agree 
JP> you may want to clarify the =
term =
"agree"

JP> Comment above (need to = define the term "agree")
with its =
neighbors, it communicates
   quickly to resolve the inconsistency.  
JP> Please define =
"inconsistency" (an example should =
suffice)

JP> = The first you use the term "inconsistency" can you point to Section = 6.8

When nodes =
agree, they slow
   their communication rate exponentially, such that nodes send at most
   a few packets per hour.  
JP> See comments on =
"hour"

=
JP> Same = here 

  =
 This primitive allows Trickle to scale to thousand-fold variations in
   network density, quickly propagate updates, distribute transmission
   load evenly, be robust to transient disconnections, handle network
   repopulations, and impose a very low maintenance overhead: common
   uses require on the order of a few packets per hour yet can respond
   in milliseconds.
Avoid using a unit value (hour) unless it is clear that this =
is given as an example.
4) Checking references for intended status: =
Proposed Standard
  =
--------------------------------------------------------------------------=
--

     (See RFCs 3967 and 4897 for information about using normative =
references
     to lower-maturity documents in RFCs)

  =3D=3D Outdated reference: A later version (-11) exists of
     draft-ietf-roll-rpl-10
=
Thanks.

JP.

= --Apple-Mail-113--1037284496-- From yoav@yitran.com Thu Aug 19 03:19:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F93D3A6822 for ; Thu, 19 Aug 2010 03:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.286 X-Spam-Level: X-Spam-Status: No, score=-6.286 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ELUlvCgJ8ew2 for ; Thu, 19 Aug 2010 03:19:23 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id B478E3A6872 for ; Thu, 19 Aug 2010 03:19:22 -0700 (PDT) Received: from source ([209.85.212.43]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKTG0FTdYfaHX/tv9p7pbIs8/4dNnrtSVX@postini.com; Thu, 19 Aug 2010 03:19:58 PDT Received: by vws8 with SMTP id 8so2062686vws.2 for ; Thu, 19 Aug 2010 03:19:57 -0700 (PDT) Received: by 10.220.161.201 with SMTP id s9mr5822268vcx.277.1282213197066; Thu, 19 Aug 2010 03:19:57 -0700 (PDT) From: Yoav Ben-Yehezkel References: In-Reply-To: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs/hsE3u0NbLfnzQDaYhaygRzGreAAASr+Q Date: Thu, 19 Aug 2010 13:19:50 +0300 Message-ID: To: JP Vasseur , Philip Levis Content-Type: multipart/alternative; boundary=0016e64758662330a8048e2a8663 Cc: ROLL WG Subject: Re: [Roll] Fwd: Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 10:19:25 -0000 --0016e64758662330a8048e2a8663 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Also, see typo at bottom of page 4 =96 blaances should be balances Thanks, Yoav *From:* roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] *On Behalf Of = *JP Vasseur *Sent:* Thursday, August 19, 2010 1:10 PM *To:* Philip Levis *Cc:* ROLL WG *Subject:* [Roll] Fwd: Fwd: WG Last Call on draft-ietf-roll-trickle-02 Thanks Phil for the changes agreed on the mailing and incorporated in Trickle -03. There just a few things still to update before I can send the publication request the IESG: 1) Can you add a terminology section (define Trickle communication rate, ...) =3D> See Yoav/JP comments on the list 2) When listing a reference, add parenthesis. Example OLD: include RPL[I-D.ietf-roll-rpl] NEW: include RPL ([I-D.ietf-roll-rpl]) 3) Several comments below have not been incorporated (see JP>) Begin forwarded message: *From: *JP Vasseur *Date: *August 3, 2010 3:36:04 PM CEDT *To: *ROLL WG *Subject: **[Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02* Begin forwarded message: *From: *JP Vasseur *Date: *August 3, 2010 3:35:41 PM CEDT *To: *JP Vasseur *Cc: *ROLL WG *Subject: **Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02* Please find below comments on draft-ietf-roll-trickle-02 (search for *JP>*)= . Co-chair hat on (shepherding the document) Networking Working Group P. Levis Internet-Draft Stanford University Intended status: Informational T. Clausen JP> So far good consensus to move to Std track. Let's wait until end of LC. Expires: January 7, 2011 LIX, Ecole Polytechnique J. Hui Arch Rock Corporation O. Gnawali Stanford University J. Ko Johns Hopkins University July 6, 2010 The Trickle Algorithm draft-ietf-roll-trickle-02 Abstract The Trickle algorithm allows wireless nodes to exchange information JP> Not restricted to wireless. Even if we do not use some features, dynami= c timer adjustments are still useful in PLC/wired environments. in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour JP> I would suggest to be more generic (not specify "hour", "mn", since that all depends on the parameter settings) JP> Comment above when information does not change. A simple suppression mechanism and transmission point selection allows Trickle's communication rate to scale logarithmically with density. This document describes Trickle JP> s/trickle/the trickle algorithm JP> Comment above and considerations in its use. Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Levis, et al. Expires January 7, 2011 [Page 1] Internet-Draft draft-ietf-roll-trickle-02 July 2010 This Internet-Draft will expire on January 7, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Levis, et al. Expires January 7, 2011 [Page 2] Internet-Draft draft-ietf-roll-trickle-02 July 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Trickle Algorithm Overview . . . . . . . . . . . . . . . . . . 3 4. Trickle Algorithm . . . . . . . . . . . . . . . . . . . . . . . 4 4.1. Parameters and Variables . . . . . . . . . . . . . . . . . 4 4.2. Algorithm Description . . . . . . . . . . . . . . . . . . . 5 5. Using Trickle . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Operational Considerations . . . . . . . . . . . . . . . . . . 6 6.1. Mismatched redundancy constants . . . . . . . . . . . . . . 6 6.2. Mismatched Imin . . . . . . . . . . . . . . . . . . . . . . 6 6.3. Mismatched Imax . . . . . . . . . . . . . . . . . . . . . . 7 6.4. Mismatched definitions . . . . . . . . . . . . . . . . . . 7 6.5. Specifying the constant k . . . . . . . . . . . . . . . . . 7 6.6. Relationship between k and Imin . . . . . . . . . . . . . . 7 6.7. Tweaks and improvements to Trickle . . . . . . . . . . . . 8 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Levis, et al. Expires January 7, 2011 [Page 3] Internet-Draft draft-ietf-roll-trickle-02 July 2010 1. Introduction The Trickle algorithm is designed for wireless networks. JP> please use the LLN terminology and point to [I-D-ietf.roll-terminology]= ID. It establishes a density-aware local broadcast with an underlying consistency model that guides when a node communicates. When a node's data does not agree JP> you may want to clarify the term "agree" JP> Comment above (need to define the term "agree") with its neighbors, it communicates quickly to resolve the inconsistency. JP> Please define "inconsistency" (an example should suffice) JP> The first you use the term "inconsistency" can you point to Section 6.8 When nodes agree, they slow their communication rate exponentially, such that nodes send at most a few packets per hour. JP> See comments on "hour" JP> Same here This primitive allows Trickle to scale to thousand-fold variations in network density, quickly propagate updates, distribute transmission load evenly, be robust to transient disconnections, handle network repopulations, and impose a very low maintenance overhead: common uses require on the order of a few packets per hour yet can respond in milliseconds. Avoid using a unit value (hour) unless it is clear that this is given as an example. 4) Checking references for intended status: Proposed Standard -------------------------------------------------------------------------= --- (See RFCs 3967 and 4897 for information about using normative referenc= es to lower-maturity documents in RFCs) =3D=3D Outdated reference: A later version (-11) exists of draft-ietf-roll-rpl-10 Thanks. JP. --0016e64758662330a8048e2a8663 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

Also, see typo at bottom of page 4 =96 blaances should be balances

=A0

Thanks,

Yoav

=A0

=A0

From: roll-bounces@ietf.org [mailto:= roll-bounces@ietf.org] On B= ehalf Of JP Vasseur
Sent: Thursday, August 19, 2010 1:10 PM
To: Philip Levis
Cc: ROLL WG
Subject: [Roll] Fwd: Fwd: WG Last Call on draft-ietf-roll-trickle-02=

=A0

Thanks Phil for the changes agreed on the mailing an= d incorporated in Trickle -03.

=A0

There just a few things still to update before I can= send the publication request the IESG:

1) Can you add a terminology section (define Trickle communication rate, ...) =3D> See Yoav/JP comments on the list

2) When listing a reference, add parenthesis.

=A0

Example

=A0

OLD:=A0include RPL[I-D.ietf-roll-rpl]

=

NEW:=A0include RPL ([I-D.ietf-roll-rpl])<= /span>

=

3) Several comments below have not been incorporated= (see JP>)

=A0

Begin forwarded message:



From: JP Vasseur <jpv@cisco.com>

Date: August 3, 2010 3:36:04 PM CEDT

To: ROLL WG <roll@ietf.org>

Subject: [Roll] Fwd:=A0 WG Last Call on draft-ietf-roll-trickle-02

=A0

=A0

=A0

Begin forwarded message:



From: JP Vasseur <jpv@cisco.com>

Date: August 3, 2010 3:35:41 PM CEDT

To: JP Vasseur <jpv@cisco.com>

Cc: ROLL WG <roll@ietf.org>

Subject: Re: [Roll] WG Last Call on dr= aft-ietf-roll-trickle-02

=A0

Please find below comments on=A0draft-ietf-roll-trickle-02 (search for JP>).

Co-chair hat on (shepherding the document)

=A0

Networking W=
orking Group=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 P. Levis
I=
nternet-Draft=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Stanford University<=
/pre>

Intended status: Informational=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 T. Clausen
JP> So far good consensus to move to Std track. Let's=
 wait until
end of LC.
Expires: January 7, 2011=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 LIX, Ecole Polytechnique
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 J. Hui
=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0Arch R=
ock Corporation
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 O. Gnawali
=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Stanf=
ord University
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=
=A0J. Ko
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Jo=
hns Hopkins University
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 July 6, 2010
=A0
=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 The Trickle Algorithm


=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 dra=
ft-ietf-roll-trickle-02
=A0
Abstract
=A0
=A0=A0 The Trickle algorithm allows wireless nodes to exchange inform=
ation
=A0
JP> Not restricted to wireless. Even if we do not use som=
e features, dynamic
timer adjustments are still useful in PLC/wired environments=
.
=A0=A0 in a highly robust, energy efficient, simple, and scalable manne=
r.


=A0=A0 Dynamically adjusting transmission windows allows Trickle to sp=
read
=A0=A0 new information on the scale of link-layer transmissi=
on times while
=A0=A0 sending only a few messages per hour=A0
JP> I would suggest to be more generic (not specify "=
;hour", "mn", since=A0
that all depends on the parameter settings)

=A0

JP> Comment above

when information does not
=A0=A0 change.=A0 A simple su=
ppression mechanism and transmission point
=A0=A0 selection allow=
s Trickle's communication rate to scale
=A0 =A0logarithmicall=
y with density.=A0 This document describes Trickle=A0
JP> s/trickle/the trickle algorithm

JP> Comment above

and
=A0=A0 considerations in its use.
=A0
Status of this Memo
=A0
=A0=A0 This Internet-Dra=
ft is submitted to IETF in full conformance with the
=A0=A0 provi=
sions of BCP 78 and BCP 79.


=A0
=A0=A0 Internet-Drafts are working documents of the Inte=
rnet Engineering
=A0=A0 Task Force (IETF), its areas, and its wor=
king groups.=A0 Note that
=A0=A0 other groups may also distribute=
 working documents as Internet-


=A0=A0 Drafts.
=A0
=A0=A0 Internet-Drafts are draf=
t documents valid for a maximum of six months
=A0=A0 and may be u=
pdated, replaced, or obsoleted by other documents at any
=A0=A0 t=
ime.=A0 It is inappropriate to use Internet-Drafts as reference


=A0=A0 material or to cite them other than as "work in progress.&=
quot;
=A0
=A0=A0 The list of current Internet-Drafts ca=
n be accessed at
=A0=A0 http://www.ietf.org/ietf/1id-abstracts.txt.


=A0
=A0=A0 The list of Internet-Draft Shadow Directories can=
 be accessed at
=A0=A0 http://www.ietf.org/shadow.html.
=A0
=A0
=A0
Levis, et al.=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Expires January 7, 2011=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 [Page 1]
=A0
Internet-Draft=A0=A0=A0=A0=A0=A0=A0=A0 draft-ietf-roll-trickle-02=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 July 2010
=A0
=A0
<= pre>=A0=A0 This Internet-Draft will expire on January 7, 2011. 
=A0
Copyright Notice
=A0
=A0=A0 Copyrigh=
t (c) 2010 IETF Trust and the persons identified as the
=A0=A0 do=
cument authors.=A0 All rights reserved.
=A0
=A0=A0 This=
 document is subject to BCP 78 and the IETF Trust's Legal
=A0=A0 Provisions Relating to IETF Documents
=A0=A0 (http://trustee.ietf.org/license-i=
nfo) in effect on the date of
=A0=A0 publication of this docu=
ment.=A0 Please review these documents
=A0=A0 carefully, as they describe your rights and restrictions with r=
espect
=A0=A0 to this document.=A0 Code Components extracted from=
 this document must
=A0=A0 include Simplified BSD License text as=
 described in Section 4.e of
=A0=A0 the Trust Legal Provisions and are provided without warranty as=

=A0=A0 described in the BSD License.
=A0
=A0=

=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
<=
pre>=A0
=A0
=A0
=A0
=A0
=
=A0
=A0
=A0


=A0
=A0
=A0
=A0
=A0
=
=A0
=A0
=A0
Levis, et al.=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 Expires January 7, 2011=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 [Page 2]
=A0
Internet-Draft=A0=A0=A0=A0=A0=A0=
=A0=A0 draft-ietf-roll-trickle-02=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Ju=
ly 2010


=A0
=A0
Table of Contents
=A0
=
=A0=A0 1.=A0 Introduction=A0 . . . . . . . . . . . . . . . . . . . . . . . =
. . 3
=A0=A0 2.=A0 Terminology . . . . . . . . . . . . . . . . . =
. . . . . . . . . 3


=A0=A0 3.=A0 Trickle Algorithm Overview=A0 . . . . . . . . . . . . . .=
 . . . . 3
=A0=A0 4.=A0 Trickle Algorithm . . . . . . . . . . . .=
 . . . . . . . . . . . 4
=A0=A0=A0=A0 4.1.=A0 Parameters and Vari=
ables=A0 . . . . . . . . . . . . . . . . . 4


=A0=A0=A0=A0 4.2.=A0 Algorithm Description . . . . . . . . . . . . . .=
 . . . . . 5
=A0=A0 5.=A0 Using Trickle . . . . . . . . . . . . .=
 . . . . . . . . . . . . 5
=A0=A0 6.=A0 Operational Consideration=
s=A0 . . . . . . . . . . . . . . . . . . 6


=A0=A0=A0=A0 6.1.=A0 Mismatched redundancy constants . . . . . . . . .=
 . . . . . 6
=A0=A0=A0=A0 6.2.=A0 Mismatched Imin . . . . . . . .=
 . . . . . . . . . . . . . . 6
=A0=A0=A0=A0 6.3.=A0 Mismatched Im=
ax . . . . . . . . . . . . . . . . . . . . . . 7


=A0=A0=A0=A0 6.4.=A0 Mismatched definitions=A0 . . . . . . . . . . . .=
 . . . . . . 7
=A0=A0=A0=A0 6.5.=A0 Specifying the constant k . .=
 . . . . . . . . . . . . . . . 7
=A0=A0=A0=A0 6.6.=A0 Relationshi=
p between k and Imin . . . . . . . . . . . . . . 7


=A0=A0=A0=A0 6.7.=A0 Tweaks and improvements to Trickle=A0 . . . . . .=
 . . . . . . 8
=A0=A0 7.=A0 Acknowledgements=A0 . . . . . . . . .=
 . . . . . . . . . . . . . . 8
=A0=A0 8.=A0 IANA Considerations .=
 . . . . . . . . . . . . . . . . . . . . . 8


=A0=A0 9.=A0 Security Considerations . . . . . . . . . . . . . . . . .=
 . . . 8
=A0=A0 10. References=A0 . . . . . . . . . . . . . . . .=
 . . . . . . . . . . 8
=A0=A0=A0=A0 10.1. Normative References=A0=
 . . . . . . . . . . . . . . . . . . . 8


=A0=A0=A0=A0 10.2. Informative References=A0 . . . . . . . . . . . . .=
 . . . . . 9
=A0=A0 Authors' Addresses=A0 . . . . . . . . . .=
 . . . . . . . . . . . . . . 9
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
=A0
<=
pre>=A0
=A0
=A0
=A0
=A0
=
=A0
=A0
=A0


=A0
=A0
=A0
=A0
Levis, et al.=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Expires January 7, 2011=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 [Page 3]
=A0
Internet-Draft=
=A0=A0=A0=A0=A0=A0=A0=A0 draft-ietf-roll-trickle-02=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 July 2010


=A0
=A0
1.=A0 Introduction
=A0
=A0=A0 The Trickle algorithm is designed for wireless networks. =A0
<=
pre style=3D"word-wrap: break-word;white-space:pre-wrap">JP> please use the LLN terminology and point to [I-D-ietf=
.roll-terminology] ID.
It
=A0=A0 establishes a density-aware lo=
cal broadcast with an underlying
=A0=A0 consistency model that guides when a node communicates.=A0 When=
 a
=A0=A0 node's data does not agree=A0
=
JP> you may want to clarify the term "agree"

=A0

JP> Comment above (need to define the term "agree")

with its neighbors, it communicates
=A0=A0 quickly to r=
esolve the inconsistency. =A0
JP> Please define "inconsistency" (an example s=
hould suffice)

=A0

JP> The first you use the term "inconsistency" can you point to Secti= on 6.8



When nodes agree, they slow
=A0=A0 their communication =
rate exponentially, such that nodes send at most
=A0=A0 a few pac=
kets per hour. =A0
JP> See comments on "hour"
<= pre style=3D"word-wrap: break-word;white-space:pre-wrap">

JP> Same here=A0

=A0

=A0=A0 This primitive allows Trickle to scale to thousand-=
fold variations in
=A0=A0 netw=
ork density, quickly propagate updates, distribute transmission

=A0=A0 load evenly, be robust to transient=
 disconnections, handle network
=A0=A0 repopulations, and impose a very low maintenance overhead: common<=
/span>


=A0=A0 uses require on the order of a few =
packets per hour yet can respond
=A0=A0 in milliseconds.
Avoid using a unit value (hour) unless it is clear that this=
 is given as an example.
4)=A0Checking references for intended status: Prop=
osed Standard
=A0 -----------------------------------------------------------------------=
-----
=A0
=A0=A0=A0=A0 (See RFCs 3967 and 4897 for info=
rmation about using normative references
=A0=A0=A0=A0 to lower-ma=
turity documents in RFCs)


=A0
=A0 =3D=3D Outdated reference: A later version (-11) exi=
sts of
=A0=A0=A0=A0 draft-ietf-roll-rpl-10






Thanks.









=A0









JP.

=A0

--0016e64758662330a8048e2a8663-- From ulrich@herberg.name Thu Aug 19 05:55:01 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB0113A6803 for ; Thu, 19 Aug 2010 05:55:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.283 X-Spam-Level: X-Spam-Status: No, score=-1.283 tagged_above=-999 required=5 tests=[AWL=0.693, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AD-mrBjE3xg for ; Thu, 19 Aug 2010 05:55:01 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id CAE7F3A67F4 for ; Thu, 19 Aug 2010 05:55:00 -0700 (PDT) Received: by vws10 with SMTP id 10so1868515vws.31 for ; Thu, 19 Aug 2010 05:55:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.157.201 with SMTP id c9mr5783893vcx.265.1282222534952; Thu, 19 Aug 2010 05:55:34 -0700 (PDT) Received: by 10.220.164.65 with HTTP; Thu, 19 Aug 2010 05:55:34 -0700 (PDT) In-Reply-To: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> References: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> Date: Thu, 19 Aug 2010 14:55:34 +0200 Message-ID: From: Ulrich Herberg To: JP Vasseur Content-Type: multipart/alternative; boundary=e0cb4e88781bb80663048e2cb2c2 Cc: ROLL WG Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 12:55:02 -0000 --e0cb4e88781bb80663048e2cb2c2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Aug 18, 2010 at 9:30 PM, JP Vasseur wrote: > draft-dt-roll-p2p-rpl-02.txt has been presented several times and discussed > on the mailing list. Could you let us know whether or not you think that > draft-dt-roll-p2p-rpl-02.txt should be adopted as a ROLL Working Group > document (feel free to justify) ? > Yes, IMO it should become a WG document. Ulrich --e0cb4e88781bb80663048e2cb2c2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Aug 18, 2010 at 9:30 PM, JP Vasseur <jpv@cisco.com> wrote:
draft-dt-roll-p2p-rpl-02.txt has been presented several times and discussed= on the mailing list. Could you let us know whether or not you think that d= raft-dt-roll-p2p-rpl-02.txt should be adopted as a ROLL Working Group docum= ent (feel free to justify) ?

Yes, IMO it should become a WG document.

Ulri= ch
--e0cb4e88781bb80663048e2cb2c2-- From Jerald.P.Martocci@jci.com Thu Aug 19 06:10:59 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAFC23A68AC; Thu, 19 Aug 2010 06:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.717 X-Spam-Level: X-Spam-Status: No, score=-3.717 tagged_above=-999 required=5 tests=[AWL=1.327, BAYES_00=-2.599, HTML_MESSAGE=0.001, HTML_MIME_NO_HTML_TAG=0.097, MIME_HTML_ONLY=1.457, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g7Z5ufEQQKqk; Thu, 19 Aug 2010 06:10:54 -0700 (PDT) Received: from exprod8og101.obsmtp.com (exprod8og101.obsmtp.com [64.18.3.82]) by core3.amsl.com (Postfix) with ESMTP id 95ED63A689B; Thu, 19 Aug 2010 06:10:51 -0700 (PDT) Received: from source ([192.132.24.139]) (using SSLv3) by exprod8ob101.postini.com ([64.18.7.12]) with SMTP ID DSNKTG0tfWvDJRJd9JAMXj3EmAbB0A7UQTrR@postini.com; Thu, 19 Aug 2010 06:11:28 PDT Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.0.1) with ESMTP id 2010081908132051-2189140 ; Thu, 19 Aug 2010 08:13:20 -0500 In-Reply-To: References: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> To: JP Vasseur MIME-Version: 1.0 X-KeepSent: F7368D49:4D0243DA-86257784:0048100F; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 FP4 December 11, 2009 From: Jerald.P.Martocci@jci.com Message-ID: Date: Thu, 19 Aug 2010 08:11:26 -0500 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 08/19/2010 08:11:16 AM, Serialize complete at 08/19/2010 08:11:16 AM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/19/2010 08:13:20 AM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.0.1|February 07, 2008) at 08/19/2010 08:13:30 AM, Serialize complete at 08/19/2010 08:13:30 AM Content-Type: multipart/related; boundary="=_related 0048708786257784_=" Cc: ROLL WG , roll-bounces@ietf.org Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 13:10:59 -0000 This is a multipart message in MIME format. --=_related 0048708786257784_= Content-Type: text/html; charset="US-ASCII"
Sorry for the confusion.  I sent this email out before realizing that Mukul has yet to post the 'measurement' draft.  He plans to post today (Thursday).





From: JP Vasseur <jpv@cisco.com>
To: Jerald.P.Martocci@jci.com
Cc: ROLL WG <roll@ietf.org>, roll-bounces@ietf.org
Date: 08/18/2010 04:30 PM
Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ?




Hi Jerry,

On Aug 18, 2010, at 9:47 PM, Jerald.P.Martocci@jci.com wrote:


Yes.  I would like the P2P draft promoted to a WG document.  


Thanks for the feed-back.

BTW.  Mukul's 'Measurement' draft

Which document are you referring to ?

Thanks.

JP.

is really an excerpt from the original P2P draft.  It was extracted as a separate document at the request of reviewers.  I think it would be beneficial to reviewers if both documents were promoted to WG level simultaneously since they complement each other.

Jerry


<mime-attachment.jpeg>

From: JP Vasseur <jpv@cisco.com>
To: ROLL WG <roll@ietf.org>
Date: 08/18/2010 02:30 PM
Subject: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group        document ?



Dear all,

draft-dt-roll-p2p-rpl-02.txt has been presented several times and  
discussed on the mailing list. Could you let us know whether or not  
you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a  
ROLL Working Group document (feel free to justify) ?

Thanks.

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


--=_related 0048708786257784_= Content-Transfer-Encoding: base64 Content-Type: image/jpeg Content-ID: <_2_0A4574C80A4572880048708786257784> /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= --=_related 0048708786257784_=-- From alexandru.petrescu@gmail.com Thu Aug 19 06:25:54 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78E043A67F4 for ; Thu, 19 Aug 2010 06:25:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.126 X-Spam-Level: X-Spam-Status: No, score=-2.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x9b1HoP8LWrb for ; Thu, 19 Aug 2010 06:25:53 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 51C563A6961 for ; Thu, 19 Aug 2010 06:25:53 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o7JDQR2e002596 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 19 Aug 2010 15:26:27 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o7JDQRnB000971 for ; Thu, 19 Aug 2010 15:26:27 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o7JDQLXA005344 for ; Thu, 19 Aug 2010 15:26:27 +0200 Message-ID: <4C6D30FD.2050705@gmail.com> Date: Thu, 19 Aug 2010 15:26:21 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: roll@ietf.org References: <4C4B85CC.6080706@gmail.com> In-Reply-To: <4C4B85CC.6080706@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Roll] How is the Message Authentication Code field computed? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 13:25:54 -0000 Excuse me - was this issue solved? What is the initialization value of the Checksum field when computing the Message Authentication Code? What is computed first: the MAC or the Checksum? Alex Le 25/07/2010 02:31, Alexandru Petrescu a écrit : >> 9.6. Coverage of Integrity and Confidentiality >> >> >> For a RPL ICMPv6 message, the entire packet is within the scope of >> RPL security. > > Well yes and no, because draft says "The body of the RPL ICMPv6 > message MAY be encrypted, starting from the first byte after the > security section" - that is not the entire packet. > >> The message authentication code is calculated over the entire IPv6 >> packet. > > I need to understand this in more detail, and I don't find in draft > (or I don't understand): > > How is the MAC computed? Which fields are covered? Which are > mutable? What's the initialization? > > How is the ICMP Checksum field covered by the MAC? First compute the > Checksum or first the MAC? > > Please give an example. > > (I could give similar with AH HMAC-MD5 and SHA1) (I may not be aware > of a ton of security RFCs and terminology - sorry Michael about > HMAC-MD5 vs MD5). > > Alex _______________________________________________ Roll mailing > list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > > From alexandru.petrescu@gmail.com Thu Aug 19 06:26:19 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 014A43A68B3; Thu, 19 Aug 2010 06:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.128 X-Spam-Level: X-Spam-Status: No, score=-2.128 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Fre6hXNIC6X; Thu, 19 Aug 2010 06:26:18 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 9D1553A6880; Thu, 19 Aug 2010 06:26:17 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o7JDQqvf015219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Aug 2010 15:26:52 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o7JDQpB1001066; Thu, 19 Aug 2010 15:26:51 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o7JDQloZ005383; Thu, 19 Aug 2010 15:26:51 +0200 Message-ID: <4C6D3117.2090209@gmail.com> Date: Thu, 19 Aug 2010 15:26:47 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: ietf Discussion References: <20100818222846.13825.49680.idtracker@localhost> In-Reply-To: <20100818222846.13825.49680.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: roll@ietf.org Subject: Re: [Roll] Last Call: (RPL: IPv6 Routing Protocol for Low power and Lossy Networks) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 13:26:19 -0000 I have already sent a number of substantive comments on version -10 of this draft on the RoLL WG list. Version -11 was not LC'ed on the RoLL WG list. I can send more substantive comments but I am not sure until september 1st 2010. Alex Le 19/08/2010 00:28, The IESG a écrit : > > The IESG has received a request from the Routing Over Low power and > Lossy networks WG (roll) to consider the following document: - 'RPL: > IPv6 Routing Protocol for Low power and Lossy Networks' > as a Proposed Standard > > The IESG plans to make a decision in the next few weeks, and > solicits final comments on this action. Please send substantive > comments to the ietf@ietf.org mailing lists by 2010-09-01. > Exceptionally, comments may be sent to iesg@ietf.org instead. In > either case, please retain the beginning of the Subject line to allow > automated sorting. > > The file can be obtained via > https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/ > > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/ > > > The following IPR Declarations may be related to this I-D: > > /ipr/1270/ /ipr/1356/ /ipr/1366/ > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From jpv@cisco.com Thu Aug 19 07:13:08 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 396503A6950; Thu, 19 Aug 2010 07:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.422 X-Spam-Level: X-Spam-Status: No, score=-110.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cP3PxsLDEu0w; Thu, 19 Aug 2010 07:13:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 29C753A68D5; Thu, 19 Aug 2010 07:13:07 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI7YbEyrRN+J/2dsb2JhbACgW3GhLJtzhTcEiXGCbQ X-IronPort-AV: E=Sophos;i="4.56,233,1280707200"; d="scan'208";a="273467950" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 19 Aug 2010 14:13:42 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o7JEDXZi010560; Thu, 19 Aug 2010 14:13:41 GMT Received: from xfe-ams-202.cisco.com ([144.254.231.96]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Aug 2010 16:13:40 +0200 Received: from [192.168.1.10] ([10.61.90.160]) by xfe-ams-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Aug 2010 16:13:40 +0200 Message-Id: <7E5418FA-E9AF-459F-AD5D-9CDE1E940A31@cisco.com> From: JP Vasseur To: Alexandru Petrescu In-Reply-To: <4C6D3117.2090209@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 19 Aug 2010 16:13:39 +0200 References: <20100818222846.13825.49680.idtracker@localhost> <4C6D3117.2090209@gmail.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 19 Aug 2010 14:13:40.0175 (UTC) FILETIME=[B90AF5F0:01CB3FA8] Cc: roll@ietf.org, ietf Discussion Subject: Re: [Roll] Last Call: (RPL: IPv6 Routing Protocol for Low power and Lossy Networks) to Proposed Standard X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 14:13:08 -0000 Hi Alex, On Aug 19, 2010, at 3:26 PM, Alexandru Petrescu wrote: > I have already sent a number of substantive comments on version -10 of > this draft on the RoLL WG list. Version -11 was not LC'ed on the RoLL > WG list. Version -10 has been WG last called. Comments were addressed, which led to RPL version 11. JP. > > I can send more substantive comments but I am not sure until september > 1st 2010. > > Alex > > Le 19/08/2010 00:28, The IESG a =E9crit : >> >> The IESG has received a request from the Routing Over Low power and >> Lossy networks WG (roll) to consider the following document: - 'RPL: >> IPv6 Routing Protocol for Low power and Lossy Networks' >> as a Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and >> solicits final comments on this action. Please send substantive >> comments to the ietf@ietf.org mailing lists by 2010-09-01. >> Exceptionally, comments may be sent to iesg@ietf.org instead. In >> either case, please retain the beginning of the Subject line to allow >> automated sorting. >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-roll-rpl/ >> >> >> The following IPR Declarations may be related to this I-D: >> >> /ipr/1270/ /ipr/1356/ /ipr/1366/ >> _______________________________________________ Roll mailing list >> Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf From coflynn@newae.com Thu Aug 19 07:35:30 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B64893A67B5 for ; Thu, 19 Aug 2010 07:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eWrjPAKBd9CD for ; Thu, 19 Aug 2010 07:35:17 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 083393A695D for ; Thu, 19 Aug 2010 07:35:16 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1Om6Db-0005PV-Sn for roll@ietf.org; Thu, 19 Aug 2010 10:35:49 -0400 From: "Colin O'Flynn" To: Date: Thu, 19 Aug 2010 15:35:42 +0100 Message-ID: <004801cb3fab$d0231a30$70694e90$@com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0049_01CB3FB4.31E78230" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs/q8yuBWwIlAntTAKR7HjCTdVl7A== Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Subject: [Roll] English usage in I-D's X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 14:35:30 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0049_01CB3FB4.31E78230 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hello, I finally got time to catching up on some of the latest I-D's. I'm a little taken back by the complexity of English used in the drafts, especially references to more academic things and just all-around inconsistency. People reading these will likely be engineers needing to implement the standards. I pain to see how someone with English as a second language who has been away from the academic side of things for a while will do. I know RPL has gone to the IETF so it's too late to post things here, but thought I'd put them up here first anyway for comments. Maybe I'm just missing something. As a few examples: #1) Trickle from mailing list discussion > For the WG, the misunderstanding was coming from the the use of different > notation. In some countries we use [a,b[ instead: > > But that's OK let's use the [a,b) notation. There is even a chance to confuse people IN the field! Why not either define what is meant by writing it out, or use something like 'a <= x < b'? I see a note that a 'natural langauge' description will be added which makes sense hopefully... #2) Trickle + RPL Together (from section 8.3, RPL) > Note that this list is not exhaustive, and an implementation MAY > consider other messages or events to be inconsistencies. My implementation could consider the "main oscillator oscillating" an inconsistency by that wording, and just transmit DIO packets as long as it wanted couldn't it, and be 100% to spec? There is something to be said for not trying to make the specification too flexible I think. In all seriousness though shouldn't this section have better linkage? Section 5 of the trickle draft says what the protocol specification needs to specify. The Imin/Imax/k are specified well in section 8.3.1. However the definition of a "consistent" transmission is semi-hidden in the paragraph: > A DIO from a sender with a lesser DAGRank > that causes no changes to the recipient's parent set, preferred > parent, or Rank SHOULD be considered consistent with respect to the > Trickle timer. Am I just stupid, or would it be better if that section (8.3) was reworded such that it explicitly states what a "consistent transmission" and "inconsistent transmission" is, and possibly combined with section 8.3.1. By this I mean consider someone who sees in the Trickle draft that RPL should specify those six items, then wants to quickly find them in the RPL draft. They would find Imin/Imax/k no problem as they are well defined in an appropriately titled section. The only chance of finding the other three is if you looked above section 8.3.1, or searched the document for the word 'Trickle'. #3) Option Length Definitions Let's look at all the different wordings for 'option length': >Option Length: 8-bit unsigned integer, representing the length in > octets of the option, not including the Option Type and Length > fields. >Option Length: For N (N > 1) octets of padding, the Option Length > field contains the value N-2. >Option Length: The Option Length field contains the length in octets > of the Metric Data. >Option Length: Variable, length of the option in octets excluding > the Type and Length fields. Note that this length is expressed > in units of single-octets, unlike in IPv6 ND. >Option Length: 14 >Option Length: Variable, length of the option in octets excluding > the Type and Length fields. >Option Length: Variable, depending on whether or not Parent Address > is present. >Option Length: 19 >Option Length: 30. Note that this length is expressed in units of > single-octets, unlike in IPv6 ND. >Option Length: 4 I count 10 definitions of option length. The only ones that are consistent are the 13/19/4 types, every other definition uses a different wording. #4) Use of too many Words The purpose of English is to communicate clearly. Adding more words than needed detracts from that purpose. You write to be understood by the reader, not to feel good about what you are writing. Consider the following beauties: 4.1 - OF (from section 3.7, RPL) > The Objective Function itself is decoupled from the routing metrics > and constraints used by RPL. Indeed, whereas the OF dictates rules > such as DODAG parents selection, load balancing and so on, the set of > metrics and/or constraints used, and thus determine the preferred > path, are based on the information carried within the DAG container > option in DIO messages. Amazingly there is two sentences in there; the first one makes sense but is a little complicated, the second one has five commas and seems to be written by two different people about half-way through. 4.2 - Loop Avoidance (from section 3.8, RPL) > "rank-based datapath validation mechanisms" Despite the fact this section is a repeat of elsewhere (see #5), this is a great example of what I mean. The first phrase is a less clear way of saying either "validating rank" or even better "checking packets are moving in the intended direction". Of course a "rank-based datapath validation mechanism" sounds like more of an achievement than either of those two. 4.3 - Greediness (from section 3.8.1, RPL) All of section 3.8.1/3.8.1.1 seems unnecessary. RPL doesn't allow greediness - case closed. If you want to learn about greediness in general the RPL draft isn't the location. 4.4 - Introduction (section 1, 1.2, RPL) > Examples of such objectives include > minimizing energy, minimizing latency, or satisfying constraints Of course, 'satisfying constraints'. Wait, isn't minimizing energy and minimizing latency also satisfying a constraint? > RPL > is designed to be able to operate over a variety of different link > layers, including ones that are constrained, potentially lossy, or > typically utilized in conjunction with highly constrained host or > router devices, such as but not limited to, low power wireless or PLC > (Power Line Communication) technologies. Was this a contest to write the words "different link layers" in as many words as possible? #5) Sections that repeat the same information (RPL) This is mostly a problem in section 3. Lots of information is repeated in different locations, which just makes it longer and more confusing. Consider section 3.8 and section 3.3.7. They are both in the overview and deal with loops, and basically say the same thing. There's some more loop stuff later even in section 3.8.2, but it's at least a tiny bit different! Throughout most of the introduction there is similar things. Section 3.7 has two paragraphs about the objective function, but then there is also a separate paragraph in section 3.3.1 about the objective function. Further it seems random if 'Objective Function', 'OF', 'Objective Function (OF)', or 'objective function' is used in the whole document. There's plenty more but I haven't gone through everything. My comments here are purely on how the draft is written, nothing technical. I'm not sure how the IETF works but hopefully we could clean this up a lot without affecting LC, since it's not actually changing any packet formats or logic. Regards, -Colin O'Flynn ------=_NextPart_000_0049_01CB3FB4.31E78230 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,=

 =

I finally got time to catching up on some of the latest I-D's. I'm a = little taken back by the complexity of English used in the drafts, especially = references to more academic things and just all-around inconsistency. =

 =

People reading these will likely be engineers needing to implement the = standards. I pain to see how someone with English as a second language who has been = away from the academic side of things for a while will = do.

 =

I know RPL has gone to the IETF so it’s too late to post things = here, but thought I’d put them up here first anyway for comments. Maybe = I’m just missing something.

 =

As a few examples:

 

#1) Trickle from mailing list discussion

> For the WG, the misunderstanding was coming = from the the use of different

> notation. In some countries we use [a,b[ = instead:

> 

> But that's OK let's use the [a,b) = notation.

 =

There is even a chance to confuse people IN the field! Why not either define = what is meant by writing it out, or use something like 'a <=3D x < b'? I = see a note that a 'natural langauge' description will be added which makes sense hopefully...

 

#2) Trickle + RPL Together (from section 8.3, RPL)

 

> Note that this list is not exhaustive, and = an implementation MAY

> consider other messages or events to be inconsistencies.

 

My implementation could consider the "main oscillator = oscillating" an inconsistency by that wording, and just transmit DIO packets as long as = it wanted couldn't it, and be 100% to spec? There is something to be said = for not trying to make the specification too flexible I think.

 =

In all seriousness though shouldn't this section have better linkage? = Section 5 of the trickle draft says what the protocol specification needs to specify. = The Imin/Imax/k are specified well in section 8.3.1. However the definition = of a “consistent” transmission is semi-hidden in the paragraph:

 

>       A DIO from a sender with a =
lesser DAGRank

>       that causes no changes to the recipient's parent set, = preferred

>       parent, or Rank SHOULD be considered consistent with respect to = the

>       Trickle timer.

 

Am I just stupid, or would it be better if that section (8.3) was reworded = such that it explicitly states what a “consistent transmission” = and “inconsistent transmission” is, and possibly combined with section 8.3.1. By = this I mean consider someone who sees in the Trickle draft that RPL should specify = those six items, then wants to quickly find them in the RPL draft. They would find Imin/Imax/k no problem as they are well defined in an appropriately = titled section. The only chance of finding the other three is if you looked above = section 8.3.1, or searched the document for the word = ‘Trickle’.

 =

#3) Option Length Definitions

 

Let’s look at all the different wordings = for ‘option length’:

 

>Option Length:  8-bit unsigned integer, representing the length in

>        = octets of the option, not including the Option Type and Length

>        = fields.

 

>Option Length:  For N (N > 1) octets = of padding, the Option Length

>        = field contains the value N-2.

 

>Option Length:  The Option Length field = contains the length in octets

>        = of the Metric Data.

 

>Option Length:  Variable, length of the = option in octets excluding

>        = the Type and Length fields.  Note that this length is = expressed

>        = in units of single-octets, unlike in IPv6 ND.

 

>Option Length:  14

 

>Option Length:  Variable, length of the = option in octets excluding

>        = the Type and Length fields.

 

>Option Length:  Variable, depending on = whether or not Parent Address

>        = is present.

 

>Option Length:  19

 

>Option Length:  30.  Note that = this length is expressed in units of

>        = single-octets, unlike in IPv6 ND.

 

>Option Length:  4

 

I count 10 definitions of option length. The only ones that are consistent = are the 13/19/4 types, every other definition uses a different wording. =

 

#4) Use of too many Words

 

The purpose of English is to communicate clearly. = Adding more words than needed detracts from that purpose. You write to be = understood by the reader, not to feel good about what you are writing. Consider the following beauties:

 

4.1 – OF (from section 3.7, = RPL)

 

>       The Objective Function =
itself is decoupled from the routing =
metrics
>       =
and constraints used by RPL.  Indeed, whereas the OF dictates =
rules
>       such =
as DODAG parents selection, load balancing and so on, the set =
of
>       metrics =
and/or constraints used, and thus determine the =
preferred
>       =
path, are based on the information carried within the DAG =
container
>       =
option in DIO messages.
 

Amazingly there is two sentences in there; the = first one makes sense but is a little complicated, the second one has five commas = and seems to be written by two different people about half-way = through.

 

4.2 – Loop Avoidance (from section 3.8, = RPL)      

>       “rank-based datapath =
validation =
mechanisms”
 

Despite the fact this section is a repeat of = elsewhere (see #5), this is a great example of what I mean. The first phrase is a less = clear way of saying either “validating rank” or even better = “checking packets are moving in the intended direction”. Of course a = “rank-based datapath validation mechanism” sounds like more of an achievement = than either of those two.

 

4.3 – Greediness (from section 3.8.1, = RPL)

All of section 3.8.1/3.8.1.1 seems unnecessary. RPL = doesn’t allow greediness – case closed. If you want to learn about = greediness in general the RPL draft isn’t the location.

 

4.4 – Introduction (section 1, 1.2, = RPL)

>       Examples of such =
objectives =
include
>       =
minimizing energy, minimizing latency, or satisfying =
constraints

 

Of course, ‘satisfying constraints’. = Wait, isn’t minimizing energy and minimizing latency also satisfying a = constraint?

 

>   RPL
>   is =
designed to be able to operate over a variety of different =
link
>   layers, including ones that =
are constrained, potentially lossy, =
or
>   typically utilized in =
conjunction with highly constrained host =
or
>   router devices, such as but not =
limited to, low power wireless or =
PLC
>   (Power Line Communication) =
technologies.

 

Was this a contest to write the words = “different link layers” in as many words as possible?

 

#5) Sections that repeat the same information = (RPL)

 

This is mostly a problem in section 3. Lots of = information is repeated in different locations, which just makes it longer and more confusing.

 

Consider section 3.8 and section 3.3.7. They are = both in the overview and deal with loops, and basically say the same thing. = There’s some more loop stuff later even in section 3.8.2, but it’s at = least a tiny bit different!

 

Throughout most of the introduction there is = similar things. Section 3.7 has two paragraphs about the objective function, but then = there is also a separate paragraph in section 3.3.1 about the objective function. Further it seems random if ‘Objective Function’, = ‘OF’, ‘Objective Function (OF)’, or ‘objective function’ is used in the = whole document.

 

There’s plenty more but I haven’t gone = through everything. My comments here are purely on how the draft is written, = nothing technical. I’m not sure how the IETF works but hopefully we could = clean this up a lot without affecting LC, since it’s not actually = changing any packet formats or logic.

 

Regards,

 

  -Colin O’Flynn

------=_NextPart_000_0049_01CB3FB4.31E78230-- From zach@sensinode.com Thu Aug 19 09:47:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021633A6947 for ; Thu, 19 Aug 2010 09:47:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.513 X-Spam-Level: X-Spam-Status: No, score=-3.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0YKiA4cO0kk8 for ; Thu, 19 Aug 2010 09:47:33 -0700 (PDT) Received: from auth-smtp.nebula.fi (auth-smtp.nebula.fi [217.30.180.105]) by core3.amsl.com (Postfix) with ESMTP id 2FEAE3A6855 for ; Thu, 19 Aug 2010 09:47:32 -0700 (PDT) Received: from [192.168.1.3] (line-7567.dyn.kponet.fi [85.29.75.235]) (authenticated bits=0) by auth-smtp.nebula.fi (8.13.4/8.13.4) with ESMTP id o7JGm37K011304 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 19 Aug 2010 19:48:03 +0300 From: Zach Shelby Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/signed; boundary=Apple-Mail-46--1013392701; protocol="application/pkcs7-signature"; micalg=sha1 Date: Thu, 19 Aug 2010 19:48:05 +0300 In-Reply-To: <010901cb3f0e$715132f0$53f398d0$@sturek@att.net> To: roll WG References: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> <010901cb3f0e$715132f0$53f398d0$@sturek@att.net> Message-Id: <26982363-CED8-4983-B21E-188B7344277F@sensinode.com> X-Mailer: Apple Mail (2.1081) Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 16:47:35 -0000 --Apple-Mail-46--1013392701 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii +1 On Aug 18, 2010, at 10:49 PM, Don Sturek wrote: > +1 > > I am in favor of the p2p draft being adopted by ROLL > > Don > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of JP > Vasseur > Sent: Wednesday, August 18, 2010 12:30 PM > To: ROLL WG > Subject: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group > document ? > > Dear all, > > draft-dt-roll-p2p-rpl-02.txt has been presented several times and > discussed on the mailing list. Could you let us know whether or not > you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a > ROLL Working Group document (feel free to justify) ? > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll -- Zach Shelby, Chief Nerd, Sensinode Ltd. http://zachshelby.org - My blog "On the Internet of Things" http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" Mobile: +358 40 7796297 --Apple-Mail-46--1013392701 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKGzCCBMww ggQ1oAMCAQICEByunWua9OYvIoqj2nRhbB4wDQYJKoZIhvcNAQEFBQAwXzELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1YmxpYyBQcmltYXJ5 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTA1MTAyODAwMDAwMFoXDTE1MTAyNzIzNTk1OVow gd0xCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNp Z24gVHJ1c3QgTmV0d29yazE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZl cmlzaWduLmNvbS9ycGEgKGMpMDUxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUG A1UEAxMuVmVyaVNpZ24gQ2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMjCCASIw DQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMnfrOfq+PgDFMQAktXBfjbCPO98chXLwKuMPRyV zm8eECw/AO2XJua2x+atQx0/pIdHR0w+VPhs+Mf8sZ69MHC8l7EDBeqV8a1AxUR6SwWi8mD81zpl Yu//EHuiVrvFTnAt1qIfPO2wQuhejVchrKaZ2RHp0hoHwHRHQgv8xTTq/ea6JNEdCBU3otdzzwFB L2OyOj++pRpu9MlKWz2VphW7NQIZ+dTvvI8OcXZZu0u2Ptb8Whb01g6J8kn+bAztFenZiHWcec5g J925rXXOL3OVekA6hXVJsLjfaLyrzROChRFQo+A8C67AClPN1zBvhTJGG+RJEMJs4q8fef/btLUC AwEAAaOCAYQwggGAMBIGA1UdEwEB/wQIMAYBAf8CAQAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcX ATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIB BjARBglghkgBhvhCAQEEBAMCAQYwLgYDVR0RBCcwJaQjMCExHzAdBgNVBAMTFlByaXZhdGVMYWJl bDMtMjA0OC0xNTUwHQYDVR0OBBYEFBF9Xhl9PATfamzWoooaPzHYO5RSMDEGA1UdHwQqMCgwJqAk oCKGIGh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL3BjYTEuY3JsMIGBBgNVHSMEejB4oWOkYTBfMQsw CQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVi bGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCEQDNun9W8N/kvFT+IqyzcqpVMA0G CSqGSIb3DQEBBQUAA4GBALEv2ZbhkqLugWDlyCog++FnLNYAmFOjAhvpkEv4GESfD0b3+qD+0x0Y o9K/HOzWGZ9KTUP4yru+E4BJBd0hczNXwkJavvoAk7LmBDGRTl088HMFN2Prv4NZmP1m3umGMpqS KTw6rlTaphJRsY/IytNHeObbpR6HBuPRFMDCIfa6MIIFRzCCBC+gAwIBAgIQan0RUwdo1sLDyX/9 fFJOUTANBgkqhkiG9w0BAQUFADCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEcyMB4XDTEwMDgxMDAwMDAwMFoXDTExMDgxMDIzNTk1OVowggEQMRcwFQYD VQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQG A1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypEaWdp dGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1phY2ggU2hl bGJ5MSEwHwYJKoZIhvcNAQkBFhJ6YWNoQHNlbnNpbm9kZS5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQCp7y7xWjidkiLHBnXP0MF+ZApAJC4Ef9cZCDtcNI55c7D78XMODsUyGxhH i5bnZQIf09tFuXl+088/VS7qgyrxo58QXpwmA7tP22bHVGb0asnxFZ28cnIvkZBcFaBgfPdi92Pb 6PL87S1bQqjw0CxXuGEs4VJtLKSejLVEYbs7CtkKMC/rfJixp3ytJ4rNh5U/XD/B2pM85DYmssto GkoXFwTwNB0HqNvGF9LN7D9JohmGkwo/FzqCZilf5CoFxM83xLHzbjPoDhZeXi/ygSiTF0eOC5ja 5vMFNyk6a+G8WlmxsUPqF73Lb1boJVODLKKDCu7wfk5ORoOUsA2YTFS9AgMBAAGjgcwwgckwCQYD VR0TBAIwADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUBBxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8v d3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQDAgWgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vSW5kQzFEaWdpdGFsSUQtY3JsLnZlcmlz aWduLmNvbS9JbmRDMURpZ2l0YWxJRC5jcmwwDQYJKoZIhvcNAQEFBQADggEBALA0uBctOXHWFO4I 2m3Ldf6Ui26jWIeYDAZ3Y12V3h8lU25RWegX4MwRGm0NcZvdX/jHlhGmvkbAegvYN3WUH9XNxRGf nXzVvK8oXChM23ET2b/g2zEsmimoDvsjvONV2vXRIPF1xMuKeWL/PsNiRKnq+jTbSOdqh7k4Rp8W PKfNjOGIRjYYHDB0O84i+JoSJKSzQp5SWpVG2vVIGLFG9vVxVjY65lqmqoxRIFRbtO7Qi/E4xxmm nRP75n1yAm7QOt+jCqJ8mCxQ0G/damNIHRxYJd0QNavACz34gdLmwEa88emIXscqqqxTyIj+jdIn VVOFE7PUo6rrAldWaGke1TYxggSLMIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQL EzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwG A1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIElu ZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMAkGBSsOAwIaBQCg ggJtMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEwMDgxOTE2NDgw NVowIwYJKoZIhvcNAQkEMRYEFBwjjN4pcuquON3qpey0OACAp9euMIIBAwYJKwYBBAGCNxAEMYH1 MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3 dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQx NzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzIC EGp9EVMHaNbCw8l//XxSTlEwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhBqfRFTB2jWwsPJf/18Uk5RMA0G CSqGSIb3DQEBAQUABIIBAKBW4U8zJcfCZZLfe5qtmhDwMlydBB3U/+GNMBKE1r/qBHnx0TCMIZKe WqolZWHTZ4baipStAwFSSkAMS3L4Pws1xiDrH+Gez+Dq9fxaojS0EofX84dJQ8KhRnibE7QabK18 v8qn1rrGi8jILn4GtRTXNXf1ftKFwF3t6tjSC5z6UPcCaJZ3obVvClWPMmwyw6JXnPKtgA+UJPEz 484FOSR3gblYlNNVisd37dUbXRhXk0I3bOYp6CADRYTJnZnVtXup9qZnH8oKGQ73c4ZP1XHzrTln SZxx+vfcXdNLSWurxd+rqfvx8hxrFtUevmupxQZoX+ajpX0WVW7qlNWnrOcAAAAAAAA= --Apple-Mail-46--1013392701-- From trac@tools.ietf.org Thu Aug 19 09:50:00 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 386763A6980 for ; Thu, 19 Aug 2010 09:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+H-+GWp4LN4 for ; Thu, 19 Aug 2010 09:49:59 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 859DA3A697B for ; Thu, 19 Aug 2010 09:49:59 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1Om8K1-0004Q9-DI; Thu, 19 Aug 2010 09:50:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "roll issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: pal@cs.stanford.edu, jpv@cisco.com X-Trac-Project: roll Date: Thu, 19 Aug 2010 16:50:33 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/68#comment:3 Message-ID: <064.f4619342562592de985d2082aa2f460f@tools.ietf.org> References: <055.d6c07a2e80e500043479718ae01fdc48@tools.ietf.org> X-Trac-Ticket-ID: 68 In-Reply-To: <055.d6c07a2e80e500043479718ae01fdc48@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: pal@cs.stanford.edu, jpv@cisco.com, roll@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: Re: [Roll] [roll] #68: RPL security comments received during LC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 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: Thu, 19 Aug 2010 16:50:00 -0000 #68: RPL security comments received during LC -----------------------------+---------------------------------------------- Reporter: jpv@… | Owner: pal@… Type: defect | Status: closed Priority: major | Milestone: Component: rpl | Version: Severity: In WG Last Call | Resolution: fixed Keywords: | -----------------------------+---------------------------------------------- Changes (by jpv@…): * status: reopened => closed * resolution: => fixed -- Ticket URL: roll From pal@cs.stanford.edu Thu Aug 19 09:57:53 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 87F523A696F for ; Thu, 19 Aug 2010 09:57:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.081 X-Spam-Level: X-Spam-Status: No, score=-6.081 tagged_above=-999 required=5 tests=[AWL=-0.082, BAYES_00=-2.599, J_CHICKENPOX_18=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zvMNZBPmqdt for ; Thu, 19 Aug 2010 09:57:52 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 3C65A3A68CB for ; Thu, 19 Aug 2010 09:57:52 -0700 (PDT) Received: from dn0a2101cb.sunet ([10.33.1.203]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Om8Re-00059t-OQ; Thu, 19 Aug 2010 09:58:27 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Philip Levis In-Reply-To: <004801cb3fab$d0231a30$70694e90$@com> Date: Thu, 19 Aug 2010 09:58:25 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <7F60EAC1-5A7D-481E-961D-F7728AB85726@cs.stanford.edu> References: <004801cb3fab$d0231a30$70694e90$@com> To: Colin O'Flynn X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 00ae0dc23c387355c0c9f5c46aa55045 Cc: roll@ietf.org Subject: Re: [Roll] English usage in I-D's X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 16:57:53 -0000 On Aug 19, 2010, at 7:35 AM, Colin O'Flynn wrote: > Hello, > =20 > I finally got time to catching up on some of the latest I-D's. I'm a = little taken back by the complexity of English used in the drafts, = especially references to more academic things and just all-around = inconsistency. > =20 > People reading these will likely be engineers needing to implement the = standards. I pain to see how someone with English as a second language = who has been away from the academic side of things for a while will do. > =20 > I know RPL has gone to the IETF so it=92s too late to post things = here, but thought I=92d put them up here first anyway for comments. = Maybe I=92m just missing something. > =20 > As a few examples: > =20 > #1) Trickle from mailing list discussion > > For the WG, the misunderstanding was coming from the the use of = different > > notation. In some countries we use [a,b[ instead: > >=20 > > But that's OK let's use the [a,b) notation. > =20 > There is even a chance to confuse people IN the field! Why not either = define what is meant by writing it out, or use something like 'a <=3D x = < b'? I see a note that a 'natural langauge' description will be added = which makes sense hopefully... Yes, that description was added.=20 "When an interval begins, Trickle resets c to 0 and sets t to a random point in the interval, taken from the range [I/2, I), that is, values greater than or equal to I/2 and less than I. The interval ends at I." > =20 > #2) Trickle + RPL Together (from section 8.3, RPL) > =20 > > Note that this list is not exhaustive, and an implementation MAY > > consider other messages or events to be inconsistencies. > =20 > My implementation could consider the "main oscillator oscillating" an = inconsistency by that wording, and just transmit DIO packets as long as = it wanted couldn't it, and be 100% to spec? There is something to be = said for not trying to make the specification too flexible I think. > =20 > In all seriousness though shouldn't this section have better linkage? = Section 5 of the trickle draft says what the protocol specification = needs to specify. The Imin/Imax/k are specified well in section 8.3.1. = However the definition of a =93consistent=94 transmission is semi-hidden = in the paragraph: > =20 > > A DIO from a sender with a lesser DAGRank > > that causes no changes to the recipient's parent set, = preferred > > parent, or Rank SHOULD be considered consistent with respect = to the > > Trickle timer. > =20 > Am I just stupid, or would it be better if that section (8.3) was = reworded such that it explicitly states what a =93consistent = transmission=94 and =93inconsistent transmission=94 is, and possibly = combined with section 8.3.1. By this I mean consider someone who sees in = the Trickle draft that RPL should specify those six items, then wants to = quickly find them in the RPL draft. They would find Imin/Imax/k no = problem as they are well defined in an appropriately titled section. The = only chance of finding the other three is if you looked above section = 8.3.1, or searched the document for the word =91Trickle=92. This section was very carefully worded. Please note that the definition = of what constitutes a consistent transmission is an optimization method: = it leads to suppression, reducing communication and energy expenditure. = If a node does not suppress (e.g., k=3Dinfinity, defines nothing as = consistent), then it simply transmits every interval. In contrast, the = definition of what is *inconsistent* is critical for correctness. Hence = the inconsistencies being defined as MUSTs. > =20 > #3) Option Length Definitions > =20 > Let=92s look at all the different wordings for =91option length=92: > =20 > >Option Length: 8-bit unsigned integer, representing the length in > > octets of the option, not including the Option Type and = Length > > fields. > =20 > >Option Length: For N (N > 1) octets of padding, the Option Length > > field contains the value N-2. > =20 > >Option Length: The Option Length field contains the length in octets > > of the Metric Data. > =20 > >Option Length: Variable, length of the option in octets excluding > > the Type and Length fields. Note that this length is = expressed > > in units of single-octets, unlike in IPv6 ND. > =20 > >Option Length: 14 > =20 > >Option Length: Variable, length of the option in octets excluding > > the Type and Length fields. > =20 > >Option Length: Variable, depending on whether or not Parent Address > > is present. > =20 > >Option Length: 19 > =20 > >Option Length: 30. Note that this length is expressed in units of > > single-octets, unlike in IPv6 ND. > =20 > >Option Length: 4 > =20 > I count 10 definitions of option length. The only ones that are = consistent are the 13/19/4 types, every other definition uses a = different wording. > =20 > #4) Use of too many Words > =20 > The purpose of English is to communicate clearly. Adding more words = than needed detracts from that purpose. You write to be understood by = the reader, not to feel good about what you are writing. Consider the = following beauties: > =20 > 4.1 =96 OF (from section 3.7, RPL) > =20 > > The Objective Function itself is decoupled from the routing = metrics > > and constraints used by RPL. Indeed, whereas the OF dictates = rules > > such as DODAG parents selection, load balancing and so on, the = set of > > metrics and/or constraints used, and thus determine the = preferred > > path, are based on the information carried within the DAG = container > > option in DIO messages. > =20 > Amazingly there is two sentences in there; the first one makes sense = but is a little complicated, the second one has five commas and seems to = be written by two different people about half-way through. Colin -- we have had this discussion on the list already. It's partially = a cultural difference. The notion that fewer words is better originated = in American writing in the 19th century. The same metric does not hold = in all languages or all readers/writers of English. As one example, = Pascal, JP and I debated it a lot: I always thought fewer words is = better, while their opinion, coming from French, was that more text = typically adds greater larit. > =20 > 4.2 =96 Loop Avoidance (from section 3.8, RPL) =20 > > =93rank-based datapath validation mechanisms=94 > =20 > Despite the fact this section is a repeat of elsewhere (see #5), this = is a great example of what I mean. The first phrase is a less clear way = of saying either =93validating rank=94 or even better =93checking = packets are moving in the intended direction=94. Of course a =93rank-based= datapath validation mechanism=94 sounds like more of an achievement = than either of those two. > =20 > 4.3 =96 Greediness (from section 3.8.1, RPL) > All of section 3.8.1/3.8.1.1 seems unnecessary. RPL doesn=92t allow = greediness =96 case closed. If you want to learn about greediness in = general the RPL draft isn=92t the location. > =20 > 4.4 =96 Introduction (section 1, 1.2, RPL) > > Examples of such objectives include > > minimizing energy, minimizing latency, or satisfying = constraints > =20 > Of course, =91satisfying constraints=92. Wait, isn=92t minimizing = energy and minimizing latency also satisfying a constraint? > =20 > > RPL > > is designed to be able to operate over a variety of different link > > layers, including ones that are constrained, potentially lossy, or > > typically utilized in conjunction with highly constrained host or > > router devices, such as but not limited to, low power wireless or = PLC > > (Power Line Communication) technologies. > =20 > Was this a contest to write the words =93different link layers=94 in = as many words as possible? > =20 > #5) Sections that repeat the same information (RPL) > =20 > This is mostly a problem in section 3. Lots of information is repeated = in different locations, which just makes it longer and more confusing. > =20 > Consider section 3.8 and section 3.3.7. They are both in the overview = and deal with loops, and basically say the same thing. There=92s some = more loop stuff later even in section 3.8.2, but it=92s at least a tiny = bit different! > =20 > Throughout most of the introduction there is similar things. Section = 3.7 has two paragraphs about the objective function, but then there is = also a separate paragraph in section 3.3.1 about the objective function. = Further it seems random if =91Objective Function=92, =91OF=92, = =91Objective Function (OF)=92, or =91objective function=92 is used in = the whole document. > =20 > There=92s plenty more but I haven=92t gone through everything. My = comments here are purely on how the draft is written, nothing technical. = I=92m not sure how the IETF works but hopefully we could clean this up a = lot without affecting LC, since it=92s not actually changing any packet = formats or logic. No document is ever perfect -- it can always be improved by editing. = It's great that someone is taking a fresh look. As I'm sure you know, = when you've been writing and rewriting for a long time, you can lose = context and perspective. Phil= From Emmanuel.Monnerie@landisgyr.com Thu Aug 19 11:11:22 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 802B13A6899 for ; Thu, 19 Aug 2010 11:11:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.601 X-Spam-Level: X-Spam-Status: No, score=0.601 tagged_above=-999 required=5 tests=[BAYES_50=0.001, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id leXf32whBPnz for ; Thu, 19 Aug 2010 11:11:19 -0700 (PDT) Received: from mta2.cellnet.com (cnetpm1.cellnet.com [148.80.254.17]) by core3.amsl.com (Postfix) with ESMTP id CC7633A686A for ; Thu, 19 Aug 2010 11:11:17 -0700 (PDT) X-ASG-Debug-ID: 1282241511-192a00080000-BCmCR7 X-Barracuda-URL: http://172.25.128.17:8000/cgi-bin/mark.cgi Received: from livemail.cellnethunt.com (localhost [127.0.0.1]) by mta2.cellnet.com (Spam Firewall) with ESMTP id 3D8D9483A14 for ; Thu, 19 Aug 2010 14:11:51 -0400 (EDT) Received: from livemail.cellnethunt.com ([10.1.130.15]) by mta2.cellnet.com with ESMTP id GcAzJiQjaephLMkT for ; Thu, 19 Aug 2010 14:11:51 -0400 (EDT) X-ASG-Whitelist: Sender X-ASG-Whitelist: Client Received: from livemail.cellnethunt.com ([10.1.130.105]) by livemail.cellnethunt.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 19 Aug 2010 14:11:50 -0400 Received: from mail pickup service by livemail.cellnethunt.com with Microsoft SMTPSVC; Thu, 19 Aug 2010 14:11:50 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Content-Class: urn:content-classes:message Importance: normal Priority: normal MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-ASG-Orig-Subj: RE: [Roll] English usage in I-D's Date: Thu, 19 Aug 2010 14:11:49 -0400 Message-ID: <76DBCE2AA6605F42A49F1BD7454C841BF652F8@usatlsv105.am.bm.net> In-Reply-To: <7F60EAC1-5A7D-481E-961D-F7728AB85726@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] English usage in I-D's thread-index: Acs/v8LYD6so7ryiSOq3wzysBMKF6AABth+w References: <004801cb3fab$d0231a30$70694e90$@com> <7F60EAC1-5A7D-481E-961D-F7728AB85726@cs.stanford.edu> From: "Monnerie, Emmanuel" To: "Philip Levis" , "Colin O'Flynn" X-OriginalArrivalTime: 19 Aug 2010 18:11:50.0581 (UTC) FILETIME=[FEC9DE50:01CB3FC9] X-Barracuda-Connect: UNKNOWN[10.1.130.15] X-Barracuda-Start-Time: 1282241511 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at cellnet.com Cc: roll@ietf.org Subject: Re: [Roll] English usage in I-D's X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:11:22 -0000 I don't know what the French culture has to do with it. I'm French and I do believe that fewer words are better, particularly when it comes to engineering documentation. If we were writing an essay or a piece of literature, I would argue the opposite. So I agree with Colin: many sentences are overly complicated. Furthermore, the text is repeating several times similar statements, which causes even more confusion. For example, look how many times the word "RPLInstanceID" is defined throughout the text. Best Regards -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: Thursday, August 19, 2010 12:58 PM To: Colin O'Flynn Cc: roll@ietf.org Subject: Re: [Roll] English usage in I-D's > 4.1 - OF (from section 3.7, RPL) > > > The Objective Function itself is decoupled from the routing metrics > > and constraints used by RPL. Indeed, whereas the OF dictates rules > > such as DODAG parents selection, load balancing and so on, the set of > > metrics and/or constraints used, and thus determine the preferred > > path, are based on the information carried within the DAG container > > option in DIO messages. > > Amazingly there is two sentences in there; the first one makes sense but is a little complicated, the second one has five commas and seems to be written by two different people about half-way through. Colin -- we have had this discussion on the list already. It's partially a cultural difference. The notion that fewer words is better originated in American writing in the 19th century. The same metric does not hold in all languages or all readers/writers of English. As one example, Pascal, JP and I debated it a lot: I always thought fewer words is better, while their opinion, coming from French, was that more text typically adds greater larit. Emmanuel Monnerie Senior Research Engineer Landis+Gyr Energy Management Solutions Office: +1 678 258 1695 Fax: +1 678 258 1316 Emmanuel.Monnerie@landisgyr.com www.landisgyr.com manage energy better From dat@exegin.com Thu Aug 19 11:45:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 857C83A6991 for ; Thu, 19 Aug 2010 11:45:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[AWL=0.687, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yNEGGv6sgNn8 for ; Thu, 19 Aug 2010 11:45:34 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 6B8563A6974 for ; Thu, 19 Aug 2010 11:45:34 -0700 (PDT) Received: by ewy22 with SMTP id 22so1660373ewy.31 for ; Thu, 19 Aug 2010 11:46:08 -0700 (PDT) Received: by 10.216.232.229 with SMTP id n79mr183641weq.52.1282243568181; Thu, 19 Aug 2010 11:46:08 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id k7sm1244042wej.26.2010.08.19.11.46.05 (version=SSLv3 cipher=RC4-MD5); Thu, 19 Aug 2010 11:46:07 -0700 (PDT) Message-ID: <4C6D7BDD.7000807@exegin.com> Date: Thu, 19 Aug 2010 11:45:49 -0700 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Roll] Question on path to grand children in non-storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:45:35 -0000 Given the following simple linear DODAG operating in non-storing mode: ER [A]<---[B]<---[C]<---[D]<---[E] Where [A] is the DODAG root. If [C] wants to send a packet to [E], is it true that the path would be [C] to [B] to [A] to [B] to [C] to [D] to [E] ? Since, (in non-storing mode) the root node is the only node that stores routes, I can't see any other way of [C] reaching [E]. Or, am I missing something? Dario From prvs=840cb0eff=mukul@uwm.edu Thu Aug 19 11:53:26 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DFEA3A697F for ; Thu, 19 Aug 2010 11:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.073 X-Spam-Level: X-Spam-Status: No, score=-3.073 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggln90AIaji4 for ; Thu, 19 Aug 2010 11:53:25 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id 230993A694D for ; Thu, 19 Aug 2010 11:53:25 -0700 (PDT) Received: from mta04.pantherlink.uwm.edu ([129.89.7.101]) by ip2mta.uwm.edu with ESMTP; 19 Aug 2010 13:53:59 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id A70342B3F06; Thu, 19 Aug 2010 13:53:29 -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 HK-1l3m9vPuJ; Thu, 19 Aug 2010 13:53:29 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 5B89A2B3F03; Thu, 19 Aug 2010 13:53:29 -0500 (CDT) Date: Thu, 19 Aug 2010 13:53:59 -0500 (CDT) From: Mukul Goyal To: Dario Tedeschi Message-ID: <1545036230.731130.1282244039611.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <4C6D7BDD.7000807@exegin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL4_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL4_64) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] Question on path to grand children in non-storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 18:53:26 -0000 >Given the following simple linear DODAG operating in non-storing mode: >ER >[A]<---[B]<---[C]<---[D]<---[E] >Where [A] is the DODAG root. >If [C] wants to send a packet to [E], is it true that the path would be [C] to [B] to [A] to [B] to [C] to [D] to [E] ? This is true as far as I understand non-storing mode operation. The proposed P2P solution can help discover more direct route in this case. Thanks Mukul >Since, (in non-storing mode) the root node is the only node that stores >routes, I can't see any other way of [C] reaching [E]. Or, am I missing >something? >Dario _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From pal@cs.stanford.edu Thu Aug 19 12:03:37 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E19E93A68A5 for ; Thu, 19 Aug 2010 12:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.378 X-Spam-Level: X-Spam-Status: No, score=-6.378 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSnIifOMliPC for ; Thu, 19 Aug 2010 12:03:36 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 4A0853A6842 for ; Thu, 19 Aug 2010 12:03:36 -0700 (PDT) Received: from dn0a2101cb.sunet ([10.33.1.203]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OmAPK-0004jh-Gp; Thu, 19 Aug 2010 12:04:11 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Thu, 19 Aug 2010 12:04:10 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <419B39EB-F02D-45CC-8D26-6C0043736AE1@cs.stanford.edu> References: To: JP Vasseur X-Mailer: Apple Mail (2.1081) X-Scan-Signature: a4197552717df0bd80eeda27cbeae713 Cc: ROLL WG Subject: Re: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:03:38 -0000 On Aug 19, 2010, at 3:09 AM, JP Vasseur wrote: > Thanks Phil for the changes agreed on the mailing and incorporated in = Trickle -03. >=20 > There just a few things still to update before I can send the = publication request the IESG: > 1) Can you add a terminology section (define Trickle communication = rate, ...) =3D> See Yoav/JP comments on the list OK > 2) When listing a reference, add parenthesis. >=20 > Example >=20 > OLD: include RPL[I-D.ietf-roll-rpl] >=20 > NEW: include RPL ([I-D.ietf-roll-rpl]) Is this the standard RFC style? I see RFCs where this isn't done. Just = typing 3 random recent numbers, none of them use this style: http://tools.ietf.org/rfc/rfc4311.txt In the conceptual sending algorithm in [ND] and in the optional extension in [ROUTERSEL] http://tools.ietf.org/rfc/rfc4759.txt The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in RFC 4234 [2] to extend the syntax of the "par" production defined in the ABNF of RFC 3966 [5]. http://tools.ietf.org/rfc/rfc5050.txt Additional bundle protocol blocks of other types may follow the primary block to support extensions to the bundle protocol, such as the Bundle Security Protocol [BSP]. The reason I ask is that I'm used to [] indicating a citation; you'd put = the citation in parentheses only the act of citation was, well, = parenthetical. >=20 > 3) Several comments below have not been incorporated (see JP>) >=20 > Begin forwarded message: >=20 >> From: JP Vasseur >> Date: August 3, 2010 3:36:04 PM CEDT >> To: ROLL WG >> Subject: [Roll] Fwd: WG Last Call on draft-ietf-roll-trickle-02 >>=20 >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: JP Vasseur >>> Date: August 3, 2010 3:35:41 PM CEDT >>> To: JP Vasseur >>> Cc: ROLL WG >>> Subject: Re: [Roll] WG Last Call on draft-ietf-roll-trickle-02 >>>=20 >>> Please find below comments on draft-ietf-roll-trickle-02 (search for = JP>). >>> Co-chair hat on (shepherding the document) >>>=20 >>> Networking Working Group P. = Levis >>> Internet-Draft Stanford = University >>> Intended status: Informational T. = Clausen >>>=20 >>> JP> So far good consensus to move to Std track. Let's wait until >>> end of LC. >>> Expires: January 7, 2011 LIX, Ecole = Polytechnique >>> J. = Hui >>> Arch Rock = Corporation >>> O. = Gnawali >>> Stanford = University >>> = J. Ko >>> Johns Hopkins = University >>> July 6, = 2010 >>>=20 >>>=20 >>> The Trickle Algorithm >>> draft-ietf-roll-trickle-02 >>>=20 >>> Abstract >>>=20 >>> The Trickle algorithm allows wireless nodes to exchange = information >>>=20 >>>=20 >>> JP> Not restricted to wireless. Even if we do not use some features, = dynamic >>> timer adjustments are still useful in PLC/wired environments. >>> in a highly robust, energy efficient, simple, and scalable = manner. >>> Dynamically adjusting transmission windows allows Trickle to = spread >>> new information on the scale of link-layer transmission times = while >>> sending only a few messages per hour=20 >>>=20 >>> JP> I would suggest to be more generic (not specify "hour", "mn", = since=20 >>> that all depends on the parameter settings) >=20 > JP> Comment above Is this a comment, or a required edit? I say that because I think some = kind of mention of scale is useful here. The actual technical section = states things more generally, but if you have a strong concrete = statement, better to say it. A general statement, for example, might be = interpreted as seconds/minutes. >>> when information does not >>> change. A simple suppression mechanism and transmission point >>> selection allows Trickle's communication rate to scale >>> logarithmically with density. This document describes Trickle=20 >>>=20 >>> JP> s/trickle/the trickle algorithm > JP> Comment above OK. >>> and >>> considerations in its use. >>>=20 >>> Status of this Memo >>>=20 >>> This Internet-Draft is submitted to IETF in full conformance with = the >>> provisions of BCP 78 and BCP 79. >>>=20 >>> Internet-Drafts are working documents of the Internet Engineering >>> Task Force (IETF), its areas, and its working groups. Note that >>> other groups may also distribute working documents as Internet- >>> Drafts. >>>=20 >>> Internet-Drafts are draft documents valid for a maximum of six = months >>> and may be updated, replaced, or obsoleted by other documents at = any >>> time. It is inappropriate to use Internet-Drafts as reference >>> material or to cite them other than as "work in progress." >>>=20 >>> The list of current Internet-Drafts can be accessed at >>> =20 >>> http://www.ietf.org/ietf/1id-abstracts.txt >>> . >>>=20 >>> The list of Internet-Draft Shadow Directories can be accessed at >>> =20 >>> http://www.ietf.org/shadow.html >>> . >>>=20 >>>=20 >>>=20 >>> Levis, et al. Expires January 7, 2011 = [Page 1] >>> Internet-Draft draft-ietf-roll-trickle-02 July = 2010 >>>=20 >>>=20 >>> This Internet-Draft will expire on January 7, 2011. >>>=20 >>> Copyright Notice >>>=20 >>> Copyright (c) 2010 IETF Trust and the persons identified as the >>> document authors. All rights reserved. >>>=20 >>> This document is subject to BCP 78 and the IETF Trust's Legal >>> Provisions Relating to IETF Documents >>> ( >>> http://trustee.ietf.org/license-info >>> ) in effect on the date of >>> publication of this document. Please review these documents >>> carefully, as they describe your rights and restrictions with = respect >>> to this document. Code Components extracted from this document = must >>> include Simplified BSD License text as described in Section 4.e = of >>> the Trust Legal Provisions and are provided without warranty as >>> described in the BSD License. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Levis, et al. Expires January 7, 2011 = [Page 2] >>> Internet-Draft draft-ietf-roll-trickle-02 July = 2010 >>>=20 >>>=20 >>> Table of Contents >>>=20 >>> 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . = . 3 >>> 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . = . 3 >>> 3. Trickle Algorithm Overview . . . . . . . . . . . . . . . . . = . 3 >>> 4. Trickle Algorithm . . . . . . . . . . . . . . . . . . . . . . = . 4 >>> 4.1. Parameters and Variables . . . . . . . . . . . . . . . . = . 4 >>> 4.2. Algorithm Description . . . . . . . . . . . . . . . . . . = . 5 >>> 5. Using Trickle . . . . . . . . . . . . . . . . . . . . . . . . = . 5 >>> 6. Operational Considerations . . . . . . . . . . . . . . . . . = . 6 >>> 6.1. Mismatched redundancy constants . . . . . . . . . . . . . = . 6 >>> 6.2. Mismatched Imin . . . . . . . . . . . . . . . . . . . . . = . 6 >>> 6.3. Mismatched Imax . . . . . . . . . . . . . . . . . . . . . = . 7 >>> 6.4. Mismatched definitions . . . . . . . . . . . . . . . . . = . 7 >>> 6.5. Specifying the constant k . . . . . . . . . . . . . . . . = . 7 >>> 6.6. Relationship between k and Imin . . . . . . . . . . . . . = . 7 >>> 6.7. Tweaks and improvements to Trickle . . . . . . . . . . . = . 8 >>> 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . = . 8 >>> 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . = . 8 >>> 9. Security Considerations . . . . . . . . . . . . . . . . . . . = . 8 >>> 10. References . . . . . . . . . . . . . . . . . . . . . . . . . = . 8 >>> 10.1. Normative References . . . . . . . . . . . . . . . . . . = . 8 >>> 10.2. Informative References . . . . . . . . . . . . . . . . . = . 9 >>> Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . = . 9 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> Levis, et al. Expires January 7, 2011 = [Page 3] >>> Internet-Draft draft-ietf-roll-trickle-02 July = 2010 >>>=20 >>>=20 >>> 1. Introduction >>>=20 >>> The Trickle algorithm is designed for wireless networks. =20 >>>=20 >>> JP> please use the LLN terminology and point to = [I-D-ietf.roll-terminology] ID. >>> It >>> establishes a density-aware local broadcast with an underlying >>> consistency model that guides when a node communicates. When a >>> node's data does not agree=20 >>>=20 >>> JP> you may want to clarify the term "agree" >=20 > JP> Comment above (need to define the term "agree") This is a simple conceptual description (the introduction): later text = that actually presents the algorithm gives the technical definition. >>> with its neighbors, it communicates >>> quickly to resolve the inconsistency. =20 >>>=20 >>> JP> Please define "inconsistency" (an example should suffice) >=20 > JP> The first you use the term "inconsistency" can you point to = Section 6.8 Would it be more helpful to put this reference at the end of the second = paragraph? That's where it makes the point about what an inconsistency = is. >=20 >>> When nodes agree, they slow >>> their communication rate exponentially, such that nodes send at = most >>> a few packets per hour. =20 >>>=20 >>> JP> See comments on "hour" >>>=20 > JP> Same here=20 >=20 > This primitive allows Trickle to scale to thousand-fold variations = in > network density, quickly propagate updates, distribute transmission > load evenly, be robust to transient disconnections, handle network > repopulations, and impose a very low maintenance overhead: common > uses require on the order of a few packets per hour yet can respond > in milliseconds. >=20 > Avoid using a unit value (hour) unless it is clear that this is given = as an example. OK, I will cite CTP. > 4) Checking references for intended status: Proposed Standard > = --------------------------------------------------------------------------= -- >=20 > (See RFCs 3967 and 4897 for information about using normative = references > to lower-maturity documents in RFCs) >=20 > =3D=3D Outdated reference: A later version (-11) exists of > draft-ietf-roll-rpl-10 Roger. Phil= From alexandru.petrescu@gmail.com Thu Aug 19 12:39:00 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B5E553A659C for ; Thu, 19 Aug 2010 12:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[AWL=-0.964, BAYES_50=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gioxhH0swJsu for ; Thu, 19 Aug 2010 12:38:57 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id DCDC73A68D0 for ; Thu, 19 Aug 2010 12:37:58 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id D380E940135 for ; Thu, 19 Aug 2010 21:38:02 +0200 (CEST) Message-ID: <4C6D8816.9030502@gmail.com> Date: Thu, 19 Aug 2010 21:37:58 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: roll@ietf.org References: <004801cb3fab$d0231a30$70694e90$@com> <7F60EAC1-5A7D-481E-961D-F7728AB85726@cs.stanford.edu> <76DBCE2AA6605F42A49F1BD7454C841BF652F8@usatlsv105.am.bm.net> In-Reply-To: <76DBCE2AA6605F42A49F1BD7454C841BF652F8@usatlsv105.am.bm.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100819-0, 19/08/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] English usage in I-D's X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:39:00 -0000 (yet another non native English speaker here) I want to share my thought that I have similar feeling of too long text, often hard to read in draft-ietf-roll-rpl-11. Sometimes words are written but not needed: > o When mapping/transposing an IPv6 ND option for redistribution as a > RPL option "Transposing" appears only here, "mapping" would be sufficient. "Flag" (typically a 1-bit value) appears here but is wrong, DTSN being 8-bit: > Destination Advertisement Trigger Sequence Number (DTSN): 8-bit > unsigned integer set by the node issuing the DIO message. The > Destination Advertisement Trigger Sequence Number (DTSN) flag Use of "transcribed for convenience" is doubtful: > [RFC4861] and [RFC3775] should be consulted as the authoritative > reference with respect to the Prefix Information option. The field > descriptions are transcribed here for convenience: > > Option Type: 0x08 (to be confirmed by IANA) But RFC4861 says that field is 3, not 0x08 - who is right? (besides, in that paragraph, "rfc4861" is not clickable whereas rfc3775 is - I guess this is an error in the xml source text). > RPL supports two > modes of downward traffic: storing (fully stateful) or non-storing > (fully source routed). "fully stateful" reads unnecessarily stressing the word "full", could have been better as "entirely stateful". > 17.2.1. Initialization Mode > > > "Architectural Principles of the Internet" [RFC1958], Section 3.8, > states: "Avoid options and parameters whenever possible. Any options > and parameters should be configured or negotiated dynamically rather > than manually. This is especially true in LLNs where the number of Missing ending double quote? > In both cases, P2P packets travel Up toward a DODAG > Root then Down to the final destination (unless the destination is on > the upward route). Does that "unless" mean that if the destination is on the upward route then the packets travel first downward and then upward? Or does it mean there is no downward travelling if the destination were on the upward route? I guess the latter, but it would be better to clarify. There are many details like this, I noted some here and there. Alex Le 19/08/2010 20:11, Monnerie, Emmanuel a écrit : > I don't know what the French culture has to do with it. I'm French and I > do believe that fewer words are better, particularly when it comes to > engineering documentation. If we were writing an essay or a piece of > literature, I would argue the opposite. > > So I agree with Colin: many sentences are overly complicated. > > Furthermore, the text is repeating several times similar statements, > which causes even more confusion. For example, look how many times the > word "RPLInstanceID" is defined throughout the text. > > Best Regards > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of > Philip Levis > Sent: Thursday, August 19, 2010 12:58 PM > To: Colin O'Flynn > Cc: roll@ietf.org > Subject: Re: [Roll] English usage in I-D's > >> 4.1 - OF (from section 3.7, RPL) >> >>> The Objective Function itself is decoupled from the routing > metrics >>> and constraints used by RPL. Indeed, whereas the OF dictates > rules >>> such as DODAG parents selection, load balancing and so on, the > set of >>> metrics and/or constraints used, and thus determine the > preferred >>> path, are based on the information carried within the DAG > container >>> option in DIO messages. >> >> Amazingly there is two sentences in there; the first one makes sense > but is a little complicated, the second one has five commas and seems to > be written by two different people about half-way through. > > Colin -- we have had this discussion on the list already. It's partially > a cultural difference. The notion that fewer words is better originated > in American writing in the 19th century. The same metric does not hold > in all languages or all readers/writers of English. As one example, > Pascal, JP and I debated it a lot: I always thought fewer words is > better, while their opinion, coming from French, was that more text > typically adds greater larit. > > > > Emmanuel Monnerie > Senior Research Engineer > Landis+Gyr > Energy Management Solutions > Office: +1 678 258 1695 > Fax: +1 678 258 1316 > Emmanuel.Monnerie@landisgyr.com > www.landisgyr.com > manage energy better > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From root@core3.amsl.com Thu Aug 19 12:45:02 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 204BD3A680D; Thu, 19 Aug 2010 12:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100819194502.204BD3A680D@core3.amsl.com> Date: Thu, 19 Aug 2010 12:45:02 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-trickle-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : The Trickle Algorithm Author(s) : P. Levis, et al. Filename : draft-ietf-roll-trickle-04.txt Pages : 13 Date : 2010-08-19 The Trickle algorithm allows nodes in a lossy shared medium (e.g., low power and lossy networks) to exchange information in a highly robust, energy efficient, simple, and scalable manner. Dynamically adjusting transmission windows allows Trickle to spread new information on the scale of link-layer transmission times while sending only a few messages per hour when information does not change. A simple suppression mechanism and transmission point selection allows Trickle's communication rate to scale logarithmically with density. This document describes the Trickle algorithm and considerations in its use. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-trickle-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-trickle-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-19123932.I-D@ietf.org> --NextPart-- From L.Wood@surrey.ac.uk Thu Aug 19 12:51:50 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B68F3A6993 for ; Thu, 19 Aug 2010 12:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_50=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d+tZLEPP9pvU for ; Thu, 19 Aug 2010 12:51:46 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 8F2553A69E1 for ; Thu, 19 Aug 2010 12:51:45 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-11.tower-82.messagelabs.com!1282247539!15093441!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 29766 invoked from network); 19 Aug 2010 19:52:19 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-11.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 19 Aug 2010 19:52:19 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.14]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Thu, 19 Aug 2010 20:52:19 +0100 From: To: Date: Thu, 19 Aug 2010 20:52:18 +0100 Thread-Topic: [Roll] English usage in I-D's Thread-Index: Acs/2AhFuNeW/YudQCO+OiIx5/OtDQ== Message-ID: References: <004801cb3fab$d0231a30$70694e90$@com> <7F60EAC1-5A7D-481E-961D-F7728AB85726@cs.stanford.edu> In-Reply-To: <7F60EAC1-5A7D-481E-961D-F7728AB85726@cs.stanford.edu> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: roll@ietf.org Subject: Re: [Roll] English usage in I-D's X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:51:50 -0000 On 19 Aug 2010, at 17:58, Philip Levis wrote: > Colin -- we have had this discussion on the list already. It's partially = a cultural difference. The notion that fewer words is better originated in = American writing in the 19th century. It did not. "I would have written a shorter letter, but I did not have the time.", Blai= se Pascal, Provincial Letters: Letter XVI, 17th century. "less is more" is pithy, but came later (Robert Browning, Andrea del Sarto,= 1855. Again, not America.) One can also make the case for stonemasons desiring brevity, and thus for t= he ten commandments. > The same metric does not hold in all languages or all readers/writers of = English. As one example, Pascal, JP and I debated it a lot: I always though= t fewer words is better, while their opinion, coming from French, was that = more text typically adds greater larit. What is "larit"? I suspect you've completely undermined your own argument h= ere. Last I checked, the IETF was predominantly American culture. (Wasn't OSI Fr= ench?) I didn't bother reading ROLL drafts - they make little sense. Instead, I st= arted with the terminology draft as a primer. Comments on that below. http://tools.ietf.org/html/draft-ietf-roll-terminology should say Terminology specific to a particular application *IS* out of the scope of this document. For example, an actuator might control and/or *MODULATE* the flow=20 Controller: A field device that can receive sensor input and automatically change the environment in the facility -- what is the facility? Field Device: A field *DEVICE* is a physical device placed in the network's operating environment (e.g. plant, urban or home). =20 Field devices include sensors, actuators as well as routers and Low power and Lossy Network Border Router (including LBR).=20 -- ugh. LBR is defined later. Rewrite. HVAC: Heating, Ventilation and Air Conditioning. A term applied to the comfort level of an internal space. -- The HVAC industry may disagree with that definition. The LBR acts as a routing device and may possibly host other functions such as data collector or aggregator. -- "may possibly" is perhaps slightly redundant and repetitive, in that it says the same thing more than once? That is, twice? Open Loop Control: A process whereby a plant operator manually manipulates an actuator over the network where the decision is influenced by information sensed by field devices. -- that is not open-loop control. The key point about open loop is that there is no feedback. See any control theory textbook. PER: Packet Error Rate. A ratio of the number of unusable packets (not received at all, or received in error- even after any applicable error correction has been applied) to the total number of packets that would have been been received in the absence of errors. -- No. A rate (X per second) is not a ratio (X/total). Learn the difference= . (Admittedly, a lot of IEEE authors writing papers are unclear on this difference. And PERs are generally useless to engineers unless packets are all the same length. I blame the network simulator ns for introducin= g this concept widely.) Sensed data can be of many types: electromagnetic (e.g. current, voltage, power, resistance, ...) , mechanical (e.g. pressure, flow, liquid density, humidity, ...), chemical (e.g. oxygen, carbon monoxide, ...), acoustic (e.g. noise, ultrasound), ... -- humidity sensors are generally capacitative, and therefore electrical. A= lso often the case for liquid density. Smart Grid: A Smart Grid is a broad class of applications to network and automate utility infrastructure. -- just an application? Really??? Timeslot: A Timeslot is a fixed time interval that may be used for the transmission or reception of a packet between two field devices. A timeslot used for communications is associated with a slotted-link -- sentence incomplete. I read the abstract of the ROLL rpl draft: Low power and Lossy Networks (LLNs) are a class of network in which both the routers and their interconnect are constrained: LLN routers typically operate with constraints on (any subset of) processing power, memory and energy (battery), and their interconnects are characterized by (any subset of) high loss rates, low data rates and instability.=20 That's three separate sentences joined together for no good reason. I did not read further. Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From samitac@ipinfusion.com Thu Aug 19 12:59:57 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5274C3A69E7 for ; Thu, 19 Aug 2010 12:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.887 X-Spam-Level: X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eie7GznGl-6e for ; Thu, 19 Aug 2010 12:59:56 -0700 (PDT) Received: from smtp128.sbc.mail.sp1.yahoo.com (smtp128.sbc.mail.sp1.yahoo.com [69.147.65.187]) by core3.amsl.com (Postfix) with SMTP id 3832B3A693E for ; Thu, 19 Aug 2010 12:59:56 -0700 (PDT) Received: (qmail 20751 invoked from network); 19 Aug 2010 20:00:28 -0000 Received: from samitacD630 (samitac@65.223.109.250 with login) by smtp128.sbc.mail.sp1.yahoo.com with SMTP; 19 Aug 2010 13:00:28 -0700 PDT X-Yahoo-SMTP: 2TubM6mswBDzS84mnP14_Gq9MWTFqPrD9YAsl.JSPFAWkA-- X-YMail-OSG: v._RNVUVM1kgiELzLV.U52vXCqnVrY0vWNG53NeYHPOztJU DoO69oT0nu_iTlU0feGGxr6bSv5PgzxOZ3f1pAC092Jjyu1tC9xt3WYvw5fo Fw6jNX6WmRblI8lCCh0OVSdUimYL4a24CF_F.0W5Qe6ObX1caACulA9_sNB0 NZn_lEI_0S8gk0F3xZ1wNs4O5mTyKouEvXwgdJ4OAMVyIycZRfvbm9Srlqpt kApILjzBS_qqYO8JNL4fH1BSo9SfdH8tA3JbKjFDvKaeKZOFbwUU3_0jfna8 5dUhJCZWt_D7_gFxhX_oG X-Yahoo-Newman-Property: ymail-3 From: "Samita Chakrabarti" To: "'ROLL WG'" References: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> <6D9687E95918C04A8B30A7D6DA805A3E01CCD2D7@zensys17.zensys.local> In-Reply-To: Date: Thu, 19 Aug 2010 13:00:27 -0700 Message-ID: <00c601cb3fd9$2b79d950$826d8bf0$@com> MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_NextPart_000_00C7_01CB3F9E.7F1B0150" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs/cZL7i+JNAiECQQiGXg6a0gKrJwAZnchQ Content-Language: en-us Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 19:59:57 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00C7_01CB3F9E.7F1B0150 Content-Type: multipart/alternative; boundary="----=_NextPart_001_00C8_01CB3F9E.7F1B0150" ------=_NextPart_001_00C8_01CB3F9E.7F1B0150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Mukul, JP, I support this document as well toward a wg document. One interesting observation: One can understand the basic RPL operation from this draft much better than the actual RPL draft. The unnecessary long text in RPL-draft is indeed an issue to any readers anywhere in the world. Regards, -Samita From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Emmanuel Baccelli Sent: Thursday, August 19, 2010 12:40 AM To: ROLL WG Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document ? +1 too. On Thu, Aug 19, 2010 at 9:35 AM, Anders Brandt wrote: +1 _____ From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com Sent: Wednesday, August 18, 2010 21:48 To: JP Vasseur Cc: ROLL WG; roll-bounces@ietf.org Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document ? Yes. I would like the P2P draft promoted to a WG document. BTW. Mukul's 'Measurement' draft is really an excerpt from the original P2P draft. It was extracted as a separate document at the request of reviewers. I think it would be beneficial to reviewers if both documents were promoted to WG level simultaneously since they complement each other. Jerry From: JP Vasseur To: ROLL WG Date: 08/18/2010 02:30 PM Subject: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? _____ Dear all, draft-dt-roll-p2p-rpl-02.txt has been presented several times and discussed on the mailing list. Could you let us know whether or not you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a ROLL Working Group document (feel free to justify) ? Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ------=_NextPart_001_00C8_01CB3F9E.7F1B0150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mukul, JP,

 =

I support this document as well toward a wg = document.

 =

One interesting observation: One can understand the basic RPL operation from = this draft much better than the actual RPL draft.  The unnecessary long = text in RPL-draft is indeed an issue to any readers anywhere in the = world.

 =

Regards,

-Samita

 =

From:= roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of = Emmanuel Baccelli
Sent: Thursday, August 19, 2010 12:40 AM
To: ROLL WG
Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document ?

 

+1 = too.

On Thu, Aug 19, 2010 at 9:35 AM, Anders Brandt = <abr@sdesigns.dk> = wrote:

+1

=

 

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jerald.P.Martocci@jci.com
Sent: Wednesday, August 18, 2010 21:48
To: JP Vasseur
Cc: ROLL WG; roll-bounces@ietf.org
Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as WorkingGroup document ?


Yes. =  I would like the P2P draft promoted to a WG document.  

BTW.  Mukul's 'Measurement' draft is really an excerpt from the original = P2P draft.  It was extracted as a separate document at the request of reviewers.  I think it would be beneficial to reviewers if both = documents were promoted to WG level simultaneously since they complement each = other.

Jerry =




From:

JP Vasseur <jpv@cisco.com>

To:

ROLL WG <roll@ietf.org>

Date:

08/18/2010 02:30 PM

Subject:

[Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group   =      document ?

 




Dear all,

draft-dt-roll-p2p-rpl-02.txt has been presented several times and =  
discussed on the mailing list. Could you let us know whether or not =  
you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a =  
ROLL Working Group document (feel free to justify) ?

Thanks.

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


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

 

------=_NextPart_001_00C8_01CB3F9E.7F1B0150-- ------=_NextPart_000_00C7_01CB3F9E.7F1B0150 Content-Type: image/jpeg; name="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAQEASABIAAD/2wBDAAgGBgcGBQgHBwcJCQgKDBQNDAsLDBkSEw8UHRofHh0a HBwgJC4nICIsIxwcKDcpLDAxNDQ0Hyc5PTgyPC4zNDL/2wBDAQkJCQwLDBgNDRgyIRwhMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjL/wAARCABZAn4DASIA AhEBAxEB/8QAHwAAAQUBAQEBAQEAAAAAAAAAAAECAwQFBgcICQoL/8QAtRAAAgEDAwIEAwUFBAQA AAF9AQIDAAQRBRIhMUEGE1FhByJxFDKBkaEII0KxwRVS0fAkM2JyggkKFhcYGRolJicoKSo0NTY3 ODk6Q0RFRkdISUpTVFVWV1hZWmNkZWZnaGlqc3R1dnd4eXqDhIWGh4iJipKTlJWWl5iZmqKjpKWm p6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uHi4+Tl5ufo6erx8vP09fb3+Pn6/8QAHwEA AwEBAQEBAQEBAQAAAAAAAAECAwQFBgcICQoL/8QAtREAAgECBAQDBAcFBAQAAQJ3AAECAxEEBSEx BhJBUQdhcRMiMoEIFEKRobHBCSMzUvAVYnLRChYkNOEl8RcYGRomJygpKjU2Nzg5OkNERUZHSElK U1RVVldYWVpjZGVmZ2hpanN0dXZ3eHl6goOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3 uLm6wsPExcbHyMnK0tPU1dbX2Nna4uPk5ebn6Onq8vP09fb3+Pn6/9oADAMBAAIRAxEAPwD0HVNT 8WxalcpaR3ZgWVhGVtAw25OOdvPFVF1fxqesV7/4BD/4mvSaK7FioJW9mjyZ5bVlJyVeS+Z5z/a3 jP8A55Xn/gEP/iaP7W8Z/wDPO8/8Ah/8TXo1FP61D/n2hf2ZV/5/y+885/tbxn/zzvP/AACH/wAT R/a3jP8A553n/gEP/ia9Goo+tQ/59oP7Mq/8/wCX3nnP9reM/wDnnef+AQ/+Jo/tbxn/AM87z/wC H/xNejUUfWof8+0H9mVf+f8AL7zzn+1vGf8AzzvP/AIf/E0f2t4z/wCeV5/4BD/4mvRqKPrUP+fa H/ZlX/n/AC+884/tbxnn/V3n/gEP/iaP7X8Z/wDPK9/8Ah/8TXo9FL61D/n2h/2dV/5/y+883/tj xp/zxvf/AACH/wATSf2x40/54Xv/AIAj/wCJr0mij61D/n2h/wBn1f8An9I82/tnxr/zwvP/AACH /wATSf2z41/54Xv/AIBD/wCJr0qij61D/n2h/wBn1f8An9I81/trxr/z73v/AIAj/wCJpP7a8bf8 +97/AOAI/wDia9Loo+tQ/wCfaD6hU/5/SPM/7a8b/wDPve/+AI/+Jpv9teOP+eF9/wCAI/8AiK9O oo+tQ/59of1Cp/z+keYf2145/wCeF9/4Aj/4ij+2vHP/ADwvv/AEf/EV6fRR9ah/z7Q/qNX/AJ/S PLzrfjr/AJ4X3/gCP/iKP7b8df8APC+/8AR/8RXqFFH1qH/PtD+pVP8An7I8u/tvx1/zwvv/AAAH /wARR/bnjr/n2vv/AAAH/wARXqNFL6zD/n2h/U6n/P1nl39u+Ov+fa+/8AB/8TR/bvjr/n2vv/AA f/EV6jRR9Zh/z7Q/qlT/AJ+s8t/t7x1/z633/gB/9hSHXvHf/Prff+AH/wBhXqdFH1mH/PtD+qT/ AOfjPK/7f8dj/l0vv/AD/wCxpD4g8ef8+d//AOAH/wBhXqtFH1mH/PtD+qz/AOfjPKT4h8ej/lyv z/3D/wD7GkPiLx7/AM+N/wD+C/8A+xr1eij6zH+RD+rT/wCfjPJz4i8ff8+V/wD+C/8A+wpP+Ei8 f/8APlf/APgv/wDsK9Zoo+sx/kQfVpfzs8m/4SPx+P8Alxv/APwX/wD2FJ/wkvj/AP58NQ/8F/8A 9jXrVFL6xH+RD+rz/nZ5J/wk3xA/6B+of+C//wCxo/4Sf4gf9A3UP/Bef/ia9bop/WYfyIfsJfzs 8j/4Sjx//wBA3UP/AAXH/wCIpP8AhKfiB/0C9Q/8F5/+Ir12ij6zD+RD9jL+dnkX/CVfED/oF6h/ 4Lz/APEUn/CVfED/AKBeo/8AgvP/AMRXr1FH1mH8iH7GX8zPIf8AhKviB/0C9R/8Fx/+IpV8U/EA jnTNQ/8ABcf/AIivXaKX1iH8iD2Mv5meSL4o8fnOdN1D/wAF5/8AiKcviXx8T/yDtQA/7B//ANjX rNFH1iH8iIeHk/ts8nHiTx8WwdPv/wDwA/8AsaePEXjzP/Hjf/8AgB/9jXqtFL28f5ET9Vn/AM/G eWf8JB47z/x5X3/gB/8AY07+3/HX/Pnff+AP/wBjXqNFHt4/yIn6pU/5+s8wOu+Of+fS+/8AAEf/ ABNKNc8cY/49b3/wBH/xNenUUvbx/kQvqdT/AJ+yPMxrfjfH/Hre/wDgEP8A4ml/trxv/wA+15/4 BD/4mvS6KTrR/lQvqVT/AJ+yPNRrXjX/AJ973/wCH/xNKNZ8a/8APvef+AQ/+Jr0mipdRfyoPqVT /n7I83/tnxp/z73n/gEP/iaX+2PGn/PC8/8AAIf/ABNej0Uuddg+pVP+fsjzj+2PGf8AzwvP/AIf /E0v9seM/wDnhef+AQ/+Jr0ailzLsP6lU/5+yPOv7X8Zf88Lv/wDH/xNH9r+Mv8Anhd/+AY/+Jr0 WipbD6nP/n7I87/tbxl/zxu//AMf/E0f2t4x/wCeN3/4Bj/4mvRKKmzK+qT/AOfjPPBq3jD/AJ43 f/gGP/iaX+1vGH/PG7/8Ax/8TXoVFTyvuP6rP/n4zz3+1vGH/PG7/wDAMf8AxNH9reMP+eN3/wCA Y/8Aia9CoqXTb6j+rS/5+M8+/tXxf/zyu/8AwDH/AMTR/avi/wD55Xf/AIBj/wCJr0Gip9i/5mP6 tL+dnn39q+L/APnld/8AgGP/AImj+1fF/wDzyu//AADH/wATXoNFS8PL+djVCX87PPv7V8X/APPK 7/8AAMf/ABNH9q+L/wDnld/+AY/+Jr0GioeFm/8Al4yvYy/mZ59/avi//nld/wDgGP8A4mj+1fF/ /PK7/wDAMf8AxNeg0VP1Sf8Az8Y/ZS/mZ59/avi//nld/wDgGP8A4muh8MXer3X2r+1UmXbs8vzI fL9c44Ge1dBRV0sNKE1J1G/IqMGndyuFFFFdZoFFFFABRRRQAUUUUAFFFFABRRUU9zFbKjSttDuE X3J6CmlfRCbSV2S0Vzc3itI2jxb4U6p/ZzFm6f7Ypuk+Mba/ubqxkjIv7e7e2aCIFjhT972GD39D WnsKlr2MnXppXbOmooyM4orI2CiiigAoqrdaja2VxZwXEuyW8lMMC7Sd7hWcjgcfKrHn0q1QAUUV R1fV7HQtNl1HUZmitYyoZ1jZzliFACqCTkkDgUDSvoi9RWXceI9JtZdMilvAH1MgWgVGbzM454Bw PmHJwORWpQTdBRUQuYDdNaiaM3CoJDFuG8KSQGx1xkEZ9jUtAwoqtqF3/Z+nXN59nuLnyI2k8m2T fJJgZ2qvdj2FWFO5Q2CMjOD1FAC0UUUAFFFFABRRRQAUUUjMEUsxwAMmgBaKraff22qadbX9nJ5t rcxrLE+0ruVhkHBwRx603T9TtNVt3nspvNiSaSBm2lcOjFGHIHRgRnpTas7MC3RRRSAKKKzZ9e06 31RdNeWQ3JxuEcEjpHn7vmOqlY89txGe1AGlRRUT3MEdxHbvNGs8oZo4ywDOFxkgdTjIz9RQBLRR VS01O0vrq9trabfLZSiG4XaRscqrgZI5+VlPGetAFuiiq1jqFrqUMktpL5iRyvCx2kYdGKsOR2II oAs0UUUAFFFFABRRRQAUUUUAFFYNj4oW7jZ5dJ1CyzAbiAXJhAnQYyVZZGUYyvDlev1xoTazpdtJ cRz6lZxPbR+bOsk6qYk/vMCflHuaHpuHWxeoqhLrekwQWk8uqWUcN4VW1ke4QLOW6BDn5ie2M0zT /EGj6qhax1O1nAuGtTslGfNXOUx64Un3AyOOaPIDSooooAKKjuJ47a3eaUkIgycDJPsB3J9KzYte iltdNnFndqL4jClF/c54+cg7RyQMAknORkAkHWwGtRVF9VhXWYtMEcrSPG0hkUDYmMfKTnO4g5wA eBzjIyyHVXm1e5sV028EVvw14TF5RbarbQN+/OGH8OPelcDRorKtNdjuEuzcWV3ZPbbWaK4CFmVs 7WXYzdSCADhsjkDip7XVYbnRotTaOWGN4xJ5cgBdc/wkKSC2eMAnJ6ZpvQFrsXqKwZvFMUWnWt6u mahKk0PnypGsZa2jH3mf58HHohYnBwDVtdbtyl85guVSz6lo8GUc8oOp5BAyBnqMgglX0ugNOiqG lan/AGnFKWs7mznhk8uW3uQm9DgMOUZlIIIOQx646ggX6YBRRRQAUUUUAFFFFABRRRQAUUVQ1rWL XQdIuNTvS4t4AC+xcnkgdPxppNuyBu2rL9FQ2l1He2cN1Dny5kEiZHOCMisvXvEUehXWlwSW7ynU LkW6lWxsJ7n1pxhKT5VuJtJXZtUUUVIwooooAKKKKAIridLW2lnlOEjUsx9hXCS6rLeX2kJM2JLi 5N6yn+CFM7f03V1+uvax6Lcvesy2yqGk29SARx+PT8a8t1O+lh0y/wBeuVMVxqKm1sYcYKxdCwH+ 7x+Nehg6alFvrt/X5v0PHzGpJVYxvolf8dW/yXqylqGqNJ4cspgxzc680gYdwNuD+RqfRtWurT4j eKtM02NPtN5dkrKwyU+Y7vw5rMvrV/7a8LeG+BJDslnH92SRt3P0XbUngq+W4+IPivWVHMcU0sfs xfA/rXViUlQnLpZv8dPyIpqTha9np+Wp6vplzBZXq6RaeZd3AG+6uGbOD3yfX2roa8106+l03wzc XkL/AOmXdwU345GME/zFei2pJtISxySi5/KvmcNifaycHurP79kenhneCJaKKK7DoOa8Q2Ooal4g 0JbW0kWCznkuZbwugRcwyxhQN28tlwfu4x37Vwun+A9Uj8OS2slhqX9oyzWH2wzS2iwz+XOrSSIY iHY43EtL85BHU16u91s1GG02Z82J5N2em0qMY9936VVTXbGSW7iQ3LPaqWcC0l+cDr5Z2/vcdDs3 YJA6mnd6f1sDV9DgNW8Iw6XY+LNaOnWtrJY3Ed/pMwCARpBBEdq4/wBWpMbIRxkdiMVrx6Hf3fw6 s4Psg+33d3BqFzCWHys9ys0gJY87QSPw49K19R8aaZZaLJqEa3UrCKV0ga0mR8xjJDgpmIZwNzgD ketW9U1t9P1DT7VYISLtsGSecxDt8iHaQ0hzkISuQCQeDRZ2s/6t/SD4feXn/Xyv+Jx2m+Edbtrm AXEIaDTtRhgsFWVSFsY2dw/J4b51UjqfKHFZF74S8S3N/wCIpI9HaKS+0/UIGeP7JFFcO7jyNpTE jEqMlpTwScYzXoUPi7TZtOmv/I1NYYbmS2f/AIls7NuQkEhVQkr8p+boOhwcisq48fBfEB0q10ye bddxWsc5iuAjMyeYx3LCygBcY+Yk9SFX5qST2W/+aS/4Pqx8rTb/AK0b/wA7GRqPgaS31C/k0TRb e2uLvRDbQ3sIjjaG5+fczNkPuYMo3qGJxyarf8IneG6W4i8KfZ9CFzC03h8G2HnlYpFaQqH8o/O8 RwzZPlZxkCuwbxXFF4i1DTp5NLit7GLzZS1//pIQIrF/I2fc+bG7dVl/Fekx2BvC14YxKYWjWwna VWC7uYgm8DbzkrjBB6EU07K/9b3Fyv8Ar0X6HH6t4X1K5tvFkQ0Q3F9qFpIllfG4Q7Izbqgt9zMH /wBYGOCAnO7OeK9FtUaO0hRxhlRQR74rMk8R2NvbG4uGkEbSiOFYYJZZZCYw+PLCbt2MnABwB9QJ hr+mme0iSaST7WivFJHA7R4b7u6QLtTPbcRntmh329P1FvqaVFZZ8Q6Ypvd80ka2aNJM8lvIiFV+ 8UYrhwO+0nHer1rcx3lrHcRLKqSDIEsTRt+KsAR+IpeYyaiiigAooooAKqanLNBptxJb2c15KEws ELIrOTxwXZV9+SKt1U1S9/s7Sby+2q32aB5drvsU7VJwWwcDjrg4pSV1qON7qx5jJ4L1qPTrKzl0 lby6TR7S0srwSRFdLuELeZIN7Bh1Q7owSdmOwqK/8CaydFvPsmlRjUbo6uksivGryRzNI0Kls8gk qQM8Hriu7tvEV5faRa3GnwaTe3ly7hFttTMlttX7x84RZPYYCdTj3pX17VH/ALLntdMs2s78xD9/ fGOdS2SwCCNlbaoJ++M7TVSbm33/AM9f6/ElLT0/Q43XfBeot9vXT9GjkjM9vdW8Hl28kEs4jZZG mjkYAg5wzAh84Izirl74Y1WfxLcT/wBkq93JfwXEGsB48W9ssaB4BlvMXJWQbVXafMyT1rqrzxC1 t4rtdEX+zAZolk/0i/8AKnYEsD5UWw+ZgJk/MOtW9Z1U6THayeQJY5ZxHKxfb5abWZn6HOAvTj60 lf8Ar+v69B2suXscr4G8MX+gTaW89glsf7EigvmRkJe4QgDcVOWIXIB5AHGa0LSz1bSfEWupFp0l xb6tcLcxXscsarAfKSMrIGYPkFMjarZ3DpzWrJrbLq8lktvGYk8tfOaUjLsyhlwFPQOuDnBJIOMZ ptx4nsIY7h0FxIttMkUj/ZpQhLPs/dttxIQeMJk5460br1v+LuJKzaW+n5WPOYvBWttZWUUOhfYp oUs01F/OhzqMyXMTvPuViWwqSHL4Y+ZjGa1bbwZNZ+I7S5/4R+3eytru8W2SNYR9njkEZjdQSNqh hJwvzAt05Ndsmv2csC3cb5tPIkmZjHIJV2MFZfL25yCSCDhgRjae0KeK9LeGGbbqKxyymEM+mXK7 GBAO/MfyDkctgdeeDQ03p6/i/wDgWDZ3/rb/ACZwUHgm6sfD3h6G58MJqYh0ySK8sQ8JK3jLGFmb ewViAjLuBJUEAcVFceCfEA0a+iuLMajfi+t54S4gmhuGS0jiZpUlYZQsrgkEOOCAa9Ls9e06/v5b K2mdp492d0LqrbW2ttYgK+1uDtJwSM4rJbxnDbRX097aOsVtdJbCO13z3Cl32AyQhAyZPIxuDLgg nIBd3f1/z/z/AK0Go2srbf5G1p11dXEl1HcWX2eOCQRxSbjiYbQWYKQMAMSo6525rz6XwVqN5dsL zS4p7Yxav8krRspeadJIDgnqdu4HsRzg129x4n0u2nnhZruSWAqsiQWM8pDEBgo2IcnBBIHIBycC pZ9f063mhiaSZzMm9Ght5JEwemXVSqk9gSCx4GTUSV9X2t96KTsuX0f3HJ6BpWs6RdX19e6E9/qx t0eC8a5jBKrAi/Zt5YsMyKxxjZ827OeK7yJneFGkTy3Kgsmc7T3Ge9U9F1e317R7bU7SO4SC4QOi 3ELROAfVWH6jIPUEjmr9aSbb1IUeVWCiiipGFFFFABQeRRQehpPYDm7Tw5f/AGIW+o6nbz+VbNbW 5t7QwhFYAEsDI+5vlHQqOTx6WNT8Oi/0/UII7k28t1cLcLLGXQq6qgGTG6MfuDoynHGax4Na1J9B ht2vSdTRFuJZ9ibmhwGDbdu0ZJEfQdGI5FXbnxHfC1vpBZxRReRO9nLHcCSRzEcNvQqFTnp8ze+O lU97P+v6+8L62JbHw9fabFpws9QtxLArpctPBLN5yu+9tpeYurE92dx7HAxe03TbrTRLEt3C8D3k twFMBDBJCzlc78E72yGx04xn5qqW2r3k86wXUMVtcxXLRSx21wJkP7kyLlmjU9CDjA5xyR1pr4rn i1DSrA6fcXPnwQvcXEcEzbDIMAjZEY8ZyTudMDnmjVv+uuor20/rTT9Tq6KjiMrKfOREbcwARywK 54PIHJGCR2PGT1qSkMp6npdrq9qLa78/yw4cGC4khcMOhDRsrD86xh4b1Cy0XT9N0nVIYltZPMeS +glumkIbcMEzKQM56k+2MVqa3qR0vTWnWG4lYsEHkW0k5Qn+IpGCxA68CsfS9Svb/QNEvkvp8NIq XHn2nlSTktt5DKu0dT8qjJxggZBlW5lbf/hv+AD217MuDwrZJ4hi1mOa8SZWkd4/tk5jdmAGfLL7 B06bcdPSmr4df/hK31tjpiNtIV4bDZct8u3bJNvO9e+3aOi88c1j4hkfxtBpuNQih2yxeW2nyiOV gFO/zSm3HUDDY65ySMTR3GoReMJo7uTU1sZvktBi2Nqx8sEjj99vyHPPy8fSiNun9aD7jbTw1dz2 U1tr+oRXu+VZhNYxzWUu8d2dZiT2wBtAx09J7fwrYxeHrfRppr2WGBg6yC9mSTcCSD5gfeOvTdis 2DVtR0q11Fb19VupEkQQie0SeeNWJG8rargx/KSBjdwc4yMTWGqXOo+D9NmS9uop7p0ge8lthFKp JwW2OgUE4wPlxkjgijS6S8v0/wCAJvdvzFj8JTWenW1jYakUiELW9y1yj3DyxscnazSZVhk4JLAZ +7Vk6JqctzqPn6lZm1uIwkEcdkyyQlTlGLGVg+O/yjPHSora41M2Vkz6iZBDetbyuYVDXKiQopYj gcZJ2gZbGNoypraRqGpz61eQz38o89J2s1mhjaAhHCho9gV8AMoYSHJP3Tt+aqjHTlW2v+YPe39d v0N3SrG5s45pL25iuLyeTfLJDCYk4AUBULMRwB1Y85+g0Ko6PJNJpcRuJmnlBZGlcKC+GIyQoAzx 2Aq9QAUUUUAFFFFABRRRQAUUUUAFch8UP+Scaz/1zX/0Na6+ub8U+FG8VGC3uNTuINNXme1hAAn5 yMnqBWtBqNRSk7JETTcWkcDp0UnivxMuh6nqV1ZWGn6VbyQQwy+WZGKKS59cZrINzea/oui2F9fT yrDrrWsV4r/vCmB0PqPX3r1nV/BWga21u17Y7pIEESSRyMjbMY2kqRkfWsHUtQ+HmhPY6TdTQQtp snmwxRCRvJf1Yrnn/erup4hStyxbfa23n8zCVNrdnM3f2zwvqXjDSdP1S++zQaUt3CZJdzRyEjJB p1rZTeH7vwVqVnqd+8uryxpdpNNvRwwGePxr0Q6BoGufaNUEC3A1O1EMkqyMBLF1A4PH1HNWJfDW kzx6aklrldMIa0HmMPLIAA789B1zWf1qNrNev3W/Mr2T6fL7zzTTJLnw54yH/CRG/l1G5kmayuku t9vOMHahQcjB/XFZe65uvAV343l8QXia5HcEqgmwiYcDytn07V6ZD4N8LaFef201uI5ICXE1xcMy xZPJG44HNIPAPhS6vl1RdOjcyOJwFkbymbs23O0/lV/Wqd+bXp07dN9EyfZS2/r1OMt7afxp4vv4 dUvr+CODTLe5jggn2LHIyDPH15rrfhnfXd/4Lhe9uHuJYppIhI/LFVbAzXQRaHp0GrXWqR2+28uo 1imk3H5lUYAxnA/Cs2e40XwHpdvDHbyxWs90I0SPLnzHPU7j0rGdVVY+ziu1vu1NIw5HzN9zengi uYHhmjWSNhgow4NeW6jZXEWqXPifxWqQWVg2yzsgf9YR91VHpnB969WrC8ReEtK8UfZv7SSRvs7b l2SFcjuDUYesqbs9n9/y9SMTQ9qk1uvu+foeOWFxcRWWtePNS+WVw8Nkp/jmkGMj2UE034T2+y5u vtQZItTia2SRh19we/zcV1XjLwF4j8T63ZWUP2O08PWvyQrE/Ma92K45b0rpdN8Ftb6SNGuHT7Na HNlcxn94nOcEfXmuvE1oToOKavLp2XY4Z0asbRgr+fd9b+u1ytoelG8tJNLuPknsrsSPnup//ZH6 13YAUAAYA4FMihWJR/E+AGcjlsetSV4dDDxpXa3f6bHpUafJFIKKKK6DUztQ0t729tLqLUruye33 Ai3WIiVWKkq29G4+UfdwevNZMPgTSLa61WeACNtSjeOTZa26lA5y2HEW9snkiRnB7irOvyXMFxD5 NzLEl5G9mNh5SViNjjqAQN/Y9s9Kp2V5cTwbpJpHNrNb2Mg8xhmVZAHbgjOcr7HuCDSWrt/Wv9L7 wbtr/X9b/cEHgOxttIGmwX95DbssscwhjgiEySfeQqkQVR6FAp688nOtquijVfLR9QvILcDbNbwm PZcLn7rblJHflCp569Mc9rnifWNH0R9Qc2IWS8eGNzGgSBFZgDIZbiJWLbR0ZcE4w1T6j4ivbLSL vVI4Qsn2O1k8tpI3jgLltzEmREIHc7wDjrTvZX7Cdtu9yxqngix1bTpbGe7uPs73b3ao0NvKsbPk sAskTDBZmbJBYEnBA4q9B4cs7e4jnSSctHcrdAFhjcIPIx06befr7cVgxeL7uWLw9I9xpkP9obw8 ZeKRpdpwGTZOQFOMkqZtu4Z4BNOg1+XU/BbX91qUAi+1CK5vLABI44Q4DsrpJIANucuGBUEk7Cpw 02m0vT9CuZ79/wBdWbk2gGa+vJjqt8tvdgiWzUQ+VnYE3AmPfnAB+9jPasrxh4XuNas/LsoraZnu RPIl28YUEJsBG+CZew6pnk4YdDWuPENppdhZLo2u2LWUnmNDPfzvdfamBH7mKUyAsxJOCWcjoFOM C/PqPiCXUjHayadBA85tkWe3kkdG8nzN7EOoPOV2ceu7tS326f1/X+QJ6/1/X9dzXttLEZilmlZ7 hZPOdlwFZ/L8s4GOmOcVlzeCNJm1bTtSZQbixREQvbQSFwn3cu8ZdSP9hlqna6x4kvxbPFJpUCTs sG1reSQo5gEpfO9cjOV2cHGDu7VM3i0W8NnHeS2cN9dw2rwwFjmVnbEmwE5YKOeOnU03dO4uV/CT WfgjSbHUNSvLdQj36OkgS2gQoGOWxIsYkbJ5+dmrpK5az1PVZ4YxqRtGMn2OeP7KJItgkfBQ/Od2 NvXgNnBX1xdb8c3OnWt5NFrGiCeO58r7E0SeZbgb+JWkuohltoI6d8ButJ+7o+n9fqCXvWPQ6K4u z1rULi71Rbq7t5RHdWj21nEjRSxxusZyWD5ZSxYDIwSrA5Hyh2n+JtQ1CznNrf6RezGSFVlt428u 2aRwpjkG8lnUc9UJ6ELRbWwdTsqK5HTPEd/N4mt9JvbvTS5il8yK3T94zI7LvwZd0akLkDY46jfn GeuoDrYKiuYnntpIo7iS3d1IWaIKWQ+o3Arn6gj2qWqGuFl0DUWR3RhbSEOjFWU7TyCOQfcUDW5S Phs/YxGus6il55xma/XyfOcldpBHl+XjaAMbOwPXmr0OlW8E9pJGZAtpC0MUe7KgHb8x9WwuM+hP qa577XcTPBaG5nD6VcJFcMsjAys2Am45+bMZ3EHuynqKmGrzafYm+c5t4bS0knEkjMEjYsHfLHPA +Ykkkhe5prVNonrY17jSZZdYTUItVvbbCKklvEsRjlCliN26MsPvH7rCppNPSeG2juZZJzByXfaD ISjISwAA5DHoBz+VczfeLL210K/uZPsttc2QRJmdA0ayOwIHzyxKBsKn5nX7w57FbHxoktlp5u57 KO8vY7cwRBhmcvIUkKAO24AYPyswGckkc0JX0K6m1beHrW1trSET3Mn2YACSRwWkIcPuY45JYc/U 0630MQNKrajeS27TLNFbyeXsgIffhSEDEE9mZuOBiucn8VahYaVqknk7JLWVxF9o2EunmlTNlpUX y16bSykY5IBGa99471G20fRLxbe1ze7t7tNbeXMQ2AqMboKpccja0uOmDiktX8/z/r+mS7HS6noX n6XeRWpDTzQzoqzMAh81tzAna3GeOVYY6q3Q4Fj8Pkn0rTYNVeKGSwld4YrWG2dFBYNgE2yBTkZ3 RpGeepIzXV6gXvNNvoLK5CXaIVDI2TFJtDKCAfdTg9QfQ1z0GpXF3eqyXcwi1d1a1QtjyliP7wLx xuUZ78mlezKb01Okg02G3milRpC0YlAyRj944Zu3qOKy5vCsdybhrjVdRld9vkO5i3WoWQSDYfL+ b5lQ/vN/3fc5yfEF4qeDdGmudStrct5bObvWZNO8790ePOTLE5IOO+KdqGoWp1/Qyt8ba7kjjc2h 1WQT7D2NqTskGN2525UKTzjirNP8Aei/H7jV1vwhp2vWT294SxM4uBI8EMxV9oThZUZOQO6nqcYq GbwPo82q6bqPlRrNYRxxoBZ2xDBPuctEWTHbyylYllq2jXOlX81j4kM2ktPF9ol/tVpJIEJIZ2k3 FoVY4GAV2gEjbk4LXVNKGo6TanxIy3hlLWouNTIE1sZWCfIWxOXA2qxDHGGznBKjq18vy/r8exL2 f9f1t+KOz0nTU0jTIbCKeaaKBdkZl27lQfdX5QMgDABPPHJJ5q7XN65rlrpF5eR3uoLatcWSizje TaZZQZAREOrPynC5PK+1Zn9srp/iW+X7Z9vu/IJFpFeN5kOEGEe3Y7QC2MSjaSXUHj5iXuVK+7/r +rnb0Vz3hW8vHiubHUYbuC6hYSKl5JG8pjf+ImN3GN4kA54AAxXQ0CQUUUUAFFFB6Gk9gMnTLrw/ qwmk0qfTL0RotvK1q8cm1RkqjFc4AycA+pqxHoulRXF3cR6ZZpNeDFzIsChpx/tnGW/GuY0fSdWu tItNO1I69bxxSAStNc28LFBEwCo9swbYG2nkhumSRmi60fW7fQbtIH1G6uri2tt6tesWEwJ8wpia LbxtyFkRTj6gtr+vUq13udLa2mj6agsrS3sbVIWDiCFEQIXJAO0dCx3D35p8ujaXcXVrdTabZyXF oMW0rwKXhH+wSMr+FYelWGsf2VaR36zNKi2pYSyAkFJCXz8787dufmYn+83WuitF2xOPKnj/AHrn E0m8n5jyDuOFPUDsCBgYwG0QtVqPigit1KwxJGrMzkIoALMck8dySST6mpKKKQxssscMTSyuscaD LOxwAPUmqF94f0XVIoYtQ0jT7uODPkpcWySCPPXaCDjoOlU/F+oW1j4flS6liiS7P2YSSzxRKhYH 5iZGUEAAnAyeOAa5geKLIeN2uD4q0v8As4oQCt9H5e3bwpBucBt3O4Q57bsZrsoYKdWHOul/wtp6 shz5XY9BMUbSJIY1LoCFYjlc9cHtVBdO0S2urnWVs9PiuXRhcXwiRXZR94PJjOBt5ye3tXn+pa9p 8NnosVj4mtppkIkuZTrasd/yZ3ZuYxt4PG2ReuE9ZfEGu6NeaRJZxa7Yy+dHdoq2+tQxKjuzbGkH mLvTB6fN1+6e3RHK5Nx31b6bf8OCmr2PQdN0nTNHt2g0vT7Sxhdt7R2sKxKWxjJCgDOAOfanzafZ XNi1jPaW8tm67Wt3jDRsPQqRjFcbr3jPw/PBBEmtQyRpcbZI7LV4IXmTymOQ4lXaAxHVlOV7jGZD 4r0WfRLexm8S6fFOFg86aPVockbh5ih94bIUHJwM7uDnpj/Z9ZxUmnr5dP6/rs1JHSXfhvQr+2tr a80XTriC1XbbxTWqOsI4GEBGFHA6egp8Wg6PDJeSRaTYxvegi6ZLdAbgHOQ5x82cnrnrXAX+s6Xb 2En2PxVBcSFJYtja6rHYJlMRH7+M7gmed6kj7xJ4o/tTSNR8OXVvfeK7IXL6WbaKN9aVV8wiQEsF lbJwUyWZ+nU8k7f2ZJrmbe9ttfW39aDUtUrnoem6Tpuj27W+l6faWMDNvMdrCsSlsAZwoAzgDn2q 5Xm83ijR2nsvs2txRFYYxA769CUtmBO8Tr5x80kY5/efUdSweKND/sdUfVJGbz83US+I4RNMdv3o 3+0Dam7B2ho/93sV/ZtV66/d/wAH+n5ake0R6HJf2cNnJeS3cCWsWfMmaQBEwcHLdBggg0yz1XTt RgSeyv7W5idyiSQTK6swGSAQeTgZxXn2v+LdDTR4JG8QadIYpJSFXUQ8ikyDb80W91Pll13KCV3d uoXRPFOiqba8bxLpUfnOIlB1JnYxIsxVpfNCsDlwMMD91fmOeK/syp7F1OV7vppp/Vw59tT0gzRi ZYTIglZSypuG4gYBIHoMj8xT68/0bxfodqGlk1eJWWKQyx3OuQTGeX5MGPMxCg4bA+QD0XNQt4q0 Uw6lnWUM7yAu66/CFuI95+WAed+6O3jpGf8Aaz81Z/2bV5rWf9P1/r77HtFa56NRXnEmvaPdabGv /CVwWxit52gj/tyPzEkypiEjiQ7yAD1ZlOed1dZ4bntLiK+k0/U11C0Nz+7kW8+0hTsQsu7JI+Yk 7SeM8YGKyrYOVKHNK/3efcpSvsbdFFFcZQUUUUAV795I9Ounhz5qxOUx/ewcVwXwlstOufBpupII Zr6e4kN40iBm356HPtjivRa468+G2kT6jNfWdzf6bJcHM62c+xH9eOxNdFKceRwk7XtqZzi+ZSWp jSy614n8aavo1hrMmjWOkxosaW6DLsR1P+zWJB4t8Qa7pugWH9qSWlxcalNYXN1bouZAgBDD0PNd pefDjSrmaKeG81G0uFgW3lmgnw06AY+c45OOM1ch8C6NbQ6PFbpLEmlTGeDa/wB5z1L+ua6FXopL /Lyf33Zl7Od/+Ceda7PrS6R4z8O3uszXkWmxRTpM6De6tglD7cj8q1L1tb0PwdoEFv4guS2ozQxe aY13Qxsv3V+nr7V2dz4K0u8vNauZzOzavCsNwu7gBQANvHB4zVK2+HllFa21vcapqV1HazpNAJpg RHsGFUcdOaaxFNpX9dvJfqHs5X/4Pmc9Iuv3PjNPB0PiS8hhtrY3U14QDNKSRhR6AZH61g6jrWoX ul/2VqtwLufSvEENuLoDBlX5iCffivTPEHg2w1++g1Az3VnqEClEurWTY+0/wn1HNV4/h7okOjwa bGJ1jiuluzIZMvJIO7HHNEMRSSTe/p16v5g6ctUjmIdW1a0+IBg8R6rqOnpJd4so0jBtJ4+y7uxN epVycngGxuNYhv73UdSu0gmM8VtPPujRyeuMdPausrmrzhK3L2NacZK9wooornNAooooAKKKKACi iigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKACiiigAooooAKKKKAI4reKAyGNApkcu 56lm9T+AA+gFSUUUAFFFFABRRRQAUUUUAFFFFABRRRQAU2QusTmNQ7gEqpOAT2Ge1OopMDATxRG7 A/ZJRG2n/bAzMAS3UxbeoYAj86vLrNqb82B80XQTcR5L+XnGSol27C2Oduc45xUH/COWexVEs4C3 n2vhh1/udPue361APB+lr4pfxAqIt26kMPs0BJYrt3eYY/NBxxgPj2o/r+vy+XzD+v6/P5/In0vx JY6raCaEXAYLGWT7NL/HwCpKjemf41yvBOcVsVj6doH9nB9uqX8zlY40eUxkxxociNQEAwckEkFj n73AxsVTt0AKKKKQEU9zDbCMzPsEjiNSQcbj0Htk8VUi1zTZ0geO6DJOQI2CnBJbaMnHGSCOe9S6 np8WqafLZyu8ayAYkjxujYEFWXIIyCARkHkVRfwzZPa38AknQXZQhlK5gKYKmPIIGGG/kH5iT7UA WYtc02dIHjugyTkCNgpwSW2jJxxkgjnvUtnqdnqCo1rOJVdC6kA9Adv4cg/kaov4Zsntb+ASToLs oQylcwFMFTHkEDDDfyD8xJ9qmttGisnuXtZ5o3ndH6qQqrj5BlThT82ep+diCOMC8wGT+IrGzSM3 TuGkkkQCCCWbaEYqWbanyqOMscKPXvSReIrGTV5dMdnSdJNiHy3KOdgfG/btDbSTszuwM4xVVfDt xdWUP2q+msrkmU3CWLq6SLI5cxkyR5I5xuAVuuMZrTGk24cMpkGJvOABGAfL8vHTpj9aO4FKPxbo 01nNdRTXDxxbOFs5i7h/uMibN0inBwygg4PPBqxHr+nyagLFXnExUHLW0qoDjdtLldofHOwnd7VB feG7e90yWx+0zRRyW8dszCOKTKITwVkRlOckHKn2xRB4cigvElGoXr26YZbR2QxiQLt8zO3fnHbd tyScZoe7t/X9f13B+QxPGOiyW7TRzXMgBXakdlO0kgYEqyIE3OpCsdygr8p54NWxrunnUzp/mTee ByTbyCMHG7b5m3Zvxztzux2qvc+HI5Vga21C9sp4IkijngMZYKoYYw6MpzuOcjsMYxTxoK/2mbtr +8eLd5n2RvL8oSbdu8fJvzjtu25OcZoe+n9f1/XcCoPG+ivPZwwm9ma7mWGMx2MxHzKzK/K8xkI2 HGRwecBiJ38W6PHIyebdMVkaJjHZTuoKnDHcEI2qeC33QeCRT5fDtvJJZSJc3MMtn5XlOhQnCB1w QVIOVkcHjvxg80l34djuVjWLUL21A8wS+SY/3yO25kbcjcZJ5XDDsaJW6f1/X9ebduhJNr1ras4n Wb/j4FvGIIJJ2c7A2dqKSBzyTwO55qebV7SDUo9PczG4kXd+7t5HRBzy7qpVM4ONxGccVT1Hw1ba jb/ZzcTwxG5S4ZUSJslQAB86NtxtBBXDA8hhUv8AYr/2h9q/tS+2sCJrfEXlzD5sBvkyNobAKkEg DJND8v60/wAydRkfinSZLSa6E06xRMqnfaSqz7jhSilQZAx4BUEE9M0/TvEemarci3tJpmlaMyAS W0keQrbWGXUDcpIDL1UnkCo7Pw7Hag+dqF7eMGj8t7gx5jRG3Kg2ouRnucse5q7BpsNvOkqNIWQz EAkY/eOHbt6jihef9f1/XcfQuUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUU UAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQ AUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFABRRRQAUUUUAFFFFAB RRRQAUUUUAFFFFAH/9k= ------=_NextPart_000_00C7_01CB3F9E.7F1B0150-- From pal@cs.stanford.edu Thu Aug 19 13:13:10 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F18D63A6890 for ; Thu, 19 Aug 2010 13:13:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.086 X-Spam-Level: X-Spam-Status: No, score=-6.086 tagged_above=-999 required=5 tests=[AWL=-0.087, BAYES_50=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SVs2AEdlY63T for ; Thu, 19 Aug 2010 13:13:08 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id D542B3A69FA for ; Thu, 19 Aug 2010 13:12:59 -0700 (PDT) Received: from dn0a2101cb.sunet ([10.33.1.203]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OmBUU-0000FE-5X; Thu, 19 Aug 2010 13:13:34 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: Date: Thu, 19 Aug 2010 13:13:33 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <29231A09-9307-42CE-9F69-3C6F4252C86B@cs.stanford.edu> References: <004801cb3fab$d0231a30$70694e90$@com> <7F60EAC1-5A7D-481E-961D-F7728AB85726@cs.stanford.edu> To: X-Mailer: Apple Mail (2.1081) X-Scan-Signature: d3e02c565cd5ac634b2ff74b6ba3e13d Cc: roll@ietf.org Subject: Re: [Roll] English usage in I-D's X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 20:13:10 -0000 On Aug 19, 2010, at 12:52 PM, wrote: >=20 > On 19 Aug 2010, at 17:58, Philip Levis wrote: >=20 >> Colin -- we have had this discussion on the list already. It's = partially a cultural difference. The notion that fewer words is better = originated in American writing in the 19th century. >=20 > It did not. >=20 > "I would have written a shorter letter, but I did not have the time.", = Blaise Pascal, Provincial Letters: Letter XVI, 17th century. >=20 > "less is more" is pithy, but came later (Robert Browning, Andrea del = Sarto, 1855. Again, not America.) >=20 > One can also make the case for stonemasons desiring brevity, and thus = for the ten commandments. This is a fallacy of generalization. A few quotations from individuals = who perhaps saw beyond their time do not indicate a general sentiment. = I'll happily take the corpus of 19th-century and earlier literature as = evidence before the opinions of a few. I realize that what I said was a = gross generalization and the real history of English prose is far more = nuanced and complex; I did not think that this is the right forum to = discuss how Latin grammar and style influences Western writing. That being said.... Writing is hard. Any text can always be improved. The question an author = faces is whether the added effort is worth the gains. At some point, = editing must end, or nothing will ever finish. I can -- just as others have done -- take any non-trivial piece of text = and point out possible improvements. As part of a genuine discussion on = how to improve the text, those comments are always worthwhile. I can = promise you that a series of detailed suggestions and editorial comments = would be applied. Unfortunately, general comments such as "increase = brevity" are difficult to act upon. Nobody is arguing that the text = should be more voluminous or fluffy. Rather, the consensus of the WG and = opinion of the shepherd was that the text was "good enough." Phil= From L.Wood@surrey.ac.uk Thu Aug 19 13:25:50 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CCD5D3A6895 for ; Thu, 19 Aug 2010 13:25:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_50=0.001, GB_I_LETTER=-2, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11HY9R+sv61K for ; Thu, 19 Aug 2010 13:25:49 -0700 (PDT) Received: from mail82.messagelabs.com (mail82.messagelabs.com [195.245.231.67]) by core3.amsl.com (Postfix) with ESMTP id 0CA3F3A698C for ; Thu, 19 Aug 2010 13:25:48 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: L.Wood@surrey.ac.uk X-Msg-Ref: server-4.tower-82.messagelabs.com!1282249583!27957711!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [131.227.200.31] Received: (qmail 3121 invoked from network); 19 Aug 2010 20:26:23 -0000 Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-4.tower-82.messagelabs.com with AES128-SHA encrypted SMTP; 19 Aug 2010 20:26:23 -0000 Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.14]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Thu, 19 Aug 2010 21:26:22 +0100 From: To: Date: Thu, 19 Aug 2010 21:26:22 +0100 Thread-Topic: [Roll] English usage in I-D's Thread-Index: Acs/3MoNYN8FgwvaQratrB+WXkcxFg== Message-ID: References: <004801cb3fab$d0231a30$70694e90$@com> <7F60EAC1-5A7D-481E-961D-F7728AB85726@cs.stanford.edu> <29231A09-9307-42CE-9F69-3C6F4252C86B@cs.stanford.edu> In-Reply-To: <29231A09-9307-42CE-9F69-3C6F4252C86B@cs.stanford.edu> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: roll@ietf.org Subject: Re: [Roll] English usage in I-D's X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 20:25:50 -0000 Brevity is the best recommendation of speech, whether in a senator or an or= ator. -- Marcus Tulius Cicero (106-43 BC) TL;DR On 19 Aug 2010, at 21:13, Philip Levis wrote: >=20 > On Aug 19, 2010, at 12:52 PM, wrote: >=20 >>=20 >> On 19 Aug 2010, at 17:58, Philip Levis wrote: >>=20 >>> Colin -- we have had this discussion on the list already. It's partiall= y a cultural difference. The notion that fewer words is better originated i= n American writing in the 19th century. >>=20 >> It did not. >>=20 >> "I would have written a shorter letter, but I did not have the time.", B= laise Pascal, Provincial Letters: Letter XVI, 17th century. >>=20 >> "less is more" is pithy, but came later (Robert Browning, Andrea del Sar= to, 1855. Again, not America.) >>=20 >> One can also make the case for stonemasons desiring brevity, and thus fo= r the ten commandments. >=20 > This is a fallacy of generalization. A few quotations from individuals wh= o perhaps saw beyond their time do not indicate a general sentiment. I'll h= appily take the corpus of 19th-century and earlier literature as evidence b= efore the opinions of a few. I realize that what I said was a gross general= ization and the real history of English prose is far more nuanced and compl= ex; I did not think that this is the right forum to discuss how Latin gramm= ar and style influences Western writing. >=20 > That being said.... >=20 > Writing is hard. Any text can always be improved. The question an author = faces is whether the added effort is worth the gains. At some point, editin= g must end, or nothing will ever finish. >=20 > I can -- just as others have done -- take any non-trivial piece of text a= nd point out possible improvements. As part of a genuine discussion on how = to improve the text, those comments are always worthwhile. I can promise yo= u that a series of detailed suggestions and editorial comments would be app= lied. Unfortunately, general comments such as "increase brevity" are diffic= ult to act upon. Nobody is arguing that the text should be more voluminous = or fluffy. Rather, the consensus of the WG and opinion of the shepherd was = that the text was "good enough." >=20 > Phil Lloyd Wood L.Wood@surrey.ac.uk http://sat-net.com/L.Wood From alexandru.petrescu@gmail.com Thu Aug 19 14:35:28 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4F2483A69FE for ; Thu, 19 Aug 2010 14:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=0.350, BAYES_50=0.001, GB_I_LETTER=-2, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IaBjFa5vnIWb for ; Thu, 19 Aug 2010 14:35:27 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id D59373A6898 for ; Thu, 19 Aug 2010 14:35:25 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 729EE940091 for ; Thu, 19 Aug 2010 23:35:55 +0200 (CEST) Message-ID: <4C6DA3B7.5040509@gmail.com> Date: Thu, 19 Aug 2010 23:35:51 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: roll@ietf.org References: <004801cb3fab$d0231a30$70694e90$@com> <7F60EAC1-5A7D-481E-961D-F7728AB85726@cs.stanford.edu> <29231A09-9307-42CE-9F69-3C6F4252C86B@cs.stanford.edu> In-Reply-To: <29231A09-9307-42CE-9F69-3C6F4252C86B@cs.stanford.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100819-0, 19/08/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] English usage in I-D's X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 21:35:28 -0000 Le 19/08/2010 22:13, Philip Levis a écrit : > > On Aug 19, 2010, at 12:52 PM, wrote: > >> >> On 19 Aug 2010, at 17:58, Philip Levis wrote: >> >>> Colin -- we have had this discussion on the list already. It's >>> partially a cultural difference. The notion that fewer words is >>> better originated in American writing in the 19th century. >> >> It did not. >> >> "I would have written a shorter letter, but I did not have the >> time.", Blaise Pascal, Provincial Letters: Letter XVI, 17th >> century. >> >> "less is more" is pithy, but came later (Robert Browning, Andrea >> del Sarto, 1855. Again, not America.) >> >> One can also make the case for stonemasons desiring brevity, and >> thus for the ten commandments. > > This is a fallacy of generalization. A few quotations from > individuals who perhaps saw beyond their time do not indicate a > general sentiment. I'll happily take the corpus of 19th-century and > earlier literature as evidence before the opinions of a few. I > realize that what I said was a gross generalization and the real > history of English prose is far more nuanced and complex; I did not > think that this is the right forum to discuss how Latin grammar and > style influences Western writing. > > That being said.... > > Writing is hard. Any text can always be improved. The question an > author faces is whether the added effort is worth the gains. > > At some point, editing must end, or nothing will ever finish. That is also true. > I can -- just as others have done -- take any non-trivial piece of > text and point out possible improvements. As part of a genuine > discussion on how to improve the text, those comments are always > worthwhile. I can promise you that a series of detailed suggestions > and editorial comments would be applied. Unfortunately, general > comments such as "increase brevity" are difficult to act upon. Well, yes, it is difficult, but in the past RPL draft did see such an increase in brevity: from the 99 pages of version -2 to 82 pages of -4. That was a good thing, I think. Here are some additional ideas: Find in the ToC the sections taking much more pages than every other, understand why, and question their usefulness. In RPL-11 all 167 1-, 2- and 3-level sections are indexed at a difference between 1 and 3 pages. Except sections 6.1 and 8.2.2 each 5 pages long. One wonders why are these 2 particular sections so long compared to the 165 others? They don't seem to describe core behaviour. Is there a way to reduce them? Eliminate the RPLInstanceID concept. The core protocol would work without: run several "instances" of Unix processes, PIDs. Join InstanceID, DAGID, DAGVersionNumber and DAGVersion into one ID. For some reason they read as a very similar thing to one reader. More ways: reuse IPsec AH security, and don't describe confidentiality (encryption) at all - that would reduce some text. Because instead of specifying a secure version for each RPL message (section 6.1 taking 5 pages), AH covers a payload whatever that is, one single text sprinkled here and there with short details of mutable fields, like the Checksum. Remove section 10.3 - it's called "Installing Keys" but it doesn't say how. > Nobody is arguing that the text should be more voluminous or fluffy. > Rather, the consensus of the WG and opinion of the shepherd was that > the text was "good enough." That is ok too. Alex > > Phil _______________________________________________ Roll mailing > list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll > From coflynn@newae.com Thu Aug 19 14:54:36 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CCFB3A69EB for ; Thu, 19 Aug 2010 14:54:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.59 X-Spam-Level: X-Spam-Status: No, score=-1.59 tagged_above=-999 required=5 tests=[AWL=0.409, BAYES_00=-2.599, J_CHICKENPOX_18=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SR2uvZDK8mBv for ; Thu, 19 Aug 2010 14:54:34 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 47B9E3A699E for ; Thu, 19 Aug 2010 14:54:34 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OmD4l-0001Lj-Ao; Thu, 19 Aug 2010 17:55:08 -0400 From: "Colin O'Flynn" To: "'Philip Levis'" References: <004801cb3fab$d0231a30$70694e90$@com> <7F60EAC1-5A7D-481E-961D-F7728AB85726@cs.stanford.edu> In-Reply-To: <7F60EAC1-5A7D-481E-961D-F7728AB85726@cs.stanford.edu> Date: Thu, 19 Aug 2010 22:55:01 +0100 Message-ID: <00a501cb3fe9$2f764100$8e62c300$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acs/v7895TaAu8W9Rk2dd6OxnMj68QAJTLrQ Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: roll@ietf.org Subject: Re: [Roll] English usage in I-D's X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 21:54:36 -0000 Hello, > Yes, that description was added. Excellent, exactly what I was looking for. > The same metric does not hold in all languages or all readers/writers of > English. I honestly don't think it's a cultural thing. You literally see it all the time where stuff is excessively complicated, in all sorts of fields. In America it's more commonly associated with "executive speak". But the academic field is just as bad the world over, I can guarantee you. Consider for example SCIgen (http://pdos.csail.mit.edu/scigen/) which generated an accepted academic paper by purposely generating all sorts of babble. > No document is ever perfect -- it can always be improved by editing. This is not simple editing mistakes such as "that should be a semi-colon, not a comma". Multiple sections literally define the same stuff, under different section names (see my initial e-mail). Part of the document makes a grand introduction to what greediness is, why it's bad, how it happens, then simply says the user doesn't need to worry about it because it can't happen. Again the core problems aren't even that the language itself is too 'academic'. It's that stuff is redefined, defined using different wording, or completely unnecessary. This isn't a 'cultural' difference, be it academic/commercial or French/American culture. It's always been more difficult to write a concise, short document. RPL as-is seems great as a draft stage, where you've got all the technical stuff down. But as a final standard, I couldn't imagine it to be acceptable... Warm Regards, -Colin -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: August 19, 2010 5:58 PM To: Colin O'Flynn Cc: roll@ietf.org Subject: Re: [Roll] English usage in I-D's On Aug 19, 2010, at 7:35 AM, Colin O'Flynn wrote: > Hello, > > I finally got time to catching up on some of the latest I-D's. I'm a little taken back by the complexity of English used in the drafts, especially references to more academic things and just all-around inconsistency. > > People reading these will likely be engineers needing to implement the standards. I pain to see how someone with English as a second language who has been away from the academic side of things for a while will do. > > I know RPL has gone to the IETF so it's too late to post things here, but thought I'd put them up here first anyway for comments. Maybe I'm just missing something. > > As a few examples: > > #1) Trickle from mailing list discussion > > For the WG, the misunderstanding was coming from the the use of different > > notation. In some countries we use [a,b[ instead: > > > > But that's OK let's use the [a,b) notation. > > There is even a chance to confuse people IN the field! Why not either define what is meant by writing it out, or use something like 'a <= x < b'? I see a note that a 'natural langauge' description will be added which makes sense hopefully... Yes, that description was added. "When an interval begins, Trickle resets c to 0 and sets t to a random point in the interval, taken from the range [I/2, I), that is, values greater than or equal to I/2 and less than I. The interval ends at I." > > #2) Trickle + RPL Together (from section 8.3, RPL) > > > Note that this list is not exhaustive, and an implementation MAY > > consider other messages or events to be inconsistencies. > > My implementation could consider the "main oscillator oscillating" an inconsistency by that wording, and just transmit DIO packets as long as it wanted couldn't it, and be 100% to spec? There is something to be said for not trying to make the specification too flexible I think. > > In all seriousness though shouldn't this section have better linkage? Section 5 of the trickle draft says what the protocol specification needs to specify. The Imin/Imax/k are specified well in section 8.3.1. However the definition of a "consistent" transmission is semi-hidden in the paragraph: > > > A DIO from a sender with a lesser DAGRank > > that causes no changes to the recipient's parent set, preferred > > parent, or Rank SHOULD be considered consistent with respect to the > > Trickle timer. > > Am I just stupid, or would it be better if that section (8.3) was reworded such that it explicitly states what a "consistent transmission" and "inconsistent transmission" is, and possibly combined with section 8.3.1. By this I mean consider someone who sees in the Trickle draft that RPL should specify those six items, then wants to quickly find them in the RPL draft. They would find Imin/Imax/k no problem as they are well defined in an appropriately titled section. The only chance of finding the other three is if you looked above section 8.3.1, or searched the document for the word 'Trickle'. This section was very carefully worded. Please note that the definition of what constitutes a consistent transmission is an optimization method: it leads to suppression, reducing communication and energy expenditure. If a node does not suppress (e.g., k=infinity, defines nothing as consistent), then it simply transmits every interval. In contrast, the definition of what is *inconsistent* is critical for correctness. Hence the inconsistencies being defined as MUSTs. > > #3) Option Length Definitions > > Let's look at all the different wordings for 'option length': > > >Option Length: 8-bit unsigned integer, representing the length in > > octets of the option, not including the Option Type and Length > > fields. > > >Option Length: For N (N > 1) octets of padding, the Option Length > > field contains the value N-2. > > >Option Length: The Option Length field contains the length in octets > > of the Metric Data. > > >Option Length: Variable, length of the option in octets excluding > > the Type and Length fields. Note that this length is expressed > > in units of single-octets, unlike in IPv6 ND. > > >Option Length: 14 > > >Option Length: Variable, length of the option in octets excluding > > the Type and Length fields. > > >Option Length: Variable, depending on whether or not Parent Address > > is present. > > >Option Length: 19 > > >Option Length: 30. Note that this length is expressed in units of > > single-octets, unlike in IPv6 ND. > > >Option Length: 4 > > I count 10 definitions of option length. The only ones that are consistent are the 13/19/4 types, every other definition uses a different wording. > > #4) Use of too many Words > > The purpose of English is to communicate clearly. Adding more words than needed detracts from that purpose. You write to be understood by the reader, not to feel good about what you are writing. Consider the following beauties: > > 4.1 - OF (from section 3.7, RPL) > > > The Objective Function itself is decoupled from the routing metrics > > and constraints used by RPL. Indeed, whereas the OF dictates rules > > such as DODAG parents selection, load balancing and so on, the set of > > metrics and/or constraints used, and thus determine the preferred > > path, are based on the information carried within the DAG container > > option in DIO messages. > > Amazingly there is two sentences in there; the first one makes sense but is a little complicated, the second one has five commas and seems to be written by two different people about half-way through. Colin -- we have had this discussion on the list already. It's partially a cultural difference. The notion that fewer words is better originated in American writing in the 19th century. The same metric does not hold in all languages or all readers/writers of English. As one example, Pascal, JP and I debated it a lot: I always thought fewer words is better, while their opinion, coming from French, was that more text typically adds greater larit. > > 4.2 - Loop Avoidance (from section 3.8, RPL) > > "rank-based datapath validation mechanisms" > > Despite the fact this section is a repeat of elsewhere (see #5), this is a great example of what I mean. The first phrase is a less clear way of saying either "validating rank" or even better "checking packets are moving in the intended direction". Of course a "rank-based datapath validation mechanism" sounds like more of an achievement than either of those two. > > 4.3 - Greediness (from section 3.8.1, RPL) > All of section 3.8.1/3.8.1.1 seems unnecessary. RPL doesn't allow greediness - case closed. If you want to learn about greediness in general the RPL draft isn't the location. > > 4.4 - Introduction (section 1, 1.2, RPL) > > Examples of such objectives include > > minimizing energy, minimizing latency, or satisfying constraints > > Of course, 'satisfying constraints'. Wait, isn't minimizing energy and minimizing latency also satisfying a constraint? > > > RPL > > is designed to be able to operate over a variety of different link > > layers, including ones that are constrained, potentially lossy, or > > typically utilized in conjunction with highly constrained host or > > router devices, such as but not limited to, low power wireless or PLC > > (Power Line Communication) technologies. > > Was this a contest to write the words "different link layers" in as many words as possible? > > #5) Sections that repeat the same information (RPL) > > This is mostly a problem in section 3. Lots of information is repeated in different locations, which just makes it longer and more confusing. > > Consider section 3.8 and section 3.3.7. They are both in the overview and deal with loops, and basically say the same thing. There's some more loop stuff later even in section 3.8.2, but it's at least a tiny bit different! > > Throughout most of the introduction there is similar things. Section 3.7 has two paragraphs about the objective function, but then there is also a separate paragraph in section 3.3.1 about the objective function. Further it seems random if 'Objective Function', 'OF', 'Objective Function (OF)', or 'objective function' is used in the whole document. > > There's plenty more but I haven't gone through everything. My comments here are purely on how the draft is written, nothing technical. I'm not sure how the IETF works but hopefully we could clean this up a lot without affecting LC, since it's not actually changing any packet formats or logic. No document is ever perfect -- it can always be improved by editing. It's great that someone is taking a fresh look. As I'm sure you know, when you've been writing and rewriting for a long time, you can lose context and perspective. Phil From daniel.gavelle@jennic.com Fri Aug 20 00:55:19 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89EA53A68A9 for ; Fri, 20 Aug 2010 00:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.726 X-Spam-Level: X-Spam-Status: No, score=-0.726 tagged_above=-999 required=5 tests=[AWL=-0.539, BAYES_20=-0.74, HELO_MISMATCH_COM=0.553] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oXvxc9qDQXFu for ; Fri, 20 Aug 2010 00:55:18 -0700 (PDT) Received: from mail.jennic.com (proxy.jennic.co.uk [81.23.53.53]) by core3.amsl.com (Postfix) with ESMTP id 5A1023A6856 for ; Fri, 20 Aug 2010 00:55:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.jennic.com (Postfix) with ESMTP id 672599BE50C; Fri, 20 Aug 2010 08:55:51 +0100 (BST) Received: from mail.jennic.com ([127.0.0.1]) by localhost (smithers.jennic.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBOzIf1NHZt9; Fri, 20 Aug 2010 08:55:51 +0100 (BST) Received: from [10.99.96.69] (snifflap01.jennic.com [10.99.96.69]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mail.jennic.com (Postfix) with ESMTPSA id 4F6969BE508; Fri, 20 Aug 2010 08:55:51 +0100 (BST) Message-ID: <4C6E3506.8070104@jennic.com> Date: Fri, 20 Aug 2010 08:55:50 +0100 From: Daniel Gavelle Organization: Jennic Ltd. User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Dario Tedeschi References: <4C6D7BDD.7000807@exegin.com> In-Reply-To: <4C6D7BDD.7000807@exegin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] Question on path to grand children in non-storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: daniel.gavelle@jennic.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 07:55:19 -0000 Dario, Yes, that is how non-storing mode has to work. Daniel. Dario Tedeschi wrote: > > Given the following simple linear DODAG operating in non-storing mode: > > ER > [A]<---[B]<---[C]<---[D]<---[E] > > > Where [A] is the DODAG root. > > If [C] wants to send a packet to [E], is it true that the path would be > [C] to [B] to [A] to [B] to [C] to [D] to [E] ? > > Since, (in non-storing mode) the root node is the only node that stores > routes, I can't see any other way of [C] reaching [E]. Or, am I missing > something? > > Dario > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > Regards, Daniel. -- __________________________________________________ Daniel Gavelle, Software Team Leader Low Power RF Solutions (formerly Jennic Ltd.) NXP Semiconductors Furnival Street, Sheffield, S1 4QT, UK Tel: +44 114 281 2655 Fax: +44 114 281 2951 Comp Reg No: 3191371 - Registered In England http://www.nxp.com http://www.jennic.com __________________________________________________ From dominique.barthel@orange-ftgroup.com Fri Aug 20 01:19:15 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 157EF3A683C for ; Fri, 20 Aug 2010 01:19:15 -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=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbYew9zAbg8B for ; Fri, 20 Aug 2010 01:19:14 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 167A43A68A2 for ; Fri, 20 Aug 2010 01:19:14 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9541357C2B7 for ; Fri, 20 Aug 2010 10:19:47 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 1874657C224 for ; Fri, 20 Aug 2010 10:19:35 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Aug 2010 10:18:36 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 20 Aug 2010 10:18:31 +0200 Message-ID: <8E09C72DBC577D489F13A71228C0B7BF017ECCCB@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Groupdocument ? Thread-Index: Acs/C8lXPkYAoSIeQpGZRzbC1RoHHQBLtWsg References: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> From: To: X-OriginalArrivalTime: 20 Aug 2010 08:18:36.0890 (UTC) FILETIME=[49B563A0:01CB4040] Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Groupdocument ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 08:19:15 -0000 I'm in favour. The proposed mechanism is a useful complement to the core = RPL mechanism, it makes use of the same basic objects/concepts with = slight twists added, and I found the document well written. Dominique -----Message d'origine----- De : roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] De la part de = JP Vasseur Envoy=E9 : mercredi 18 ao=FBt 2010 21:30 =C0 : ROLL WG Objet : [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working = Groupdocument ? Dear all, draft-dt-roll-p2p-rpl-02.txt has been presented several times and = discussed on the mailing list. Could you let us know whether or not you = think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a ROLL = Working Group document (feel free to justify) ? Thanks. JP. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From Emmanuel.Monnerie@landisgyr.com Fri Aug 20 07:50:37 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26B6F3A6A77 for ; Fri, 20 Aug 2010 07:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.045 X-Spam-Level: X-Spam-Status: No, score=0.045 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_05=-1.11, J_CHICKENPOX_63=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BhHMuE0nmB6P for ; Fri, 20 Aug 2010 07:50:36 -0700 (PDT) Received: from mta2.cellnet.com (mta2.cellnet.com [148.80.254.17]) by core3.amsl.com (Postfix) with ESMTP id 199493A6A9D for ; Fri, 20 Aug 2010 07:50:36 -0700 (PDT) X-ASG-Debug-ID: 1282315870-5617001f0000-BCmCR7 X-Barracuda-URL: http://172.25.128.17:8000/cgi-bin/mark.cgi Received: from livemail.cellnethunt.com (localhost [127.0.0.1]) by mta2.cellnet.com (Spam Firewall) with ESMTP id 2ABC5456004 for ; Fri, 20 Aug 2010 10:51:10 -0400 (EDT) Received: from livemail.cellnethunt.com ([10.1.130.15]) by mta2.cellnet.com with ESMTP id qJanzuj5OnuvPq0d for ; Fri, 20 Aug 2010 10:51:10 -0400 (EDT) X-ASG-Whitelist: Sender X-ASG-Whitelist: Client Received: from livemail.cellnethunt.com ([10.1.130.105]) by livemail.cellnethunt.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 20 Aug 2010 10:51:09 -0400 Received: from mail pickup service by livemail.cellnethunt.com with Microsoft SMTPSVC; Fri, 20 Aug 2010 10:51:09 -0400 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.4325 Importance: normal Priority: normal Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-ASG-Orig-Subj: RE: [Roll] English usage in I-D's Date: Fri, 20 Aug 2010 10:51:08 -0400 Message-ID: <76DBCE2AA6605F42A49F1BD7454C841BF65455@usatlsv105.am.bm.net> In-Reply-To: <29231A09-9307-42CE-9F69-3C6F4252C86B@cs.stanford.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] English usage in I-D's thread-index: Acs/2w2GLximIivbQiaYNBEyeAPCQAAmyjDw References: <004801cb3fab$d0231a30$70694e90$@com><7F60EAC1-5A7D-481E-961D-F7728AB85726@cs.stanford.edu> <29231A09-9307-42CE-9F69-3C6F4252C86B@cs.stanford.edu> From: "Monnerie, Emmanuel" To: "Philip Levis" X-OriginalArrivalTime: 20 Aug 2010 14:51:09.0673 (UTC) FILETIME=[2042DD90:01CB4077] X-Barracuda-Connect: UNKNOWN[10.1.130.15] X-Barracuda-Start-Time: 1282315870 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at cellnet.com Cc: roll@ietf.org Subject: Re: [Roll] English usage in I-D's X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 14:50:37 -0000 Philip, In order to avoid a flood of long emails, could we consider sending the RPL author team an annotated document (MS Word format) including mostly editorial comments? Regards -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Philip Levis Sent: Thursday, August 19, 2010 4:14 PM To: L.Wood@surrey.ac.uk Cc: roll@ietf.org Subject: Re: [Roll] English usage in I-D's [...] I can -- just as others have done -- take any non-trivial piece of text and point out possible improvements. As part of a genuine discussion on how to improve the text, those comments are always worthwhile. I can promise you that a series of detailed suggestions and editorial comments would be applied. Unfortunately, general comments such as "increase brevity" are difficult to act upon. Nobody is arguing that the text should be more voluminous or fluffy. Rather, the consensus of the WG and opinion of the shepherd was that the text was "good enough." Phil _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll Emmanuel Monnerie Senior Research Engineer Landis+Gyr Energy Management Solutions Office: +1 678 258 1695 Fax: +1 678 258 1316 Emmanuel.Monnerie@landisgyr.com www.landisgyr.com manage energy better From culler@cs.berkeley.edu Fri Aug 20 09:48:32 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F77D3A6AA7 for ; Fri, 20 Aug 2010 09:48:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2qOApI9SYXb for ; Fri, 20 Aug 2010 09:48:31 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 8D0593A695B for ; Fri, 20 Aug 2010 09:48:31 -0700 (PDT) Received: from [10.71.0.130] ([12.157.151.170]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o7KGmh2C004082 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 20 Aug 2010 09:48:44 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: David Culler In-Reply-To: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> Date: Fri, 20 Aug 2010 09:48:43 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <39D9881C-818C-4229-907F-E249500EA4CE@cs.berkeley.edu> References: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> To: JP Vasseur X-Mailer: Apple Mail (2.1081) Cc: ROLL WG Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 16:48:32 -0000 Sounds like the hum to me. On Aug 18, 2010, at 12:30 PM, JP Vasseur wrote: > Dear all, >=20 > draft-dt-roll-p2p-rpl-02.txt has been presented several times and = discussed on the mailing list. Could you let us know whether or not you = think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a ROLL = Working Group document (feel free to justify) ? >=20 > Thanks. >=20 > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From robert.cragie@gridmerge.com Fri Aug 20 10:01:10 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C78873A6978 for ; Fri, 20 Aug 2010 10:01:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wBoK8etRpIrF for ; Fri, 20 Aug 2010 10:01:09 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 455E23A6857 for ; Fri, 20 Aug 2010 10:01:09 -0700 (PDT) Received: from [70.96.129.163] (helo=[10.42.1.60]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1OmUyG-0005sA-TE; Fri, 20 Aug 2010 18:01:37 +0100 Message-ID: <4C6EB4EC.9030508@gridmerge.com> Date: Fri, 20 Aug 2010 18:01:32 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: d.sturek@att.net References: <2FC6E0A9-2728-40D5-ADA8-A9E5BFC10656@cisco.com> <010901cb3f0e$715132f0$53f398d0$@sturek@att.net> In-Reply-To: <010901cb3f0e$715132f0$53f398d0$@sturek@att.net> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms070606050908030702000207" Cc: 'ROLL WG' Subject: Re: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group document ? X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 17:01:10 -0000 This is a cryptographically signed message in MIME format. --------------ms070606050908030702000207 Content-Type: multipart/alternative; boundary="------------020407060109040308060500" This is a multi-part message in MIME format. --------------020407060109040308060500 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable +1 Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 18/08/2010 8:49 PM, Don Sturek wrote: > +1 > > I am in favor of the p2p draft being adopted by ROLL > > Don > > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of= JP > Vasseur > Sent: Wednesday, August 18, 2010 12:30 PM > To: ROLL WG > Subject: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Gro= up > document ? > > Dear all, > > draft-dt-roll-p2p-rpl-02.txt has been presented several times and > discussed on the mailing list. Could you let us know whether or not > you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a > ROLL Working Group document (feel free to justify) ? > > Thanks. > > JP. > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --------------020407060109040308060500 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

Robert Cragie (Pacific Gas & Electric)

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


On 18/08/2010 8:49 PM, Don Sturek wrote: 
+1

I am in favor of the p2p draft being adopted by ROLL

Don

-----Original Message-----
From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On =
Behalf Of JP
Vasseur
Sent: Wednesday, August 18, 2010 12:30 PM
To: ROLL WG
Subject: [Roll] Adoption of draft-dt-roll-p2p-rpl-02.txt as Working Group=

document ?

Dear all,

draft-dt-roll-p2p-rpl-02.txt has been presented several times and =20
discussed on the mailing list. Could you let us know whether or not =20
you think that draft-dt-roll-p2p-rpl-02.txt should be adopted as a =20
ROLL Working Group document (feel free to justify) ?

Thanks.

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

_______________________________________________
Roll mailing list
Roll@=
ietf.org
https://www.ietf.org/mailman/listinfo/roll
--------------020407060109040308060500-- --------------ms070606050908030702000207 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA4 MjAxNzAxMzJaMCMGCSqGSIb3DQEJBDEWBBQ7J6kD9BHR1FQZlHh08JVBqkD1cjBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAJedaJCna8K8AunOEiTaLc1KlNejoY8Wt5U9K7pKUidQm/RS2gDGZ4q+MWcHlBDZqsFw UD3x0be0f+J5K1sEGGek1BwY3PWP0pVXMCL0ZT+gCpyi+2ERfPuaKXPtlX9TPTokA0Qd49Zt xGLEIVXOKsjmCj0Ckxji2lDhk33TGqppPEIbwszi7MXPDHjyrQuOwSnQetUpNAjWtxvfJgOn vib0JHeo8c0Anbtd+rPXITfYC78s5rDErK0eWkq6Kf8DFmB+MwxLyPMWGXDWsskWgBr52WsO SLXjqGrvCURnq97Kr7Ue2A05yjaxaySPUROUnmeC292QYj08Q28FaBTl2JYAAAAAAAA= --------------ms070606050908030702000207-- From dat@exegin.com Fri Aug 20 10:22:08 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 272993A6855 for ; Fri, 20 Aug 2010 10:22:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.634, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2s9b18o6nP5 for ; Fri, 20 Aug 2010 10:22:07 -0700 (PDT) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 5EF223A6AA0 for ; Fri, 20 Aug 2010 10:22:06 -0700 (PDT) Received: by ewy22 with SMTP id 22so2469746ewy.31 for ; Fri, 20 Aug 2010 10:22:40 -0700 (PDT) Received: by 10.216.86.15 with SMTP id v15mr1543972wee.9.1282324960117; Fri, 20 Aug 2010 10:22:40 -0700 (PDT) Received: from [172.16.1.52] ([216.251.130.154]) by mx.google.com with ESMTPS id w14sm1955836weq.33.2010.08.20.10.22.37 (version=SSLv3 cipher=RC4-MD5); Fri, 20 Aug 2010 10:22:38 -0700 (PDT) Message-ID: <4C6EB9CB.7010204@exegin.com> Date: Fri, 20 Aug 2010 10:22:19 -0700 From: Dario Tedeschi User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: roll@ietf.org References: <4C6D7BDD.7000807@exegin.com> In-Reply-To: <4C6D7BDD.7000807@exegin.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] Question on path to grand children in non-storing mode X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 17:22:08 -0000 Thanks for the confirmation. Dario Tedeschi wrote: > > Given the following simple linear DODAG operating in non-storing mode: > > ER > [A]<---[B]<---[C]<---[D]<---[E] > > > Where [A] is the DODAG root. > > If [C] wants to send a packet to [E], is it true that the path would > be [C] to [B] to [A] to [B] to [C] to [D] to [E] ? > > Since, (in non-storing mode) the root node is the only node that > stores routes, I can't see any other way of [C] reaching [E]. Or, am I > missing something? > > Dario From mcr@sandelman.ca Fri Aug 20 11:12:46 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E11463A6AFC; Fri, 20 Aug 2010 11:12:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.834 X-Spam-Level: X-Spam-Status: No, score=-1.834 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2j58VsRPpM1o; Fri, 20 Aug 2010 11:12:45 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 16AE33A6B2E; Fri, 20 Aug 2010 11:12:17 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id BFF82346E2; Fri, 20 Aug 2010 14:12:51 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 2B9BF98A97; Fri, 20 Aug 2010 14:12:51 -0400 (EDT) From: Michael Richardson To: ietf@ietf.org, roll@ietf.org X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 20 Aug 2010 14:12:51 -0400 Message-ID: <13773.1282327971@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] Unresolved issues with RPL-11: security section. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 18:12:47 -0000 I have read the security sections of draft-ietf-roll-rpl-11. The encumbered signature algorithms have been removed, which is good. There are two major issues which I thought were brought up in RPL-10 which are still unresolved: 1) if RPL is using a link-level security mechanism, how can the distinction in section 3.3.3 (and 10.1) between "pre-installed" and "authenticated" be communicated from the link-level security to the RPL-level? I.e. how is layer-2/layer-3 channel binding done? (When the security is built-in, then section 10.2 tries to explain it, and I think the idea will work, but I'm not sure if the actual details are right. The rules of 10.2 will take me some time to fully understand, and they are very new.) 2) we still do not know how to calculate the MAC. What byte does it start at? The beginning of the IPv6 header, it says in 10.8. What values go into the mutable fields? What about checksum? Flow-Label? I'd guess zero, but??? I'd like to see a sample packet in the document along with the keys involved. -- ] 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 pal@cs.stanford.edu Fri Aug 20 15:14:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4DAE03A685A for ; Fri, 20 Aug 2010 15:14:35 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMGn6EEuh0Xa for ; Fri, 20 Aug 2010 15:14:34 -0700 (PDT) Received: from cs-smtp-3.Stanford.EDU (cs-smtp-3.Stanford.EDU [171.64.64.27]) by core3.amsl.com (Postfix) with ESMTP id 7CAFA3A6B32 for ; Fri, 20 Aug 2010 15:14:31 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.127]) by cs-smtp-3.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OmZrZ-0000wh-OV; Fri, 20 Aug 2010 15:15:02 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <76DBCE2AA6605F42A49F1BD7454C841BF65455@usatlsv105.am.bm.net> Date: Fri, 20 Aug 2010 13:57:22 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <004801cb3fab$d0231a30$70694e90$@com><7F60EAC1-5A7D-481E-961D-F7728AB85726@cs.stanford.edu> <29231A09-9307-42CE-9F69-3C6F4252C86B@cs.stanford.edu> <76DBCE2AA6605F42A49F1BD7454C841BF65455@usatlsv105.am.bm.net> To: "Monnerie, Emmanuel" X-Mailer: Apple Mail (2.1081) X-Scan-Signature: f219e97bb238ccbb8ed40879dafdba3c Cc: roll@ietf.org Subject: Re: [Roll] English usage in I-D's X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Aug 2010 22:14:35 -0000 On Aug 20, 2010, at 7:51 AM, Monnerie, Emmanuel wrote: > Philip, >=20 > In order to avoid a flood of long emails, could we consider sending = the > RPL author team an annotated document (MS Word format) including = mostly > editorial comments? Summary: I'd leave it to Tim and Pascal (editors) and David (chair) to = decide. Long-winded: Well, I think that would be up to the editors (Pascal and Tim). Note = that the document has passed last call and is now on to the IESG, so = major rewritings are problematic. A huge list of edits on a 100+ page = document might be difficult to apply, as I'm sure you realize: the = resulting document would of course then need to go through an additional = editorial pass for consistency and correctness, etc.=20 Furthermore, it's worth saying that there isn't a single "true" way to = write a document with as varied a readership and domain as this one. For = example, a document that's clear, concise, and comprehensible to an = expert in LLNs can be inscrutable to someone who's used to wired = networks. Conversely, a document that's clear and concise to a wired = network designer might seem verbose and long-winded to an LLN expert.=20 Phil= From robert.cragie@gmail.com Fri Aug 20 19:23:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3674D3A6901 for ; Fri, 20 Aug 2010 19:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i+gKKSt-jfwj for ; Fri, 20 Aug 2010 19:23:38 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 894AB3A68C7 for ; Fri, 20 Aug 2010 19:23:38 -0700 (PDT) Received: by vws10 with SMTP id 10so3967035vws.31 for ; Fri, 20 Aug 2010 19:24:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=+XAcUtVSz5X3fomXItNS/kS7sOzZgJGazT12c9hoK68=; b=gasoHk8iHRLfuU4zYXyu2R37c8uiZeucH6DXeu2i0YLXtqFzS3fECtoIpSR7VbHErK 52tyWy3ZXqwWtYccxRAPWc17PqSdIdymlVKg4C+uC5CRxwWjA7yWvbsTxIF2RjoWkkhx mKT//CSqfnhGDuEMG0ZhrNFTGceklAB7c058w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=Mlwd0adCrDl9ncsQKKZj4NTbwpL+uqpKuYvwjwjz2WNB7j3Ig9pQPFEz3+7zHH8taz Kn4TEi4xMeyLgIIil/ce+ewQqU9RBqcGiBhMfDUXGsuzfssNNgDYj64yv1wD+zWErAoN i++8wkhQKu7KwZjelXxlqLlr4D9su7RzJReA0= MIME-Version: 1.0 Received: by 10.220.88.138 with SMTP id a10mr1374927vcm.96.1282357452348; Fri, 20 Aug 2010 19:24:12 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.220.170.78 with HTTP; Fri, 20 Aug 2010 19:24:12 -0700 (PDT) In-Reply-To: <13773.1282327971@marajade.sandelman.ca> References: <13773.1282327971@marajade.sandelman.ca> Date: Sat, 21 Aug 2010 03:24:12 +0100 X-Google-Sender-Auth: vvSTBUfSAnXlPiZ4MHPyan8-VWg Message-ID: From: Robert Cragie To: Michael Richardson Content-Type: multipart/alternative; boundary=0016363b7b706c1e3f048e4c1c38 Cc: roll@ietf.org Subject: Re: [Roll] Unresolved issues with RPL-11: security section. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 02:55:17 -0000 --0016363b7b706c1e3f048e4c1c38 Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, Comments inline, bracketed by Robert -- Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On Fri, Aug 20, 2010 at 7:12 PM, Michael Richardson wrote: > > I have read the security sections of draft-ietf-roll-rpl-11. > The encumbered signature algorithms have been removed, which is good. > > There are two major issues which I thought were brought up in RPL-10 > which are still unresolved: > > 1) if RPL is using a link-level security mechanism, how can > the distinction in section 3.3.3 (and 10.1) between "pre-installed" > and "authenticated" be communicated from the link-level > security to the RPL-level? > I.e. how is layer-2/layer-3 channel binding done? > Both these modes are for RPL security. What does this have to do with link layer security? If there is link layer security, the assumption is that you would not use RPL security, in which case link layer key management is out of scope. Whilst you could use both link layer and RPL security, there is probably little point. > > (When the security is built-in, then section 10.2 tries to explain > it, and I think the idea will work, but I'm not sure if the actual > details are right. > > The rules of 10.2 will take me some time to fully understand, > and they are very new.) > > 2) we still do not know how to calculate the MAC. > What byte does it start at? The beginning of the IPv6 header, > it says in 10.8. What values go into the mutable fields? What > about checksum? Flow-Label? I'd guess zero, but??? > > I'd like to see a sample packet in the document along with the > keys involved. > "Message authentication codes (MAC) and signatures are calculated over the entire IPv6 packet" - that seems pretty clear to me. With regard to mutable fields, I'm not sure there are any. A source-routed DAO ACK may have a RH4 header in but that is processed at every hop therefore is resecured at every hop. With regard to checksum, this is calculated prior to securing the message. Flow label - I too would guess 0 as these are control messages. I agree a sample packet would be useful along with securing/unsecuring steps. > > -- > ] 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. > > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --0016363b7b706c1e3f048e4c1c38 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael,=A0

Comments inline, bracketed by <RCC>= </RCC>

Robert

--=A0
Robe= rt Cragie (Pacific Gas & Electric)

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


On Fri, Aug 20, 2010 at 7:12 PM, Micha= el Richardson <mcr= @sandelman.ca> wrote:

I have read the security sections of draft-ietf-roll-rpl-11.
The encumbered signature algorithms have been removed, which is good.

There are two major issues which I thought were brought up in RPL-10
which are still unresolved:

=A01) if RPL is using a link-level security mechanism, how can
=A0 =A0 the distinction in section 3.3.3 (and 10.1) between "pre-inst= alled"
=A0 =A0 and "authenticated" be communicated from the link-level<= br> =A0 =A0 security to the RPL-level?
=A0 =A0 I.e. how is layer-2/layer-3 channel binding done?
=
=A0
<RCC>Both these modes are for RPL security. What d= oes this have to do with link layer security? If there is link layer securi= ty, the assumption is that you would not use RPL security, in which case li= nk layer key management is out of scope. Whilst you could use both link lay= er and RPL security, there is probably little point.</RCC>

=A0 =A0 (When the security is built-in, then section 10.2 tries to explain=
=A0 =A0 =A0it, and I think the idea will work, but I'm not sure if the= actual
=A0 =A0 =A0details are right.

=A0 =A0 =A0The rules of 10.2 will take me some time to fully understand, =A0 =A0 =A0and they are very new.)

=A02) we still do not know how to calculate the MAC.
=A0 =A0 What byte does it start at? =A0The beginning of the IPv6 header, =A0 =A0 it says in 10.8. =A0What values go into the mutable fields? =A0Wha= t
=A0 =A0 about checksum? Flow-Label? =A0I'd guess zero, but???

=A0 =A0 I'd like to see a sample packet in the document along with the=
=A0 =A0 keys involved.
=A0
<RCC>
"Message authentication codes (MAC) and signatures are calculate= d over the entire IPv6 packet" - that seems pretty clear to me. With r= egard to mutable fields, I'm not sure there are any. A source-routed DA= O ACK may have a RH4 header in but that is processed at every hop therefore= is resecured at every hop. With regard to checksum, this is calculated pri= or to securing the message. Flow label - I too would guess 0 as these are c= ontrol messages.

I agree a sample packet=A0would be useful along with se= curing/unsecuring steps.
</RCC> =A0=A0

--
] =A0 =A0 =A0 He who is tired of Weird Al is tired of life! =A0 =A0 =A0 =A0= =A0 | =A0firewalls =A0[
] =A0 Michael Richardson, Sandelman Software Works, Ottawa, ON =A0 =A0|net = architect[
] mcr@sandelman.ottawa.on.ca<= /a> http:/= /www.sandelman.ottawa.on.ca/ |device driver[
=A0 Kyoto Plus: watch the video <http://www.youtube.com/watch?v=3Dkzx1y= cLXQSE>
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 then sign the petition.






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



--0016363b7b706c1e3f048e4c1c38-- From ajakuma2@cisco.com Fri Aug 20 20:46:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A0DB3A68FC for ; Fri, 20 Aug 2010 20:46:35 -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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekL46AgQQZVu for ; Fri, 20 Aug 2010 20:46:34 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 686F03A635F for ; Fri, 20 Aug 2010 20:46:34 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcHANfobkxAaMHG/2dsb2JhbACBRJFshRSHd3GdMptHhTcEhDKILg X-IronPort-AV: E=Sophos;i="4.56,243,1280707200"; d="scan'208,217";a="174932729" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 21 Aug 2010 03:47:08 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7L3l29R000560 for ; Sat, 21 Aug 2010 03:47:02 GMT Received: from xmb-bgl-41b.cisco.com ([72.163.129.217]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 21 Aug 2010 09:17:01 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB40E3.837B3B18" Date: Sat, 21 Aug 2010 09:17:00 +0530 Message-ID: <454A16E4DA86094EB66BB2C1DBBBC01802586E8A@XMB-BGL-41B.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification on ETX computation Thread-Index: ActA44Kr5uInWdOAR3yCFRL6ezADTg== From: "Ajay Kumar (ajakuma2)" To: X-OriginalArrivalTime: 21 Aug 2010 03:47:01.0953 (UTC) FILETIME=[83951310:01CB40E3] Subject: [Roll] Clarification on ETX computation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 03:46:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB40E3.837B3B18 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable HI WG, =20 I need some clarification on the way Path ETX is calculated from Link ETXs.=20 How is it additive metric? I believe it should be multiplicative unless Logarithmic values are sent. Or am I missing something?? =20 Regards, Ajay =20 ------_=_NextPart_001_01CB40E3.837B3B18 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI WG,

 

I need some clarification on the way Path ETX is = calculated from  Link ETXs.

How is it additive metric? I believe it should be multiplicative unless Logarithmic values are sent. Or am I missing = something??

 

Regards,

Ajay

=

 

------_=_NextPart_001_01CB40E3.837B3B18-- From gnawali@cs.stanford.edu Fri Aug 20 21:29:22 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE5133A635F for ; Fri, 20 Aug 2010 21:29:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.523 X-Spam-Level: X-Spam-Status: No, score=-5.523 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WikZgW0CRYpI for ; Fri, 20 Aug 2010 21:29:22 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id F0C073A67B3 for ; Fri, 20 Aug 2010 21:29:21 -0700 (PDT) Received: from mail-iw0-f174.google.com ([209.85.214.174]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:RC4-MD5:128) (Exim 4.60) (envelope-from ) id 1OmfiO-0005v8-3I for roll@ietf.org; Fri, 20 Aug 2010 21:29:56 -0700 Received: by iwn5 with SMTP id 5so1496605iwn.19 for ; Fri, 20 Aug 2010 21:29:55 -0700 (PDT) Received: by 10.231.157.212 with SMTP id c20mr2527858ibx.186.1282364995115; Fri, 20 Aug 2010 21:29:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.145.135 with HTTP; Fri, 20 Aug 2010 21:29:35 -0700 (PDT) In-Reply-To: <454A16E4DA86094EB66BB2C1DBBBC01802586E8A@XMB-BGL-41B.cisco.com> References: <454A16E4DA86094EB66BB2C1DBBBC01802586E8A@XMB-BGL-41B.cisco.com> From: Omprakash Gnawali Date: Fri, 20 Aug 2010 21:29:35 -0700 Message-ID: To: "Ajay Kumar (ajakuma2)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Scan-Signature: 9c8d7c79e82d9ccd3af9a51b4d3246f3 Cc: roll@ietf.org Subject: Re: [Roll] Clarification on ETX computation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 04:29:22 -0000 On Fri, Aug 20, 2010 at 8:47 PM, Ajay Kumar (ajakuma2) wrote: > HI WG, > > > > I need some clarification on the way Path ETX is calculated from=A0 Link = ETXs. > > How is it additive metric? I believe it should be multiplicative unless > Logarithmic values are sent. Or am I missing something?? ETX is the number of expected transmissions on a link. You add them up over the links to estimate the number of transmissions on a path. Here is a draft that talks about how to compute the path metric using ETX: http://tools.ietf.org/html/draft-gnawali-roll-minrank-hysteresis-of-01 - om_p From ajakuma2@cisco.com Sat Aug 21 00:54:37 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F50A3A6A46 for ; Sat, 21 Aug 2010 00:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGYcyiBx3+oi for ; Sat, 21 Aug 2010 00:54:36 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A3FBF3A677D for ; Sat, 21 Aug 2010 00:54:36 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALsib0xAaMHG/2dsb2JhbACgQHGbfJs5hTcEhDOIMIdX X-IronPort-AV: E=Sophos;i="4.56,244,1280707200"; d="scan'208";a="576776866" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 21 Aug 2010 07:55:10 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7L7t9oG029833; Sat, 21 Aug 2010 07:55:09 GMT Received: from xmb-bgl-41b.cisco.com ([72.163.129.217]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 21 Aug 2010 13:25:08 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 21 Aug 2010 13:25:07 +0530 Message-ID: <454A16E4DA86094EB66BB2C1DBBBC01802586E8E@XMB-BGL-41B.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Clarification on ETX computation Thread-Index: ActA6Y+ONlKoMVltRziLKMrV1MqIsgAG84mA References: <454A16E4DA86094EB66BB2C1DBBBC01802586E8A@XMB-BGL-41B.cisco.com> From: "Ajay Kumar (ajakuma2)" To: "Omprakash Gnawali" X-OriginalArrivalTime: 21 Aug 2010 07:55:08.0361 (UTC) FILETIME=[2C92AB90:01CB4106] Cc: roll@ietf.org Subject: Re: [Roll] Clarification on ETX computation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 07:54:37 -0000 Hi Omprakash, Consider this topo below: 2 2 2 | Root |----------| N1 | -----------| N2 |------------| N3 | Labels indicate ETX value. Now, at node 3 Path ETX must be 8 if ETX =3D = 1/Probability of Successful Transmissions (1/((0.5)*(0.5)*(0.5)). How could it be 6??? Or this logic is left to implementation???? Regards, Ajay -----Original Message----- From: Omprakash Gnawali [mailto:gnawali@cs.stanford.edu]=20 Sent: Saturday, August 21, 2010 10:00 AM To: Ajay Kumar (ajakuma2) Cc: roll@ietf.org Subject: Re: [Roll] Clarification on ETX computation On Fri, Aug 20, 2010 at 8:47 PM, Ajay Kumar (ajakuma2) wrote: > HI WG, > > > > I need some clarification on the way Path ETX is calculated from=A0 = Link ETXs. > > How is it additive metric? I believe it should be multiplicative = unless > Logarithmic values are sent. Or am I missing something?? ETX is the number of expected transmissions on a link. You add them up over the links to estimate the number of transmissions on a path. Here is a draft that talks about how to compute the path metric using ETX: http://tools.ietf.org/html/draft-gnawali-roll-minrank-hysteresis-of-01 - om_p From hrogge@googlemail.com Sat Aug 21 01:01:43 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 992E43A6860 for ; Sat, 21 Aug 2010 01:01:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t9LX2+pSMVF6 for ; Sat, 21 Aug 2010 01:01:42 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 2BD693A677D for ; Sat, 21 Aug 2010 01:01:41 -0700 (PDT) Received: by eyd10 with SMTP id 10so2834519eyd.31 for ; Sat, 21 Aug 2010 01:02:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:message-id; bh=6s6yn9/EVtEwVnzwDz0SqRxKGM9QCs6G+RthkG+4DdU=; b=r7qt7WZSLOeYAtBLr1TNyPsk2fxBQC6ECVTogGPBawbE5yfV8678tG1KqkYKBF5RrQ aqxmF00O8EDvP/ShBmzNLjbBnnUQ9lpu6EnqEIcd7rzH0MtoLrDHmRyXCRDMTIZW8vCl pqtOE8TYX2VIjJHmfedlcuHDwoFw2X3281q7o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding:message-id; b=jlBTdmiM7pNlS1fyQhW/+jtYn+Ktgn+JONPZKi0qUXDhYA/jndNFx89VblX8jypoYs LfIWzyBDIZPFLcp1at1Ob27cwYqcOROchH/36qe/TZC/2TtN6KK7oaPbqDD0W1IvoLRP ThnjIgs6Va4xSwpmXa+NjNqpa5dVYf5XHWoY0= Received: by 10.213.17.195 with SMTP id t3mr1259689eba.63.1282377735758; Sat, 21 Aug 2010 01:02:15 -0700 (PDT) Received: from core2.localnet (static-87-79-93-195.netcologne.de [87.79.93.195]) by mx.google.com with ESMTPS id a48sm6383929eei.13.2010.08.21.01.02.14 (version=SSLv3 cipher=RC4-MD5); Sat, 21 Aug 2010 01:02:14 -0700 (PDT) From: Henning Rogge To: roll@ietf.org Date: Sat, 21 Aug 2010 10:02:07 +0200 User-Agent: KMail/1.13.5 (Linux/2.6.35-gentoo-r1; KDE/4.4.5; x86_64; ; ) References: <454A16E4DA86094EB66BB2C1DBBBC01802586E8A@XMB-BGL-41B.cisco.com> <454A16E4DA86094EB66BB2C1DBBBC01802586E8E@XMB-BGL-41B.cisco.com> In-Reply-To: <454A16E4DA86094EB66BB2C1DBBBC01802586E8E@XMB-BGL-41B.cisco.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1506343.z1CgETKkpL"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201008211002.12985.hrogge@googlemail.com> Subject: Re: [Roll] Clarification on ETX computation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 08:01:43 -0000 --nextPart1506343.z1CgETKkpL Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Am Samstag 21 August 2010, 09:55:07 schrieb Ajay Kumar (ajakuma2): > Hi Omprakash, >=20 > Consider this topo below: > 2 2 2 >=20 > | Root |----------| N1 | -----------| N2 |------------| N3 | >=20 > Labels indicate ETX value. Now, at node 3 Path ETX must be 8 if ETX =3D > 1/Probability of Successful Transmissions (1/((0.5)*(0.5)*(0.5)). How > could it be 6??? Or this logic is left to implementation???? ETX woudl be 6 if you consider linklayer retransmissions. You need two=20 transmissions for the first hop, two for the second and two for the last on= e. Henning Rogge =2D-=20 1) You can't win. 2) You can't break even. 3) You can't leave the game. =E2=80=94 The Laws of Thermodynamics, summarized --nextPart1506343.z1CgETKkpL Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) iEYEABECAAYFAkxviAQACgkQcenvcwAcHWcSRACeJX9nrtGXd4XN2zydFH/2LUC+ KG4Anjkgm/r3vSWX91zq8nbX/enr20L+ =e3SG -----END PGP SIGNATURE----- --nextPart1506343.z1CgETKkpL-- From ajakuma2@cisco.com Sat Aug 21 01:26:12 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F79A3A683A for ; Sat, 21 Aug 2010 01:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TkXiO10WejyI for ; Sat, 21 Aug 2010 01:26:11 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D02FB3A6835 for ; Sat, 21 Aug 2010 01:26:11 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAO4qb0xAaMHG/2dsb2JhbACDGJxEZHGbb4lekVSBIoMicwSEM4gw X-IronPort-AV: E=Sophos;i="4.56,244,1280707200"; d="scan'208";a="576778597" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 21 Aug 2010 08:26:45 +0000 Received: from xbh-bgl-411.cisco.com (xbh-bgl-411.cisco.com [72.163.129.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o7L8QiH2003772; Sat, 21 Aug 2010 08:26:44 GMT Received: from xmb-bgl-41b.cisco.com ([72.163.129.217]) by xbh-bgl-411.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 21 Aug 2010 13:56:43 +0530 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: Sat, 21 Aug 2010 13:56:42 +0530 Message-ID: <454A16E4DA86094EB66BB2C1DBBBC01802586E8F@XMB-BGL-41B.cisco.com> In-Reply-To: <201008211002.12985.hrogge@googlemail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Clarification on ETX computation Thread-Index: ActBB3eDN9w1mdXaTCmaO+2yxKN4GAAArcIA References: <454A16E4DA86094EB66BB2C1DBBBC01802586E8A@XMB-BGL-41B.cisco.com> <454A16E4DA86094EB66BB2C1DBBBC01802586E8E@XMB-BGL-41B.cisco.com> <201008211002.12985.hrogge@googlemail.com> From: "Ajay Kumar (ajakuma2)" To: "Henning Rogge" , X-OriginalArrivalTime: 21 Aug 2010 08:26:43.0465 (UTC) FILETIME=[96249790:01CB410A] Subject: Re: [Roll] Clarification on ETX computation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 08:26:12 -0000 WWVzLi4uLiBUaGlzIGNsYXJpZmllcy4gVGhhbmtzLg0KDQpSZWdhcmRzLA0KQWpheQ0KDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBIZW5uaW5nIFJvZ2dlIFttYWlsdG86aHJv Z2dlQGdvb2dsZW1haWwuY29tXSANClNlbnQ6IFNhdHVyZGF5LCBBdWd1c3QgMjEsIDIwMTAgMToz MiBQTQ0KVG86IHJvbGxAaWV0Zi5vcmcNCkNjOiBBamF5IEt1bWFyIChhamFrdW1hMik7IE9tcHJh a2FzaCBHbmF3YWxpDQpTdWJqZWN0OiBSZTogW1JvbGxdIENsYXJpZmljYXRpb24gb24gRVRYIGNv bXB1dGF0aW9uDQoNCkFtIFNhbXN0YWcgMjEgQXVndXN0IDIwMTAsIDA5OjU1OjA3IHNjaHJpZWIg QWpheSBLdW1hciAoYWpha3VtYTIpOg0KPiBIaSBPbXByYWthc2gsDQo+IA0KPiBDb25zaWRlciB0 aGlzIHRvcG8gYmVsb3c6DQo+ICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgIDIgICAg ICAgICAgICAgICAgICAyDQo+IA0KPiAgIHwgIFJvb3QgIHwtLS0tLS0tLS0tfCBOMSAgfCAtLS0t LS0tLS0tLXwgTjIgfC0tLS0tLS0tLS0tLXwgICBOMyB8DQo+IA0KPiBMYWJlbHMgaW5kaWNhdGUg RVRYIHZhbHVlLiBOb3csIGF0IG5vZGUgMyBQYXRoIEVUWCBtdXN0IGJlIDggaWYgRVRYID0gDQo+ IDEvUHJvYmFiaWxpdHkgb2YgU3VjY2Vzc2Z1bCBUcmFuc21pc3Npb25zICgxLygoMC41KSooMC41 KSooMC41KSkuIEhvdyANCj4gY291bGQgaXQgYmUgNj8/PyBPciB0aGlzIGxvZ2ljIGlzIGxlZnQg dG8gaW1wbGVtZW50YXRpb24/Pz8/DQpFVFggd291ZGwgYmUgNiBpZiB5b3UgY29uc2lkZXIgbGlu a2xheWVyIHJldHJhbnNtaXNzaW9ucy4gWW91IG5lZWQgdHdvIHRyYW5zbWlzc2lvbnMgZm9yIHRo ZSBmaXJzdCBob3AsIHR3byBmb3IgdGhlIHNlY29uZCBhbmQgdHdvIGZvciB0aGUgbGFzdCBvbmUu DQoNCkhlbm5pbmcgUm9nZ2UNCg0KLS0NCjEpIFlvdSBjYW4ndCB3aW4uDQoyKSBZb3UgY2FuJ3Qg YnJlYWsgZXZlbi4NCjMpIFlvdSBjYW4ndCBsZWF2ZSB0aGUgZ2FtZS4NCuKAlCBUaGUgTGF3cyBv ZiBUaGVybW9keW5hbWljcywgc3VtbWFyaXplZA0K From alexandru.petrescu@gmail.com Sat Aug 21 08:16:33 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D1663A67B4 for ; Sat, 21 Aug 2010 08:16:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.604 X-Spam-Level: X-Spam-Status: No, score=-1.604 tagged_above=-999 required=5 tests=[AWL=0.645, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sw1N4B-1kWTk for ; Sat, 21 Aug 2010 08:16:32 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 2D9F23A68F1 for ; Sat, 21 Aug 2010 08:16:29 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id AD329940031 for ; Sat, 21 Aug 2010 17:16:58 +0200 (CEST) Message-ID: <4C6FEDE4.3040107@gmail.com> Date: Sat, 21 Aug 2010 17:16:52 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: roll@ietf.org References: <13773.1282327971@marajade.sandelman.ca> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100821-0, 21/08/2010), Outbound message X-Antivirus-Status: Clean Subject: Re: [Roll] Unresolved issues with RPL-11: security section. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 15:16:33 -0000 Le 21/08/2010 04:24, Robert Cragie a écrit : > Hi Michael, > > Comments inline, bracketed by > > Robert > > -- > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 > 1924 910888 +1 415 513 0064 http://www.gridmerge.com > > > > On Fri, Aug 20, 2010 at 7:12 PM, Michael Richardson > wrote: > > > I have read the security sections of draft-ietf-roll-rpl-11. The > encumbered signature algorithms have been removed, which is good. > > There are two major issues which I thought were brought up in RPL-10 > which are still unresolved: > > 1) if RPL is using a link-level security mechanism, how can the > distinction in section 3.3.3 (and 10.1) between "pre-installed" and > "authenticated" be communicated from the link-level security to the > RPL-level? I.e. how is layer-2/layer-3 channel binding done? > > Both these modes are for RPL security. What does this have to do > with link layer security? If there is link layer security, the > assumption is that you would not use RPL security, in which case link > layer key management is out of scope. Whilst you could use both link > layer and RPL security, there is probably little point. > > > (When the security is built-in, then section 10.2 tries to explain > it, and I think the idea will work, but I'm not sure if the actual > details are right. > > The rules of 10.2 will take me some time to fully understand, and > they are very new.) > > 2) we still do not know how to calculate the MAC. What byte does it > start at? The beginning of the IPv6 header, it says in 10.8. What > values go into the mutable fields? What about checksum? Flow-Label? > I'd guess zero, but??? > > I'd like to see a sample packet in the document along with the keys > involved. > > "Message authentication codes (MAC) and signatures are > calculated over the entire IPv6 packet" - that seems pretty clear to > me. Not so clear to me. > With regard to mutable fields, I'm not sure there are any. How about the Hop Limit field in the IPv6 base header, being decremented at each Hop? Does RPL MAC cover it? > A source-routed DAO ACK may have a RH4 header in but that is > processed at every hop therefore is resecured at every hop. Resecuring at each hop doesn't sound as end-to-end security. > With regard to checksum, this is calculated prior to securing the > message. Assume I want to compute that Checksum. MAC is not yet computed. Is the Checksum covering the MAC field? If yes, is the MAC field present and set to 0? Or is it absent altogether? Draft doesn't say. > Flow label - I too would guess 0 as these are control messages. Not sure. Flow label behaviour seems to be under discussion. > I agree a sample packet would be useful along with > securing/unsecuring steps. I agree examples are useful. Other remarks: draft says: > Message authentication codes (MACs) and signatures cover the entire > ICMPv6 RPL message, > [...] > For a RPL ICMPv6 message, the entire packet is within the scope of > RPL security. Does that mean the IPv6 base header is within scope too? Or only starting at ICMP? > Message authentication codes (MAC) and signatures are calculated over > the entire IPv6 packet. That sounds as the IPv6 base header too. But that has a Hop Limit field. Hop Limit is mutable, it is different at reception than what the sender send, thus making it impossible to verify the MAC. Alex > > > > -- ] 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. > > > > > > > _______________________________________________ Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > > > > > > _______________________________________________ Roll mailing list > Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Sun Aug 22 07:20:47 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A07A3A659C for ; Sun, 22 Aug 2010 07:20:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.696 X-Spam-Level: X-Spam-Status: No, score=-1.696 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjZeCgl2Z5nt for ; Sun, 22 Aug 2010 07:20:46 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id E54303A657C for ; Sun, 22 Aug 2010 07:20:45 -0700 (PDT) Received: from marajade.sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by relay.sandelman.ca (Postfix) with ESMTPS id F3BA23441D; Sun, 22 Aug 2010 10:21:18 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 98A6C98A97; Sun, 22 Aug 2010 10:21:17 -0400 (EDT) From: Michael Richardson To: Robert Cragie In-Reply-To: References: <13773.1282327971@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Sun, 22 Aug 2010 10:21:17 -0400 Message-ID: <4313.1282486877@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] Unresolved issues with RPL-11: security section. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 14:20:47 -0000 >>>>> "Robert" == Robert Cragie writes: >> I have read the security sections of draft-ietf-roll-rpl-11. The >> encumbered signature algorithms have been removed, which is good. >> >> There are two major issues which I thought were brought up in >> RPL-10 which are still unresolved: >> >> 1) if RPL is using a link-level security mechanism, how can the >> distinction in section 3.3.3 (and 10.1) between "pre-installed" >> and "authenticated" be communicated from the link-level security >> to the RPL-level? I.e. how is layer-2/layer-3 channel binding >> done? >> Robert> Both these modes are for RPL security. What does this Robert> have to do with link layer security? If there is link layer Robert> security, the assumption is that you would not use RPL Robert> security, in which case link layer key management is out of Robert> scope. Whilst you could use both link layer and RPL Robert> security, there is probably little point. If there is link-layer security, does it provide the equivalent of 'pre-installed' keys, or "authenticated" keys? What is the *AUTHORIZATION* provided by link-layer security? Is there an assumption that link layer security means that all nodes can be routers? Or WHAT? >> (When the security is built-in, then section 10.2 tries to >> explain it, and I think the idea will work, but I'm not sure if >> the actual details are right. >> >> The rules of 10.2 will take me some time to fully understand, and >> they are very new.) >> >> 2) we still do not know how to calculate the MAC. What byte does >> it start at? The beginning of the IPv6 header, it says in 10.8. >> What values go into the mutable fields? What about checksum? >> Flow-Label? I'd guess zero, but??? >> >> I'd like to see a sample packet in the document along with the >> keys involved. >> Robert> "Message authentication codes (MAC) and signatures are Robert> calculated over the entire IPv6 packet" - that seems pretty Robert> clear to me. With regard to mutable fields, I'm not sure Robert> there are any. A source-routed DAO ACK may have a RH4 header Then, you need to read the IPv6 specification and the AH specification. There are numerous fields that may chance in the IPv6 header including: - TTL - ToS/DSCP bits - maybe flow label - all hop-by-hop options Robert> in but that is processed at every hop therefore is resecured Robert> at every hop. With regard to checksum, this is calculated Robert> prior to securing the message. Flow label - I too would Robert> guess 0 as these are control messages. Robert> I agree a sample packet would be useful along with Robert> securing/unsecuring steps. -- ] 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 jpv@cisco.com Mon Aug 23 01:29:52 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B25AD3A67CC for ; Mon, 23 Aug 2010 01:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.412 X-Spam-Level: X-Spam-Status: No, score=-110.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtVsZDFjw57S for ; Mon, 23 Aug 2010 01:29:51 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 319C43A69A0 for ; Mon, 23 Aug 2010 01:29:51 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKPOcUxAZnwN/2dsb2JhbACBQ55scZxDmnyFNwSJdoJt X-IronPort-AV: E=Sophos;i="4.56,256,1280707200"; d="scan'208,217";a="150754561" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Aug 2010 08:30:24 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o7N8UNm3011366; Mon, 23 Aug 2010 08:30:24 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); Mon, 23 Aug 2010 10:30:23 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Aug 2010 10:30:22 +0200 Message-Id: <0986DDB7-629C-44B0-9867-5E9E7EE75DAB@cisco.com> From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-189--697656047 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 23 Aug 2010 10:30:21 +0200 References: <20100819194502.204BD3A680D@core3.amsl.com> X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 23 Aug 2010 08:30:22.0559 (UTC) FILETIME=[6D8F2EF0:01CB429D] Cc: Thomas Heide Clausen Subject: [Roll] Fwd: I-D Action:draft-ietf-roll-trickle-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 08:29:52 -0000 --Apple-Mail-189--697656047 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, Thanks Phil for having incorporated all the comments raised during the WG Last Call. The publication request has been sent to the IESG. Thanks. JP. Begin forwarded message: > From: Internet-Drafts@ietf.org > Date: August 19, 2010 9:45:02 PM CEDT > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: I-D Action:draft-ietf-roll-trickle-04.txt > Reply-To: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy > networks Working Group of the IETF. > > > Title : The Trickle Algorithm > Author(s) : P. Levis, et al. > Filename : draft-ietf-roll-trickle-04.txt > Pages : 13 > Date : 2010-08-19 > > The Trickle algorithm allows nodes in a lossy shared medium (e.g., > low power and lossy networks) to exchange information in a highly > robust, energy efficient, simple, and scalable manner. Dynamically > adjusting transmission windows allows Trickle to spread new > information on the scale of link-layer transmission times while > sending only a few messages per hour when information does not > change. A simple suppression mechanism and transmission point > selection allows Trickle's communication rate to scale > logarithmically with density. This document describes the Trickle > algorithm and considerations in its use. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-roll-trickle-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. Content-Type: text/plain
Content-ID: <2010-08-19123932.I-D@ietf.org >

> _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --Apple-Mail-189--697656047 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear = all,

Thanks Phil for having incorporated all the = comments raised during the WG Last Call.
The publication = request has been sent to the = IESG.

Thanks.

JP.

Begin forwarded message:

Date: August 19, 2010 9:45:02 PM = CEDT
To: i-d-announce@ietf.org
Subject: = I-D Action:draft-ietf-roll-trickle-04.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 =           : The = Trickle Algorithm
Author(s) =       : P. Levis, et al.
Filename =        : = draft-ietf-roll-trickle-04.txt
Pages =           : = 13
= Date =            : = 2010-08-19

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

A URL for = this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-roll-trickle-04.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-d= rafts/

Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of = the
Internet-Draft.
Content-Type: = text/plain<BR>Content-ID: &lt;2010-08-19123932.I-D@ietf.or= g&gt;<BR><BR>
_______________________________________________
I-D-= Announce mailing list
I-D-Announce@ietf.org
https:/= /www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft = directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

=
= --Apple-Mail-189--697656047-- From robert.cragie@gridmerge.com Mon Aug 23 06:12:38 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E29413A67ED for ; Mon, 23 Aug 2010 06:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZOl5KoIQxll for ; Mon, 23 Aug 2010 06:12:31 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 0E1AB3A6A1A for ; Mon, 23 Aug 2010 06:12:30 -0700 (PDT) Received: from client-86-27-10-225.glfd.adsl.virginmedia.com ([86.27.10.225] helo=[192.168.1.66]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1OnWpg-0008LP-K5; Mon, 23 Aug 2010 14:13:01 +0100 Message-ID: <4C7273DB.5080306@gridmerge.com> Date: Mon, 23 Aug 2010 14:12:59 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Michael Richardson References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca> In-Reply-To: <4313.1282486877@marajade.sandelman.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080500050503040606030004" Cc: roll@ietf.org Subject: Re: [Roll] Unresolved issues with RPL-11: security section. X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 13:12:39 -0000 This is a cryptographically signed message in MIME format. --------------ms080500050503040606030004 Content-Type: multipart/alternative; boundary="------------060901020001030104040106" This is a multi-part message in MIME format. --------------060901020001030104040106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable More comments below, bracketed by Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com On 22/08/2010 3:21 PM, Michael Richardson wrote: >>>>>> "Robert" =3D=3D Robert Cragie writes= : > >> I have read the security sections of draft-ietf-roll-rpl-11. = The > >> encumbered signature algorithms have been removed, which is go= od. > >> > >> There are two major issues which I thought were brought up in > >> RPL-10 which are still unresolved: > >> > >> 1) if RPL is using a link-level security mechanism, how can th= e > >> distinction in section 3.3.3 (and 10.1) between "pre-installed= " > >> and "authenticated" be communicated from the link-level securi= ty > >> to the RPL-level? I.e. how is layer-2/layer-3 channel binding= > >> done? > >> > > Robert> Both these modes are for RPL security. What does thi= s > Robert> have to do with link layer security? If there is link lay= er > Robert> security, the assumption is that you would not use RPL > Robert> security, in which case link layer key management is out = of > Robert> scope. Whilst you could use both link layer and RPL > Robert> security, there is probably little point. > > If there is link-layer security, does it provide the equivalent of > 'pre-installed' keys, or "authenticated" keys? > > What is the *AUTHORIZATION* provided by link-layer security? Is there > an assumption that link layer security means that all nodes can be > routers? Or WHAT? I don't get the point you're trying to make here. Key management=20 for link layer security is out of scope for this document. Link layer=20 security by implication provides hop-by-hop packet protection. This=20 would mean a whole IPv6 packet (obviously including the RPL control=20 message) is encrypted and there is likely to be integrity checking over=20 the whole MPDU. What more is there to say? > >> (When the security is built-in, then section 10.2 tries to > >> explain it, and I think the idea will work, but I'm not sure i= f > >> the actual details are right. > >> > >> The rules of 10.2 will take me some time to fully understand, = and > >> they are very new.) > >> > >> 2) we still do not know how to calculate the MAC. What byte d= oes > >> it start at? The beginning of the IPv6 header, it says in 10.= 8. > >> What values go into the mutable fields? What about checksum? > >> Flow-Label? I'd guess zero, but??? > >> > >> I'd like to see a sample packet in the document along with the= > >> keys involved. > >> > > Robert> "Message authentication codes (MAC) and signatures= are > Robert> calculated over the entire IPv6 packet" - that seems pret= ty > Robert> clear to me. With regard to mutable fields, I'm not sure > Robert> there are any. A source-routed DAO ACK may have a RH4 hea= der > > Then, you need to read the IPv6 specification and the AH specification.= > There are numerous fields that may chance in the IPv6 header including:= > - TTL > - ToS/DSCP bits > - maybe flow label > - all hop-by-hop options This is about securing RPL control messages. That limits the=20 options considerably. I agree that each case does need a little more=20 analysis in practice in the document. > > Robert> in but that is processed at every hop therefore is resecu= red > Robert> at every hop. With regard to checksum, this is calculated= > Robert> prior to securing the message. Flow label - I too would > Robert> guess 0 as these are control messages. > > Robert> I agree a sample packet would be useful along with > Robert> securing/unsecuring steps. > --------------060901020001030104040106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable More comments below, bracketed by <RCC2></RCC2>

Robert

Robert Cragie (Pacific Gas & Electric)

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


On 22/08/2010 3:21 PM, Michael Richardson wrote: 
"Robert" =3D=3D Robert Cragie <ro=
bert.cragie@gridmerge.com> writes:

    >> I have read the security sections of dr=
aft-ietf-roll-rpl-11.  The
    >> encumbered signature algorithms have been removed, which is =
good.
    >>=20
    >> There are two major issues which I thought were brought up i=
n
    >> RPL-10 which are still unresolved:
    >>=20
    >> 1) if RPL is using a link-level security mechanism, how can =
the
    >> distinction in section 3.3.3 (and 10.1) between "pre-install=
ed"
    >> and "authenticated" be communicated from the link-level secu=
rity
    >> to the RPL-level?  I.e. how is layer-2/layer-3 channel bindi=
ng
    >> done?
    >>=20

    Robert> <RCC>Both these modes are for RPL security. What doe=
s this
    Robert> have to do with link layer security? If there is link laye=
r
    Robert> security, the assumption is that you would not use RPL
    Robert> security, in which case link layer key management is out o=
f
    Robert> scope. Whilst you could use both link layer and RPL
    Robert> security, there is probably little point.</RCC>

If there is link-layer security, does it provide the equivalent of
'pre-installed' keys, or "authenticated" keys?

What is the *AUTHORIZATION* provided by link-layer security?  Is there
an assumption that link layer security means that all nodes can be
routers?  Or WHAT?
<RCC2>I don't get the point you're trying to make here. Key management for link layer security is out of scope for this document. Link layer security by implication provides hop-by-hop packet protection. This would mean a whole IPv6 packet (obviously including the RPL control message) is encrypted and there is likely to be integrity checking over the whole MPDU. What more is there to say?</RCC2>
    >> (When the security is built-in, then section 10.2 tries to
    >> explain it, and I think the idea will work, but I'm not sure=
 if
    >> the actual details are right.
    >>=20
    >> The rules of 10.2 will take me some time to fully understand=
, and
    >> they are very new.)
    >>=20
    >> 2) we still do not know how to calculate the MAC.  What byte=
 does
    >> it start at?  The beginning of the IPv6 header, it says in 1=
0.8.
    >> What values go into the mutable fields?  What about checksum=
?=20
    >> Flow-Label?  I'd guess zero, but???
    >>=20
    >> I'd like to see a sample packet in the document along with t=
he
    >> keys involved.
    >>=20

    Robert> <RCC> "Message authentication codes (MAC) and signat=
ures are
    Robert> calculated over the entire IPv6 packet" - that seems prett=
y
    Robert> clear to me. With regard to mutable fields, I'm not sure
    Robert> there are any. A source-routed DAO ACK may have a RH4 head=
er

Then, you need to read the IPv6 specification and the AH specification.
There are numerous fields that may chance in the IPv6 header including:
      - TTL
      - ToS/DSCP bits
      - maybe flow label
      - all hop-by-hop options
<RCC2>This is about securing RPL control messages. That limits the options considerably. I agree that each case does need a little more analysis in practice in the document.</RCC2>
     =20
    Robert> in but that is processed at every hop therefore is resecur=
ed
    Robert> at every hop. With regard to checksum, this is calculated
    Robert> prior to securing the message. Flow label - I too would
    Robert> guess 0 as these are control messages.

    Robert> I agree a sample packet would be useful along with
    Robert> securing/unsecuring steps.  </RCC>
--------------060901020001030104040106-- --------------ms080500050503040606030004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIJKzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC AvAwggJZoAMCAQICEHQVhhxGmCATv+IPne+OkB8wDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UE BhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMT I1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA5MDgyOTE2NTcwM1oX DTEwMDgyOTE2NTcwM1owTTEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEqMCgG CSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAtuQTYz8HUA37wa1PMyVnREeRwT3jtzGO6epyiCCaVeJkP76G KdnNapg0jyuzDfRqSMW0n570toMF9FTpD34hDvtHcnMDboU7MSKFV2VyOOlTB3eHJfRn2Jtl o9mSeW1qIIOwRReV6v50OxmijmeGFAn82Y1QrtyKDQxhl0HhEmY4jonziMyQ5gKlO5TM+CxY hV0zXCLHfp9QjLG7bwZx6F0ChSHvRaf5ZlLKQSI2BGAx/GtP5l4ME7+kq4icmbV0g6m1AH9Y LYYKV9rOx9SilPpTJdwn7GY/Qop4VSmdsaDBlXieBbjKqPN/CEqFmlxjjPFihorkeyC1T2R5 CqB41QIDAQABozgwNjAmBgNVHREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20w DAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQCTQ5bjbW8th9Yy/xbAgmc070Y/DLPR RwOu51zamGFNffSpiPDJsLg4Bu9QZqhDylPm3AriHGp9MVL8Ei4h5krygmgHLE0mNYFsJt35 90wdK7z3dXtV/nOD0+rFR6Y9oUGf916rO0madex0KbosqrUuZ1NGVh/Q5/7H0mAEg+1EWzCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQI EwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENv bnN1bHRpbmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAi BgNVBAMTG1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVy c29uYWwtZnJlZW1haWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5 NTlaMGIxCzAJBgNVBAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBM dGQuMSwwKgYDVQQDEyNUaGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzAN BgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9Vvy Gna9fww6YfK/Uc4B1OVQCjDXAmNaLIkVcI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOC dz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUPSAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCB kTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhh d3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0EuY3JsMAsGA1UdDwQEAwIBBjApBgNV HREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0xMzgwDQYJKoZIhvcNAQEFBQAD gYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2fNi/A9BxQIJNwPP2t4WFi w9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH1sYITq726jTlEBpb NU1341YheILcIRk13iSx0x1G/11fZU8xggNxMIIDbQIBATB2MGIxCzAJBgNVBAYTAlpBMSUw IwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3dGUg UGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQdBWGHEaYIBO/4g+d746QHzAJBgUrDgMC GgUAoIIB0DAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xMDA4 MjMxMzEyNTlaMCMGCSqGSIb3DQEJBDEWBBThcYQ5+N6RzkD1jELGvAuyNngDPjBfBgkqhkiG 9w0BCQ8xUjBQMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgYUGCSsGAQQBgjcQBDF4MHYw YjELMAkGA1UEBhMCWkExJTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4x LDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpgg E7/iD53vjpAfMIGHBgsqhkiG9w0BCRACCzF4oHYwYjELMAkGA1UEBhMCWkExJTAjBgNVBAoT HFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQZXJzb25h bCBGcmVlbWFpbCBJc3N1aW5nIENBAhB0FYYcRpggE7/iD53vjpAfMA0GCSqGSIb3DQEBAQUA BIIBAKN8JGv7I3n9EAg9adULVp/YrR6mZ6Vx2V+KquKrsA+P5HE+5az3R+08SZ4jZRvnwAPx 0VRvAU6r/OSPLsPoc7ZQrXgDe2vx2hV3Y4e4/zpvUWmJYZzlkhNSkhRYvwRugp/0DsCU/f2a +Mbcex4FLIDVqTjA0pg595pvA9BRf38v0H03VsKXpGqeqsAits2OzoXS9eq5jwIINBdOexTt k96AqlcuW3Jd2PeXH2vHKS84z9V7jMRxsImYG0Hr5RZh2e2a65SrPU4YymeI38SRlP63TOYO 4qU6NIFmBmN0vvo6z07ucX69EMBNSwOQUAPCllnswXGMz7g+2preENJRXg8AAAAAAAA= --------------ms080500050503040606030004-- From alexandru.petrescu@gmail.com Wed Aug 25 11:21:47 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A32C3A68EF for ; Wed, 25 Aug 2010 11:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.322 X-Spam-Level: X-Spam-Status: No, score=-0.322 tagged_above=-999 required=5 tests=[AWL=-0.673, BAYES_50=0.001, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rzyF1mSCOQ6H for ; Wed, 25 Aug 2010 11:21:38 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 603DB3A687E for ; Wed, 25 Aug 2010 11:21:34 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 7895A940153; Wed, 25 Aug 2010 20:22:01 +0200 (CEST) Message-ID: <4C755F46.9090809@gmail.com> Date: Wed, 25 Aug 2010 20:21:58 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca> <4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com> <4C73E2BE.3070603@gridmerge.com> In-Reply-To: <4C73E2BE.3070603@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 100825-0, 25/08/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit (was: Unresolved issues with RPL-11: security section.) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 18:21:47 -0000 [Robert, I now copy the list, my answer is inline] Le 24/08/2010 17:18, Robert Cragie RC3 wrote, and I wrote earlier : [...] >> All RPL messages are Control - they're Next Header 58 field in the >> IPv6 Base Header. >> >> There's no such thing as RPL "data" message, which you seem to >> imply. > On the contrary. I am saying there are *only* RPL control > messages that need to be secured, hence limiting the variability in > the IP header. Each message can be inspected and understood from a > security point of view. In a sense I agree. But let me stress that there are no other RPL messages than control messages. >> Besides, all IPv6 messages (containing ICMP or any other payload >> like TCP, UDP) have this Hop Limit which gets decremented >> mandatorily. > I agree that mutable fields in multi-hopped messages need to be > looked at more carefully. This includes DAO (recently promoted to > multihop) and DAO ACK. >> >> The security in RPL is Broken. > I agree that not enough thought has been given to the > individual RPL control messages and their needs from a point of view > of security If you imply that much thought was given to the non-RPL messages (i.e. not control, but data as seen by the link layer - be that IP or IPX) - I agree with that. >> Because >> >> There is no means for the receiver to check the integrity of the >> received message, because the Hop Limit field is mutable. >> >> Example: >> >> sender sends this message: IP_Base_Header[Hop Limit] | >> ICMP_RPL_Header[MAC] >> >> Upon reception, there is no means to re-compute the MAC because it >> doesn't know what was the initial Hop Limit used by the sender to >> compute the MAC. >> >> The Hop Limit is a field present in every IPv6 message, be it ICMP, >> UDP, TCP - even for no protocol. It is in the Base Header of IPv6. >> The Hop Limit is set by the Sender to some value the sender wants >> to travel. Every intermediary hop decrements it and discards the >> packet if it gets to 0 and this is not the Dst address. > So, there are two solutions: > > 1) Resecure at every hop (more like link layer security) 2) Remove > mutable fields from MAC calculation (more like IPSec AH) > > (1) is OK if you trust all the nodes you are hopping through, which > is not unreasonable for e.g. a lowpan. Well, for IP it's risky to assume that all nodes you hop through sit on the same link. IP is for Internet, the sensor querier is most likely not another sensor, likely to sit outside the lowpan. Then, re-securing at every hop would mean that these low-power lowpan nodes have to compute MAC prior to forwarding each packet. This may be considerable load(?) > (2) [Remove mutable fields from MAC calculation] is more complicated > but provides end-to-end security on the immutable fields. Removing Hop Limit from the MAC computation is one possibility, it provides some security. I am curious though whether IPsec AH provides protection for the Hop Limit too. Another possibility is to make the MAC (Message Auth Code) calculation to cover only the... MAC (IEEE Medium Access Control) headers, and include that MAC value in the IEEE header (not in an RPL header). In this way MAC doesn't worry about mutable/immutable IP fields. "mutable but predictable" of IPv6: If we knew that some IEEE header could securily carry a field containing "IP hops travelled" then we could probably restore it to Hop Limit when going out of the lowpan. Current RPL security is not implementable, at least because of the absence of treatment of mutable fields (RPL says Hop Limit MUST be decremented, Security section says it is covered by MAC). Any thoughts appreciated. Alex > >> >> Alex >> >>>> >>>> Robert> in but that is processed at every hop therefore is >>>> resecured Robert> at every hop. With regard to checksum, this >>>> is calculated Robert> prior to securing the message. Flow label >>>> - I too would Robert> guess 0 as these are control messages. >>>> >>>> Robert> I agree a sample packet would be useful along with >>>> Robert> securing/unsecuring steps. >>>> >>> >>> >>> _______________________________________________ Roll mailing >>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >> >> From rodolfo@ubilogix.com Wed Aug 25 13:40:11 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8E023A691A for ; Wed, 25 Aug 2010 13:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N2CM+1QjaV+c for ; Wed, 25 Aug 2010 13:40:10 -0700 (PDT) Received: from dpmailmta03.doteasy.com (dpmailmta03-17.doteasy.com [65.61.218.57]) by core3.amsl.com (Postfix) with ESMTP id 7E1353A68C2 for ; Wed, 25 Aug 2010 13:40:10 -0700 (PDT) Received: from dpmail31pro.doteasy.com ([192.168.101.31]) by dpmailrp06.doteasy.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7PKeW3Y002858; Wed, 25 Aug 2010 13:40:32 -0700 Received: from 189.222.82.34.dsl.dyn.telnor.net [189.222.82.34] by dpmail31pro.doteasy.com with SMTP; Wed, 25 Aug 2010 13:40:18 -0700 Message-ID: <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> From: "Rodolfo Gonzalez Bernaldez" To: "Alexandru Petrescu" , References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> In-Reply-To: <4C755F46.9090809@gmail.com> Date: Wed, 25 Aug 2010 13:40:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: No geolocation information available for 192.168.101.31 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 01CWIEw32 - 2e1fcc4cb184 X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.86 X-Originating-IP: 192.168.101.86 Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit (was: Unresolved issues with RPL-11: security section.) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 20:40:11 -0000 Hello Alex, Robert, all. > "Current RPL security is not implementable, at least because of the > absence of treatment of mutable fields (RPL says Hop Limit MUST be > decremented, Security section says it is covered by MAC)." If the only problem is the mutable fields of IPv6 header (6LoWPAN, IPv6, IPHC, etc), why don't we have it specified in a security section something like this?: "ccm* computation doesn't include IPv6 header, neither include IPv6 extension headers" In my opinion the content of IPv6 header doesn't provide any critical information for security, and with this, we are avoiding these fields for the CBC-MAC calculation in a very clear way. Best regards Rodolfo. -------------------------------------------------- From: "Alexandru Petrescu" Sent: Wednesday, August 25, 2010 11:21 AM To: Cc: "ROLL WG" Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit (was: Unresolved issues with RPL-11: security section.) > [Robert, I now copy the list, my answer is inline] > > Le 24/08/2010 17:18, Robert Cragie RC3 wrote, and I wrote earlier : > [...] >>> All RPL messages are Control - they're Next Header 58 field in the >>> IPv6 Base Header. >>> >>> There's no such thing as RPL "data" message, which you seem to >>> imply. >> On the contrary. I am saying there are *only* RPL control >> messages that need to be secured, hence limiting the variability in >> the IP header. Each message can be inspected and understood from a >> security point of view. > > In a sense I agree. But let me stress that there are no other RPL > messages than control messages. > >>> Besides, all IPv6 messages (containing ICMP or any other payload >>> like TCP, UDP) have this Hop Limit which gets decremented >>> mandatorily. >> I agree that mutable fields in multi-hopped messages need to be >> looked at more carefully. This includes DAO (recently promoted to >> multihop) and DAO ACK. >>> >>> The security in RPL is Broken. >> I agree that not enough thought has been given to the >> individual RPL control messages and their needs from a point of view >> of security > > If you imply that much thought was given to the non-RPL messages (i.e. > not control, but data as seen by the link layer - be that IP or IPX) - I > agree with that. > >>> Because >>> >>> There is no means for the receiver to check the integrity of the >>> received message, because the Hop Limit field is mutable. >>> >>> Example: >>> >>> sender sends this message: IP_Base_Header[Hop Limit] | >>> ICMP_RPL_Header[MAC] >>> >>> Upon reception, there is no means to re-compute the MAC because it >>> doesn't know what was the initial Hop Limit used by the sender to >>> compute the MAC. >>> >>> The Hop Limit is a field present in every IPv6 message, be it ICMP, >>> UDP, TCP - even for no protocol. It is in the Base Header of IPv6. >>> The Hop Limit is set by the Sender to some value the sender wants >>> to travel. Every intermediary hop decrements it and discards the >>> packet if it gets to 0 and this is not the Dst address. >> So, there are two solutions: >> >> 1) Resecure at every hop (more like link layer security) 2) Remove >> mutable fields from MAC calculation (more like IPSec AH) >> >> (1) is OK if you trust all the nodes you are hopping through, which >> is not unreasonable for e.g. a lowpan. > > Well, for IP it's risky to assume that all nodes you hop through sit on > the same link. IP is for Internet, the sensor querier is most likely > not another sensor, likely to sit outside the lowpan. > > Then, re-securing at every hop would mean that these low-power lowpan > nodes have to compute MAC prior to forwarding each packet. This may be > considerable load(?) > >> (2) [Remove mutable fields from MAC calculation] is more complicated >> but provides end-to-end security on the immutable fields. > > Removing Hop Limit from the MAC computation is one possibility, it > provides some security. I am curious though whether IPsec AH provides > protection for the Hop Limit too. > > Another possibility is to make the MAC (Message Auth Code) calculation > to cover only the... MAC (IEEE Medium Access Control) headers, and > include that MAC value in the IEEE header (not in an RPL header). In > this way MAC doesn't worry about mutable/immutable IP fields. > > "mutable but predictable" of IPv6: If we knew that some IEEE header > could securily carry a field containing "IP hops travelled" then we > could probably restore it to Hop Limit when going out of the lowpan. > > Current RPL security is not implementable, at least because of the > absence of treatment of mutable fields (RPL says Hop Limit MUST be > decremented, Security section says it is covered by MAC). > > Any thoughts appreciated. > > Alex > >> >>> >>> Alex >>> >>>>> >>>>> Robert> in but that is processed at every hop therefore is >>>>> resecured Robert> at every hop. With regard to checksum, this >>>>> is calculated Robert> prior to securing the message. Flow label >>>>> - I too would Robert> guess 0 as these are control messages. >>>>> >>>>> Robert> I agree a sample packet would be useful along with >>>>> Robert> securing/unsecuring steps. >>>>> >>>> >>>> >>>> _______________________________________________ Roll mailing >>>> list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll >>> >>> > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Wed Aug 25 15:46:13 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D28193A6942 for ; Wed, 25 Aug 2010 15:46:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.189 X-Spam-Level: X-Spam-Status: No, score=-0.189 tagged_above=-999 required=5 tests=[AWL=-0.835, BAYES_50=0.001, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q73adWF7sgoo for ; Wed, 25 Aug 2010 15:46:13 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id DB2373A6835 for ; Wed, 25 Aug 2010 15:46:12 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [66.78.105.13]) by relay.sandelman.ca (Postfix) with ESMTPS id 3653C3447C; Wed, 25 Aug 2010 18:46:45 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 76C4798A94; Wed, 25 Aug 2010 18:46:42 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <4C7273DB.5080306@gridmerge.com> References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca> <4C7273DB.5080306@gridmerge.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 25 Aug 2010 18:46:42 -0400 Message-ID: <30091.1282776402@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] section 3.3.3: channel binding issue for link-layer security X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 22:46:13 -0000 I spoke to Robert by phone this morning (sorry for my crappy headset, I was on a train...) to try to understand where the disconnect in understanding is. This is what I propose to write in section 3.3.3: 3.3.3. Security RPL supports a built-in message confidentiality and integrity. It is designed for situations where link-layer mechanisms can not be used, or where they do not exist. For some deployment scenarios (cf applicability statements), link-layer security can be used. 3.3.3.1 Built-in Security When using the built-in security, RPL has three basic security modes: In the first, called "unsecured," RPL control messages are sent without any additional security mechanisms. Unsecured mode does not imply that the RPL network is unsecure: it could be using other present security primitives (e.g. link-layer security) to meet application security requirements. In the second, called "pre-installed," nodes joining a RPL Instance have pre-installed keys that enable them to process and generate secured RPL messages. The third mode is called "authenticated." In authenticated mode, nodes have pre-installed keys as in pre-installed mode, but the pre- installed key may only be used to join a RPL Instance as a leaf. "Authenticated" vs "pre-installed" is determined by the 'A' flag in the DODAG configuration option (section 6.7.6) in the DIO message. As these messages are protected by an encryption and authentication key, which the leaf node may not posess, the RPL instance joining as a leaf may need to issue a DODAG Information Solicitation message to request that RPL routers send DIO messages with the appropriate "pre-installed" keys that the leaf node possesses. In scenarios where asymmetric signature mechanisms are used, and no privacy protection is used, then the leaf node may be able to validate the DIO message without sending a DIS. To joining an authenticated RPL Instance as a router requires obtaining a symmetric key from an authentication authority. To join using an asymetric key may involve interaction with some kind of authorization authority. The processes by which these keys/certificates are obtained is outside the scope of this specification. 3.3.3.2 Link-Layer security The details of using link-layer security with RPL is subject to a detailed explanation for each link-layer supported. For many link-layers it is an all-or-nothing connection: the lower layers may not support providing information to upper layers about which encryption/authentication keys were used for reception, and they may not provide any controls to determine which ones will be used for transmission. This is a common situation for devices with radios connected via USB or other commodity buses, where the radio in question simply presents itself as ethernet. For such situations, the DODAG is considered to be in "pre-installed" mode, and the 'A' bit in the DODAG configuration option should be cleared. From mcr@sandelman.ca Wed Aug 25 15:48:26 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4FDB83A695E for ; Wed, 25 Aug 2010 15:48:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.911 X-Spam-Level: X-Spam-Status: No, score=-0.911 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnWSnWR2TQM2 for ; Wed, 25 Aug 2010 15:48:25 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 6569D3A695D for ; Wed, 25 Aug 2010 15:48:25 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [66.78.105.13]) by relay.sandelman.ca (Postfix) with ESMTPS id 334B63452E; Wed, 25 Aug 2010 18:48:58 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 61FC998A94; Wed, 25 Aug 2010 18:48:57 -0400 (EDT) From: Michael Richardson To: "Rodolfo Gonzalez Bernaldez" In-Reply-To: <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 25 Aug 2010 18:48:57 -0400 Message-ID: <30160.1282776537@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit (was: Unresolved issues with RPL-11: security section.) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 22:48:26 -0000 >>>>> "Rodolfo" == Rodolfo Gonzalez Bernaldez writes: Rodolfo> If the only problem is the mutable fields of IPv6 header Rodolfo> (6LoWPAN, IPv6, IPHC, etc), why don't we have it specified Rodolfo> in a security section something like this?: Rodolfo> "ccm* computation doesn't include IPv6 header, neither Rodolfo> include IPv6 extension headers" Rodolfo> In my opinion the content of IPv6 header doesn't provide Rodolfo> any critical information for security, and with this, we Rodolfo> are avoiding these fields for the CBC-MAC calculation in a Rodolfo> very clear way. The IPv6 source address is used in a number of places that are important. It may be that changes (forgeries) have no significant impact, but I do not believe that we are at that point in understanding to state this. My preference is instead to simply reference rfc4302 (by reference or by copy&paste of text), and use those rules. They are well explained, and in some cases, can leverage hardware that already exists. -- ] 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 Wed Aug 25 17:24:56 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ADD4B3A68D2 for ; Wed, 25 Aug 2010 17:24:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.115 X-Spam-Level: X-Spam-Status: No, score=-0.115 tagged_above=-999 required=5 tests=[AWL=-0.575, BAYES_40=-0.185, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O-PvSvtT2lxp for ; Wed, 25 Aug 2010 17:24:55 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 9F9C33A68CC for ; Wed, 25 Aug 2010 17:24:55 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [66.78.105.13]) by relay.sandelman.ca (Postfix) with ESMTPS id 4266634468 for ; Wed, 25 Aug 2010 20:25:28 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 8D6AF98A94 for ; Wed, 25 Aug 2010 20:25:27 -0400 (EDT) From: Michael Richardson To: roll@ietf.org X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 25 Aug 2010 20:25:27 -0400 Message-ID: <8455.1282782327@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 00:24:56 -0000 An RPL node which is participating in multiple DODAGs will have multiple Trickle timers. It will send out a DIO for each DODAG if necessary. However, it seems that there is some advantage to transmitting multiple packets at the same time --- you can be more sleepy, and it helps other nodes be more sleepy. As such it seems that whenever possible, if a node already has picked a value "t" which is consistent with multiple DODAG's [I/2,I) ranges, that it should use the same value t across all DODAGs. For a machine with multiple interfaces (e.g. multiple radios on different frequencies, or even different media types), that it should in fact keep a DODAG Trickle Timer *per disjoint interface*. Does this make sense? -- ] 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 pal@cs.stanford.edu Wed Aug 25 19:03:55 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9DDFB3A6A65 for ; Wed, 25 Aug 2010 19:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.281 X-Spam-Level: X-Spam-Status: No, score=-5.281 tagged_above=-999 required=5 tests=[AWL=-1.282, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eUgW0PM-PzDz for ; Wed, 25 Aug 2010 19:03:54 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id A5E363A69E8 for ; Wed, 25 Aug 2010 19:03:54 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.127]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OoRpL-0008OD-7E; Wed, 25 Aug 2010 19:04:27 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <8455.1282782327@marajade.sandelman.ca> Date: Wed, 25 Aug 2010 19:04:26 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> References: <8455.1282782327@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 2e2010fe0da008b9f5e122b86dc99621 Cc: roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 02:03:55 -0000 On Aug 25, 2010, at 5:25 PM, Michael Richardson wrote: >=20 > An RPL node which is participating in multiple DODAGs will have = multiple > Trickle timers. It will send out a DIO for each DODAG if necessary. >=20 > However, it seems that there is some advantage to transmitting = multiple > packets at the same time --- you can be more sleepy, and it helps = other > nodes be more sleepy. >=20 > As such it seems that whenever possible, if a node already has picked = a > value "t" which is consistent with multiple DODAG's [I/2,I) ranges, = that > it should use the same value t across all DODAGs. >=20 > For a machine with multiple interfaces (e.g. multiple radios on > different frequencies, or even different media types), that it should = in > fact keep a DODAG Trickle Timer *per disjoint interface*. >=20 > Does this make sense? Just to be sure -- you just suggesting the optimization that when a node = transmits a DIO, it checks if the current time falls within the = intervals of any of its other DODAG timers, and if so, assumes t is that = value (still applies the suppression invariant)? One issue this raises = is that if some nodes are members of more DODAGs than others, they will = transmit more often: they're basically selecting the minimum t across = their intervals. The operating assumption here seems to be that sending multiple = multicast messages back-to-back is less expensive than spacing them out = over time. This isn't always true (depends on the link layer). Phil= From mcr@sandelman.ca Wed Aug 25 19:18:16 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABF883A68EA for ; Wed, 25 Aug 2010 19:18:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.711 X-Spam-Level: X-Spam-Status: No, score=-1.711 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9t9jPBahZw4V for ; Wed, 25 Aug 2010 19:18:15 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 782613A68C3 for ; Wed, 25 Aug 2010 19:18:15 -0700 (PDT) Received: from marajade.sandelman.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id 71DFA34463; Wed, 25 Aug 2010 22:18:47 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id A6AF198A94; Wed, 25 Aug 2010 22:18:46 -0400 (EDT) From: Michael Richardson To: Philip Levis In-Reply-To: <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Wed, 25 Aug 2010 22:18:46 -0400 Message-ID: <11260.1282789126@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 02:18:16 -0000 >>>>> "Philip" == Philip Levis writes: >> An RPL node which is participating in multiple DODAGs will have >> multiple Trickle timers. It will send out a DIO for each DODAG >> if necessary. >> >> However, it seems that there is some advantage to transmitting >> multiple packets at the same time --- you can be more sleepy, and >> it helps other nodes be more sleepy. >> >> As such it seems that whenever possible, if a node already has >> picked a value "t" which is consistent with multiple DODAG's >> [I/2,I) ranges, that it should use the same value t across all >> DODAGs. >> >> For a machine with multiple interfaces (e.g. multiple radios on >> different frequencies, or even different media types), that it >> should in fact keep a DODAG Trickle Timer *per disjoint >> interface*. >> >> Does this make sense? Philip> Just to be sure -- you just suggesting the optimization that Philip> when a node transmits a DIO, it checks if the current time Philip> falls within the intervals of any of its other DODAG timers, Philip> and if so, assumes t is that value (still applies the Philip> suppression invariant)? One issue this raises is that if Philip> some nodes are members of more DODAGs than others, they will Philip> transmit more often: they're basically selecting the minimum Philip> t across their intervals. That wasn't how I was thinking of implementing it. Rather, instead of always picking a "random" t, I'd look at all the existing t values for all the DODAGs that I'm a member of, and if one of them satisfies [I/2,I), then I use that. If not, then I pick it randomly as before. Philip> The operating assumption here seems to be that sending Philip> multiple multicast messages back-to-back is less expensive Philip> than spacing them out over time. This isn't always true Philip> (depends on the link layer). yes, that's my assumption. It's certainly cheaper in terms of CPU power budget, as when you wake up, it's best to get rid of as much work as possible and then go back to sleep. If it's not true of some link layers, I'd like to understand this better. -- ] 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 pal@cs.stanford.edu Wed Aug 25 19:57:15 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BF553A68F9 for ; Wed, 25 Aug 2010 19:57:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.532 X-Spam-Level: X-Spam-Status: No, score=-6.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nN7ur3QFaOpp for ; Wed, 25 Aug 2010 19:57:14 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 47EF63A6847 for ; Wed, 25 Aug 2010 19:57:14 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OoSew-0002o9-Ux; Wed, 25 Aug 2010 19:57:47 -0700 In-Reply-To: <11260.1282789126@marajade.sandelman.ca> References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> <11260.1282789126@marajade.sandelman.ca> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Levis Date: Wed, 25 Aug 2010 19:56:26 -0700 To: Michael Richardson X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 8577cc8f8d13cb4ae2b02fc82e253015 Cc: roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 02:57:15 -0000 On Aug 25, 2010, at 7:18 PM, Michael Richardson wrote: > >>>>>> "Philip" == Philip Levis writes: >>> An RPL node which is participating in multiple DODAGs will have >>> multiple Trickle timers. It will send out a DIO for each DODAG >>> if necessary. >>> >>> However, it seems that there is some advantage to transmitting >>> multiple packets at the same time --- you can be more sleepy, and >>> it helps other nodes be more sleepy. >>> >>> As such it seems that whenever possible, if a node already has >>> picked a value "t" which is consistent with multiple DODAG's >>> [I/2,I) ranges, that it should use the same value t across all >>> DODAGs. >>> >>> For a machine with multiple interfaces (e.g. multiple radios on >>> different frequencies, or even different media types), that it >>> should in fact keep a DODAG Trickle Timer *per disjoint >>> interface*. >>> >>> Does this make sense? > > Philip> Just to be sure -- you just suggesting the optimization > that > Philip> when a node transmits a DIO, it checks if the current time > Philip> falls within the intervals of any of its other DODAG > timers, > Philip> and if so, assumes t is that value (still applies the > Philip> suppression invariant)? One issue this raises is that if > Philip> some nodes are members of more DODAGs than others, they > will > Philip> transmit more often: they're basically selecting the > minimum > Philip> t across their intervals. > > That wasn't how I was thinking of implementing it. > > Rather, instead of always picking a "random" t, I'd look at all the > existing t values for all the DODAGs that I'm a member of, and if > one of > them satisfies [I/2,I), then I use that. If not, then I pick it > randomly as before. > > Philip> The operating assumption here seems to be that sending > Philip> multiple multicast messages back-to-back is less expensive > Philip> than spacing them out over time. This isn't always true > Philip> (depends on the link layer). > > yes, that's my assumption. > It's certainly cheaper in terms of CPU power budget, as when you wake > up, it's best to get rid of as much work as possible and then go > back to > sleep. If it's not true of some link layers, I'd like to understand > this better. In most LLN devices I've seen/used/measured, under reasonable workloads, CPU energy costs are negligible. Sure, you can burn CPU energy by doing AES in software, but the cost of an interrupt is really insignificant. The dominant cost is networking. Phil From jpv@cisco.com Wed Aug 25 23:22:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E80D53A6947 for ; Wed, 25 Aug 2010 23:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.416 X-Spam-Level: X-Spam-Status: No, score=-110.416 tagged_above=-999 required=5 tests=[AWL=0.182, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jvNNgEy3XJi2 for ; Wed, 25 Aug 2010 23:22:03 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 28C103A6403 for ; Wed, 25 Aug 2010 23:22:03 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhcFACOldUyrR7Hu/2dsb2JhbACBQ55+cZ9Bm1iFNwSKAoJz X-IronPort-AV: E=Sophos;i="4.56,272,1280707200"; d="scan'208,217";a="245472176" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 26 Aug 2010 06:22:35 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o7Q6MYbT007641 for ; Thu, 26 Aug 2010 06:22:35 GMT Received: from xfe-ams-201.cisco.com ([144.254.231.95]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Aug 2010 08:22:34 +0200 Received: from ams-jvasseur-8712.cisco.com ([10.55.201.131]) by xfe-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 26 Aug 2010 08:22:34 +0200 Message-Id: From: JP Vasseur To: ROLL WG Content-Type: multipart/alternative; boundary=Apple-Mail-42--446125910 Mime-Version: 1.0 (Apple Message framework v936) Date: Thu, 26 Aug 2010 08:22:31 +0200 X-Mailer: Apple Mail (2.936) X-OriginalArrivalTime: 26 Aug 2010 06:22:34.0146 (UTC) FILETIME=[12117820:01CB44E7] Subject: [Roll] New ROLL WG Document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 06:22:04 -0000 --Apple-Mail-42--446125910 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Dear all, There was a good support to support draft-dt-roll-p2p-rpl-02.txt as a new ROLL WG document. Authors, please resubmit as draft-ietf-roll-p2p-rpl-00.txt. Thanks. JP. --Apple-Mail-42--446125910 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Dear all,

There was a good support to support draft-dt-roll-p2p-rpl-02.txt as a new ROLL WG document.
Authors, please resubmit as draft-ietf-roll-p2p-rpl-00.txt.

Thanks.

JP.
--Apple-Mail-42--446125910-- From alexandru.petrescu@gmail.com Thu Aug 26 02:20:26 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804163A68AD for ; Thu, 26 Aug 2010 02:20:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.138 X-Spam-Level: X-Spam-Status: No, score=-2.138 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8nrCK3aSxpzY for ; Thu, 26 Aug 2010 02:20:24 -0700 (PDT) Received: from cirse-out.extra.cea.fr (cirse-out.extra.cea.fr [132.166.172.106]) by core3.amsl.com (Postfix) with ESMTP id 756173A6403 for ; Thu, 26 Aug 2010 02:20:20 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by cirse.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o7Q9KpeC030795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Aug 2010 11:20:52 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o7Q9Kpdc030625; Thu, 26 Aug 2010 11:20:51 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o7Q9Kpdw029714; Thu, 26 Aug 2010 11:20:51 +0200 Message-ID: <4C7631F3.2040409@gmail.com> Date: Thu, 26 Aug 2010 11:20:51 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rodolfo Gonzalez Bernaldez References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> In-Reply-To: <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 09:20:26 -0000 Le 25/08/2010 22:40, Rodolfo Gonzalez Bernaldez a écrit : > Hello Alex, Robert, all. > > >> "Current RPL security is not implementable, at least because of the >> absence of treatment of mutable fields (RPL says Hop Limit MUST be >> decremented, Security section says it is covered by MAC)." > > > If the only problem is the mutable fields of IPv6 header (6LoWPAN, > IPv6, IPHC, etc), why don't we have it specified in a security > section something like this?: > > "ccm* computation doesn't include IPv6 header, neither include IPv6 > extension headers" Sounds possible. In this way the RPL specific security mechanism would cover only the RPL headers, not the IPv6 base headers, nor the IPv6 Extension Headers. This is a quick way. On another hand, risks do exist in the base header (spoofing the src address is one widely known). It is thus good to use AH to protect it. RPL text would simply refer to rfc4302, and implementations of AH exist. I support this. If we do so (RPL MAC covers RPL only, AH covers all headers) then we may face another potential issue: who is computed first the RPL MAC? Or the AH ICV (integrity computation value, similar to Message Auth Code)? Because AH covers all the headers, RPL included. These are some of the tradeoffs involved. I now personally prefer to simply refer to AH, only. Comments welcome. Alex > > In my opinion the content of IPv6 header doesn't provide any > critical information for security, and with this, we are avoiding > these fields for the CBC-MAC calculation in a very clear way. > > Best regards Rodolfo. > > -------------------------------------------------- From: "Alexandru > Petrescu" Sent: Wednesday, August 25, > 2010 11:21 AM To: Cc: "ROLL WG" > Subject: Re: [Roll] Messg Auth Code covering the > mutable IP Hop Limit (was: Unresolved issues with RPL-11: security > section.) > >> [Robert, I now copy the list, my answer is inline] >> >> Le 24/08/2010 17:18, Robert Cragie RC3 wrote, and I wrote earlier : >> [...] >>>> All RPL messages are Control - they're Next Header 58 field in >>>> the IPv6 Base Header. >>>> >>>> There's no such thing as RPL "data" message, which you seem to >>>> imply. >>> On the contrary. I am saying there are *only* RPL control >>> messages that need to be secured, hence limiting the variability >>> in the IP header. Each message can be inspected and understood >>> from a security point of view. >> >> In a sense I agree. But let me stress that there are no other RPL >> messages than control messages. >> >>>> Besides, all IPv6 messages (containing ICMP or any other >>>> payload like TCP, UDP) have this Hop Limit which gets >>>> decremented mandatorily. >>> I agree that mutable fields in multi-hopped messages need >>> to be looked at more carefully. This includes DAO (recently >>> promoted to multihop) and DAO ACK. >>>> >>>> The security in RPL is Broken. >>> I agree that not enough thought has been given to the >>> individual RPL control messages and their needs from a point of >>> view of security >> >> If you imply that much thought was given to the non-RPL messages >> (i.e. not control, but data as seen by the link layer - be that IP >> or IPX) - I agree with that. >> >>>> Because >>>> >>>> There is no means for the receiver to check the integrity of >>>> the received message, because the Hop Limit field is mutable. >>>> >>>> Example: >>>> >>>> sender sends this message: IP_Base_Header[Hop Limit] | >>>> ICMP_RPL_Header[MAC] >>>> >>>> Upon reception, there is no means to re-compute the MAC >>>> because it doesn't know what was the initial Hop Limit used by >>>> the sender to compute the MAC. >>>> >>>> The Hop Limit is a field present in every IPv6 message, be it >>>> ICMP, UDP, TCP - even for no protocol. It is in the Base >>>> Header of IPv6. The Hop Limit is set by the Sender to some >>>> value the sender wants to travel. Every intermediary hop >>>> decrements it and discards the packet if it gets to 0 and this >>>> is not the Dst address. >>> So, there are two solutions: >>> >>> 1) Resecure at every hop (more like link layer security) 2) >>> Remove mutable fields from MAC calculation (more like IPSec AH) >>> >>> (1) is OK if you trust all the nodes you are hopping through, >>> which is not unreasonable for e.g. a lowpan. >> >> Well, for IP it's risky to assume that all nodes you hop through >> sit on the same link. IP is for Internet, the sensor querier is >> most likely not another sensor, likely to sit outside the lowpan. >> >> Then, re-securing at every hop would mean that these low-power >> lowpan nodes have to compute MAC prior to forwarding each packet. >> This may be considerable load(?) >> >>> (2) [Remove mutable fields from MAC calculation] is more >>> complicated but provides end-to-end security on the immutable >>> fields. >> >> Removing Hop Limit from the MAC computation is one possibility, it >> provides some security. I am curious though whether IPsec AH >> provides protection for the Hop Limit too. >> >> Another possibility is to make the MAC (Message Auth Code) >> calculation to cover only the... MAC (IEEE Medium Access Control) >> headers, and include that MAC value in the IEEE header (not in an >> RPL header). In this way MAC doesn't worry about mutable/immutable >> IP fields. >> >> "mutable but predictable" of IPv6: If we knew that some IEEE header >> could securily carry a field containing "IP hops travelled" then we >> could probably restore it to Hop Limit when going out of the >> lowpan. >> >> Current RPL security is not implementable, at least because of the >> absence of treatment of mutable fields (RPL says Hop Limit MUST be >> decremented, Security section says it is covered by MAC). >> >> Any thoughts appreciated. >> >> Alex >> >>> >>>> >>>> Alex >>>> >>>>>> >>>>>> Robert> in but that is processed at every hop therefore is >>>>>> resecured Robert> at every hop. With regard to checksum, >>>>>> this is calculated Robert> prior to securing the message. >>>>>> Flow label - I too would Robert> guess 0 as these are >>>>>> control messages. >>>>>> >>>>>> Robert> I agree a sample packet would be useful along with >>>>>> Robert> securing/unsecuring steps. >>>>>> >>>>> >>>>> >>>>> _______________________________________________ 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=84712cf5d=mukul@uwm.edu Thu Aug 26 05:23:03 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB83F3A6838 for ; Thu, 26 Aug 2010 05:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYEfxOiZ-9Z2 for ; Thu, 26 Aug 2010 05:23:02 -0700 (PDT) Received: from ip2mta.uwm.edu (ip2mta.uwm.edu [129.89.7.20]) by core3.amsl.com (Postfix) with ESMTP id F180F3A682F for ; Thu, 26 Aug 2010 05:23:01 -0700 (PDT) Received: from mta01.pantherlink.uwm.edu ([129.89.7.132]) by ip2mta.uwm.edu with ESMTP; 26 Aug 2010 07:23:34 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 5E2EDE6A7C for ; Thu, 26 Aug 2010 07:23:34 -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 aseXtQZL9bFT for ; Thu, 26 Aug 2010 07:23:33 -0500 (CDT) Received: from mail02.pantherlink.uwm.edu (mail02.pantherlink.uwm.edu [129.89.7.86]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 21350E6A87 for ; Thu, 26 Aug 2010 07:23:33 -0500 (CDT) Date: Thu, 26 Aug 2010 07:23:33 -0500 (CDT) From: Mukul Goyal To: roll Message-ID: <1424930784.136903.1282825413100.JavaMail.root@mail02.pantherlink.uwm.edu> In-Reply-To: <20100826122128.9DA783A67DB@core3.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [129.89.7.91] X-Mailer: Zimbra 6.0.7_GA_2473.RHEL5_64 (ZimbraWebClient - IE8 (Win)/6.0.7_GA_2473.RHEL5_64) X-Authenticated-User: mukul@uwm.edu Subject: [Roll] Fwd: New Version Notification for draft-ietf-roll-p2p-rpl-00 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 12:23:03 -0000 FYI ----- Forwarded Message ----- From: "IETF I-D Submission Tool" To: mukul@uwm.edu Cc: "Emmanuel Baccelli" Sent: Thursday, August 26, 2010 7:21:28 AM Subject: New Version Notification for draft-ietf-roll-p2p-rpl-00 A new version of I-D, draft-ietf-roll-p2p-rpl-00.txt has been successfully submitted by Mukul Goyal and posted to the IETF repository. Filename: draft-ietf-roll-p2p-rpl Revision: 00 Title: Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Creation_date: 2010-08-26 WG ID: roll Number_of_pages: 22 Abstract: Point to point (P2P) communication between arbitrary IPv6 routers and hosts in a Low power and Lossy Network (LLN) is a key requirement for many applications. RPL, the IPv6 Routing Protocol for LLNs, constrains the LLN topology to a Directed Acyclic Graph (DAG) and requires the P2P routing to take place along the DAG links. Such P2P routes may be significantly suboptimal and may lead to traffic congestion near the DAG root. This document describes a P2P route discovery mechanism complementary to RPL base functionality. This mechanism allows an RPL-aware IPv6 router or host to discover and establish on demand one or more routes to another RPL-aware IPv6 router or host in the LLN such that the discovered routes meet the specified cost criteria. The IETF Secretariat. From root@core3.amsl.com Thu Aug 26 05:30:04 2010 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4F7FB3A6873; Thu, 26 Aug 2010 05:30:03 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100826123004.4F7FB3A6873@core3.amsl.com> Date: Thu, 26 Aug 2010 05:30:03 -0700 (PDT) Cc: roll@ietf.org Subject: [Roll] I-D Action:draft-ietf-roll-p2p-rpl-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 12:30:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Author(s) : M. Goyal, E. Baccelli Filename : draft-ietf-roll-p2p-rpl-00.txt Pages : 22 Date : 2010-08-26 Point to point (P2P) communication between arbitrary IPv6 routers and hosts in a Low power and Lossy Network (LLN) is a key requirement for many applications. RPL, the IPv6 Routing Protocol for LLNs, constrains the LLN topology to a Directed Acyclic Graph (DAG) and requires the P2P routing to take place along the DAG links. Such P2P routes may be significantly suboptimal and may lead to traffic congestion near the DAG root. This document describes a P2P route discovery mechanism complementary to RPL base functionality. This mechanism allows an RPL-aware IPv6 router or host to discover and establish on demand one or more routes to another RPL-aware IPv6 router or host in the LLN such that the discovered routes meet the specified cost criteria. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-p2p-rpl-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-p2p-rpl-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-08-26052127.I-D@ietf.org> --NextPart-- From mcr@sandelman.ca Thu Aug 26 06:03:37 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1776B3A6970 for ; Thu, 26 Aug 2010 06:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.723 X-Spam-Level: X-Spam-Status: No, score=-1.723 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gOoP6kLNhclL for ; Thu, 26 Aug 2010 06:03:36 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 54F833A6873 for ; Thu, 26 Aug 2010 06:03:36 -0700 (PDT) Received: from marajade.sandelman.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id 5321C345AD for ; Thu, 26 Aug 2010 09:04:08 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 9AD5298A94 for ; Thu, 26 Aug 2010 09:04:07 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <11260.1282789126@marajade.sandelman.ca> References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> <11260.1282789126@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 26 Aug 2010 09:04:07 -0400 Message-ID: <21838.1282827847@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] trickle timer per interface/media X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 13:03:37 -0000 >>>>> "Michael" == Michael Richardson writes: > For a machine with multiple interfaces (e.g. multiple radios on > different frequencies, or even different media types), that it > should in fact keep a DODAG Trickle Timer *per disjoint > interface*. I wanted to repeat this (second) question. -- ] 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 Thu Aug 26 06:11:24 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE36A3A6873 for ; Thu, 26 Aug 2010 06:11:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.735 X-Spam-Level: X-Spam-Status: No, score=-1.735 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OK-nGN9SxIMf for ; Thu, 26 Aug 2010 06:11:23 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 34B753A67E2 for ; Thu, 26 Aug 2010 06:11:23 -0700 (PDT) Received: from marajade.sandelman.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id BC449345AD; Thu, 26 Aug 2010 09:11:55 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 1204598A94; Thu, 26 Aug 2010 09:11:55 -0400 (EDT) From: Michael Richardson To: Philip Levis In-Reply-To: References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> <11260.1282789126@marajade.sandelman.ca> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 26 Aug 2010 09:11:55 -0400 Message-ID: <22002.1282828315@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 13:11:24 -0000 >>>>> "Philip" == Philip Levis writes: Philip> The operating assumption here seems to be that sending Philip> multiple multicast messages back-to-back is less expensive Philip> than spacing them out over time. This isn't always true Philip> (depends on the link layer). >> yes, that's my assumption. It's certainly cheaper in terms of >> CPU power budget, as when you wake up, it's best to get rid of as >> much work as possible and then go back to sleep. If it's not >> true of some link layers, I'd like to understand this better. Philip> In most LLN devices I've seen/used/measured, under Philip> reasonable workloads, CPU energy costs are negligible. Sure, Philip> you can burn CPU energy by doing AES in software, but the Philip> cost of an interrupt is really insignificant. The dominant Philip> cost is networking. I'm not an expert, I'm going on heresay, mostly from the Linux and Android discussions about how to write applications that do not drain the battery. My reading is that this is not the experience on smartphones and laptops: waking up the CPU hurts a lot. Yes, Tx power certainly costs --- and you want to reduce it, but there is also some wake up/shutdown cost on the transmitter too. There were some people looking at whether the network stack on laptops should synchronize multiple TCP connections better, such that if a message needs to go out, it happens while the system is awake, rather than causing another resume from sleepy state. So, let me ask the question a different way: is there a DOWNSIDE to sending out DIOs for different DODAGs at the same time? Is it something that the specification should discourage? -- ] 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 Thu Aug 26 06:30:38 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 384223A682D for ; Thu, 26 Aug 2010 06:30:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.745 X-Spam-Level: X-Spam-Status: No, score=-1.745 tagged_above=-999 required=5 tests=[AWL=0.209, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E1PWKvl6o14E for ; Thu, 26 Aug 2010 06:30:37 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 254643A672E for ; Thu, 26 Aug 2010 06:30:36 -0700 (PDT) Received: from marajade.sandelman.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id 61DF734487; Thu, 26 Aug 2010 09:31:09 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 9EC2598A94; Thu, 26 Aug 2010 09:31:08 -0400 (EDT) From: Michael Richardson To: Alexandru Petrescu In-Reply-To: <4C7631F3.2040409@gmail.com> References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 26 Aug 2010 09:31:08 -0400 Message-ID: <22565.1282829468@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 13:30:38 -0000 >>>>> "Alexandru" == Alexandru Petrescu writes: Alexandru> On another hand, risks do exist in the base header Alexandru> (spoofing the src address is one widely known). It is Alexandru> thus good to use AH to protect it. RPL text would simply Alexandru> refer to rfc4302, and implementations of AH exist. I Alexandru> support this. AH does not offer any assymetric signature modes on the packet itself. It also does not offer any encryption. The right answer is for the security section to reference the RFC4302 instructions on dealing with mutable fields. -- ] 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 coflynn@newae.com Thu Aug 26 07:37:25 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B7D0B3A6994 for ; Thu, 26 Aug 2010 07:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.09 X-Spam-Level: X-Spam-Status: No, score=-2.09 tagged_above=-999 required=5 tests=[AWL=0.509, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3uBQyO9LnCVp for ; Thu, 26 Aug 2010 07:37:24 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id EE09E3A69B9 for ; Thu, 26 Aug 2010 07:37:22 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OodaQ-0008A0-KF; Thu, 26 Aug 2010 10:37:50 -0400 From: "Colin O'Flynn" To: "'Michael Richardson'" , "'Philip Levis'" References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> <11260.1282789126@marajade.sandelman.ca> <22002.1282828315@marajade.sandelman.ca> In-Reply-To: <22002.1282828315@marajade.sandelman.ca> Date: Thu, 26 Aug 2010 15:37:46 +0100 Message-ID: <00dc01cb452c$422b4280$c681c780$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActFIEWmZq/HZCvnQ9qZarQY3ZvZTgABFjrg Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 14:37:25 -0000 Hello, Philip> you can burn CPU energy by doing AES in software, but the Philip> cost of an interrupt is really insignificant. The dominant Philip> cost is networking. Philip I think you are absolutely correct here for embedded devices that RPL is primarily concerned about. Waking up the CPU isn't a big issue. Larger devices (Linux/etc) are completely different in terms of both hardware and software architecture. But the main concern should be the tiny nodes IMHO. Unless you are using synchronization between devices (which so far I don't see happening in real networks), you have no option but to do "low power listening" to receive the async transmission from other nodes. In this mode you wake up frequently, switch on the transceiver, and listen for a brief period. Since you've already waken up the CPU & radio, doing a radio transmission at that time only "costs" you the extra time to do the actual transmission. Thus probably most people would just synchronize DIO transmissions to the nearest time the radio will be active anyway. This could be every 10mS or more frequently. A quick "reality check" on the actual costs of waking up: Consider the time it takes to transmit a single message: 100 bytes at 250 kbits/second is 3.2 mS. That ignores time waiting for ACK, etc etc. At 16 MIPS you can do 51200 instructions. A micro such as the ATMega128RFA1 can wake up in 6 cycles from standby, and 210 from total power down. The radio in that micro takes a little longer though: typically going from sleep to transmitting takes in the vicinity of 0.5 mS (equiv to 8000 cycles per my last example). Still, compared to actually doing the transmission this isn't *that* long. > is there a DOWNSIDE to sending out DIOs for different DODAGs at the > same time? There is situations where there could be. For example your power source doesn't have low enough impedance to deliver the current to actually send a bunch of data back-to-back. With coin cell batteries for example you run into this problem. But I'd say it really doesn't matter and RPL shouldn't try to specify if you should or shouldn't do this optimization. It's a case of implementation optimizations specific to your link-layer, processor, and network architecture. Regards, -Colin -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson Sent: August 26, 2010 2:12 PM To: Philip Levis Cc: roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs >>>>> "Philip" == Philip Levis writes: Philip> The operating assumption here seems to be that sending Philip> multiple multicast messages back-to-back is less expensive Philip> than spacing them out over time. This isn't always true Philip> (depends on the link layer). >> yes, that's my assumption. It's certainly cheaper in terms of >> CPU power budget, as when you wake up, it's best to get rid of as >> much work as possible and then go back to sleep. If it's not >> true of some link layers, I'd like to understand this better. Philip> In most LLN devices I've seen/used/measured, under Philip> reasonable workloads, CPU energy costs are negligible. Sure, Philip> you can burn CPU energy by doing AES in software, but the Philip> cost of an interrupt is really insignificant. The dominant Philip> cost is networking. I'm not an expert, I'm going on heresay, mostly from the Linux and Android discussions about how to write applications that do not drain the battery. My reading is that this is not the experience on smartphones and laptops: waking up the CPU hurts a lot. Yes, Tx power certainly costs --- and you want to reduce it, but there is also some wake up/shutdown cost on the transmitter too. There were some people looking at whether the network stack on laptops should synchronize multiple TCP connections better, such that if a message needs to go out, it happens while the system is awake, rather than causing another resume from sleepy state. So, let me ask the question a different way: is there a DOWNSIDE to sending out DIOs for different DODAGs at the same time? Is it something that the specification should discourage? -- ] 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. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From alexandru.petrescu@gmail.com Thu Aug 26 07:42:11 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F4A43A67ED for ; Thu, 26 Aug 2010 07:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.83 X-Spam-Level: X-Spam-Status: No, score=-1.83 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PmkOGwqLHEZd for ; Thu, 26 Aug 2010 07:42:10 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 60A4B3A69B8 for ; Thu, 26 Aug 2010 07:42:10 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o7QEggje013117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Aug 2010 16:42:42 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o7QEgfnB012404; Thu, 26 Aug 2010 16:42:42 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o7QEgf4Z004432; Thu, 26 Aug 2010 16:42:41 +0200 Message-ID: <4C767D61.2050701@gmail.com> Date: Thu, 26 Aug 2010 16:42:41 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Michael Richardson References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> In-Reply-To: <22565.1282829468@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 14:42:11 -0000 Le 26/08/2010 15:31, Michael Richardson a écrit : >>>>>> "Alexandru" == Alexandru >>>>>> Petrescu writes: > Alexandru> On another hand, risks do exist in the base header > Alexandru> (spoofing the src address is one widely known). It is > Alexandru> thus good to use AH to protect it. RPL text would > simply Alexandru> refer to rfc4302, and implementations of AH exist. > I Alexandru> support this. > > AH does not offer any assymetric signature modes on the packet > itself. It also does not offer any encryption. Right, and I don'think there's anything wrong with that. Both require more computation. I think symmetric signature and authentication are sufficient here. > The right answer is for the security section to reference the > RFC4302 instructions on dealing with mutable fields. WEll, I agree mostly. But dealing with more than mutable fields. I think there are several ways of referencing RFC4302 ("AH") in the RPL spec. For example, one wouldn't appreciate to have both AH protection of the entire packet _and_ RPL CCM protection. It is redundant. Alex From pal@cs.stanford.edu Thu Aug 26 09:42:40 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 15C963A69C5 for ; Thu, 26 Aug 2010 09:42:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.534 X-Spam-Level: X-Spam-Status: No, score=-6.534 tagged_above=-999 required=5 tests=[AWL=0.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1l05mWbCw+-S for ; Thu, 26 Aug 2010 09:42:39 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 13ADA3A69AA for ; Thu, 26 Aug 2010 09:42:39 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.127]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1OofXi-0008Se-UH; Thu, 26 Aug 2010 09:43:11 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <22002.1282828315@marajade.sandelman.ca> Date: Thu, 26 Aug 2010 09:43:11 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <205614F5-4454-4C4A-AA66-FE0DC023EF99@cs.stanford.edu> References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> <11260.1282789126@marajade.sandelman.ca> <22002.1282828315@marajade.sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 2ecb59bd28923317bd193fe54b7794cd Cc: roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 16:42:40 -0000 On Aug 26, 2010, at 6:11 AM, Michael Richardson wrote: >=20 >>>>>> "Philip" =3D=3D Philip Levis writes: > Philip> The operating assumption here seems to be that sending > Philip> multiple multicast messages back-to-back is less expensive > Philip> than spacing them out over time. This isn't always true > Philip> (depends on the link layer). >=20 >>> yes, that's my assumption. It's certainly cheaper in terms of >>> CPU power budget, as when you wake up, it's best to get rid of as >>> much work as possible and then go back to sleep. If it's not >>> true of some link layers, I'd like to understand this better. >=20 > Philip> In most LLN devices I've seen/used/measured, under > Philip> reasonable workloads, CPU energy costs are negligible. = Sure, > Philip> you can burn CPU energy by doing AES in software, but the > Philip> cost of an interrupt is really insignificant. The dominant > Philip> cost is networking. >=20 > I'm not an expert, I'm going on heresay, mostly from the Linux and > Android discussions about how to write applications that do not drain > the battery. =20 >=20 > My reading is that this is not the experience on smartphones and > laptops: waking up the CPU hurts a lot. Yes, Tx power certainly costs > --- and you want to reduce it, but there is also some wake up/shutdown > cost on the transmitter too. Sure, but that's not really the device class we're interested in. The = issue you run into in CPUs (rather than MCUs) is typically wakeup = latency, combined with a high power draw. I'm not sure why you'd have a = laptop always in a deep sleep mode, running RPL. As for phones, the CPU = is expensive yes, this is why there are separate wakeup circuits. Also, = the energy behavior and profiles of mobile phone technologies is a lot = different than LLNs: single-hop networks with centralized coordinators, = etc. Regardless, if the energy cost is on the wakeup at time t, the reception = in interval I, or the transmission at time t, the key savings comes from = how I increases. The CPU is going to wake up on packet reception, and = probably spend more cycles than on a timer. Given all of the other = things a RPL node may have to do, optimizing the number of interrupts it = handles for time t is unlikely to be significant. I'd be really = interested to see an application profile where an interrupt every few = minutes/hours is a limiting energy cost. > =20 >=20 > There were some people looking at whether the network stack on laptops=20= > should synchronize multiple TCP connections better, such that if a > message needs to go out, it happens while the system is awake, rather > than causing another resume from sleepy state. >=20 > So, let me ask the question a different way: > is there a DOWNSIDE to sending out DIOs for different DODAGs at the > same time? Yes -- it unevenly balances load based on the number of DODAGs a node is = a member of. But I think this is the wrong way to go about this = discussion: the onus should be to, through experimentation, = *demonstrate* there isn't a downside. There are too many examples in = wireless of thought experiments and convincing arguments being wrong. > Is it something that the specification should discourage? Yes. The Trickle draft is actually explicit on this. The basic answer is = that Trickle is a very carefully balanced algorithm that's been tested = and evaluated for 5 or so years now. It's possible that there are ways = to improve it, but the bar to demonstrate something is an improvement is = an experimental demonstration, not a thought experiment. Phil From mcr@sandelman.ca Thu Aug 26 10:21:17 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE37D3A6A4F for ; Thu, 26 Aug 2010 10:21:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.842 X-Spam-Level: X-Spam-Status: No, score=-1.842 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bpBidl1W4Hs4 for ; Thu, 26 Aug 2010 10:21:15 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id B34E83A68DA for ; Thu, 26 Aug 2010 10:21:15 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id B87A9345B0 for ; Thu, 26 Aug 2010 13:21:47 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 00A1098A94 for ; Thu, 26 Aug 2010 13:21:46 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <205614F5-4454-4C4A-AA66-FE0DC023EF99@cs.stanford.edu> References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> <11260.1282789126@marajade.sandelman.ca> <22002.1282828315@marajade.sandelman.ca> <205614F5-4454-4C4A-AA66-FE0DC023EF99@cs.stanford.edu> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 26 Aug 2010 13:21:46 -0400 Message-ID: <4712.1282843306@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 17:21:17 -0000 >>>>> "Philip" == Philip Levis writes: Philip> Regardless, if the energy cost is on the wakeup at time t, Philip> the reception in interval I, or the transmission at time t, Philip> the key savings comes from how I increases. The CPU is going I agree. >> So, let me ask the question a different way: is there a DOWNSIDE >> to sending out DIOs for different DODAGs at the same time? Philip> Yes -- it unevenly balances load based on the number of Philip> DODAGs a node is a member of. But I think this is the wrong Philip> way to go about this discussion: the onus should be to, Philip> through experimentation, *demonstrate* there isn't a Philip> downside. There are too many examples in wireless of thought Philip> experiments and convincing arguments being wrong. I accept this view. >> Is it something that the specification should discourage? Philip> Yes. The Trickle draft is actually explicit on this. The Philip> basic answer is that Trickle is a very carefully balanced Philip> algorithm that's been tested and evaluated for 5 or so years Philip> now. It's possible that there are ways to improve it, but Philip> the bar to demonstrate something is an improvement is an Philip> experimental demonstration, not a thought experiment. I did not see anything in the Trickle draft that dealt with the question of a node that participates in multiple Trickle timers. It dealt with a single instance of Trickle. -- ] 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 Thu Aug 26 10:25:35 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 192393A6A8A for ; Thu, 26 Aug 2010 10:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hb4BYeBKEM5V for ; Thu, 26 Aug 2010 10:25:34 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 19A813A68DA for ; Thu, 26 Aug 2010 10:25:34 -0700 (PDT) Received: from marajade.sandelman.ca (unknown [132.213.238.4]) by relay.sandelman.ca (Postfix) with ESMTPS id 8B407345E7 for ; Thu, 26 Aug 2010 13:26:06 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id AB3D098A94 for ; Thu, 26 Aug 2010 13:26:05 -0400 (EDT) From: Michael Richardson To: roll@ietf.org In-Reply-To: <00dc01cb452c$422b4280$c681c780$@com> References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> <11260.1282789126@marajade.sandelman.ca> <22002.1282828315@marajade.sandelman.ca> <00dc01cb452c$422b4280$c681c780$@com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Thu, 26 Aug 2010 13:26:05 -0400 Message-ID: <4791.1282843565@marajade.sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 17:25:35 -0000 >>>>> "Colin" == Colin O'Flynn writes: Colin> Hello, Thanks for the well thought our reply. >> is there a DOWNSIDE to sending out DIOs for different DODAGs at >> the same time? Colin> There is situations where there could be. For example your Colin> power source doesn't have low enough impedance to deliver the Colin> current to actually send a bunch of data back-to-back. With Colin> coin cell batteries for example you run into this problem. I agree that this is a problem for the transmitter, and the transmitter needs to know how much (well, what intensity...) work it can do before it needs to sleep again. I should have asked: is there a DOWNSIDE for the receivers or the network stability if a sender who is a member of multiple DODAGs, decides to send out the DIOs for these different DODAGs at the same time? -- ] 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 pal@cs.stanford.edu Thu Aug 26 13:19:58 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D9A5D3A6AA7 for ; Thu, 26 Aug 2010 13:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pkSvZN8xBd5P for ; Thu, 26 Aug 2010 13:19:58 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 019E33A6AF6 for ; Thu, 26 Aug 2010 13:19:57 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.106]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Ooiw2-0001Xd-0o; Thu, 26 Aug 2010 13:20:30 -0700 In-Reply-To: <4712.1282843306@marajade.sandelman.ca> References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> <11260.1282789126@marajade.sandelman.ca> <22002.1282828315@marajade.sandelman.ca> <205614F5-4454-4C4A-AA66-FE0DC023EF99@cs.stanford.edu> <4712.1282843306@marajade.sandelman.ca> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <10A77745-ABAE-40EC-83A0-FEF0445F481A@cs.stanford.edu> Content-Transfer-Encoding: 7bit From: Philip Levis Date: Thu, 26 Aug 2010 13:19:09 -0700 To: Michael Richardson X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: 3134a374f3853b94094f80bd9e2b84a0 Cc: roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 20:19:59 -0000 On Aug 26, 2010, at 10:21 AM, Michael Richardson wrote: > >>>>>> "Philip" == Philip Levis writes: > Philip> Regardless, if the energy cost is on the wakeup at time t, > Philip> the reception in interval I, or the transmission at > time t, > Philip> the key savings comes from how I increases. The CPU is > going > > I agree. > >>> So, let me ask the question a different way: is there a DOWNSIDE >>> to sending out DIOs for different DODAGs at the same time? > > Philip> Yes -- it unevenly balances load based on the number of > Philip> DODAGs a node is a member of. But I think this is the > wrong > Philip> way to go about this discussion: the onus should be to, > Philip> through experimentation, *demonstrate* there isn't a > Philip> downside. There are too many examples in wireless of > thought > Philip> experiments and convincing arguments being wrong. > > I accept this view. > >>> Is it something that the specification should discourage? > > Philip> Yes. The Trickle draft is actually explicit on this. The > Philip> basic answer is that Trickle is a very carefully balanced > Philip> algorithm that's been tested and evaluated for 5 or so > years > Philip> now. It's possible that there are ways to improve it, but > Philip> the bar to demonstrate something is an improvement is an > Philip> experimental demonstration, not a thought experiment. > > I did not see anything in the Trickle draft that dealt with the > question > of a node that participates in multiple Trickle timers. It dealt > with a > single instance of Trickle. Section 6.7. For the issues of multiple Trickle timers, DIP and DHV are two protocols that try to address this. They assume a specific consistency model, though, version numbers. I don't know of any work which has examined how to aggregate timers for routing protocol consistency. Phil From rodolfo@ubilogix.com Thu Aug 26 15:08:19 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAE4C3A69B1 for ; Thu, 26 Aug 2010 15:08:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.975 X-Spam-Level: X-Spam-Status: No, score=0.975 tagged_above=-999 required=5 tests=[AWL=-1.507, BAYES_40=-0.185, J_CHICKENPOX_35=0.6, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTmYTM6Vh736 for ; Thu, 26 Aug 2010 15:08:19 -0700 (PDT) Received: from dpmailmta03.doteasy.com (dpmailmta03-11.doteasy.com [65.61.218.51]) by core3.amsl.com (Postfix) with ESMTP id E09293A693B for ; Thu, 26 Aug 2010 15:08:18 -0700 (PDT) Received: from dpmail31pro.doteasy.com ([192.168.101.31]) by dpmailrp06.doteasy.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7QM8fWM017240; Thu, 26 Aug 2010 15:08:42 -0700 Received: from 189.222.82.34.dsl.dyn.telnor.net [189.222.82.34] by dpmail31pro.doteasy.com with SMTP; Thu, 26 Aug 2010 15:08:27 -0700 Message-ID: <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> From: "Rodolfo Gonzalez Bernaldez" To: "Alexandru Petrescu" , "Michael Richardson" References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> In-Reply-To: <4C767D61.2050701@gmail.com> Date: Thu, 26 Aug 2010 15:08:15 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: No geolocation information available for 192.168.101.31 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 01CXa8FUM - 4df87f0a6d67 X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.86 X-Originating-IP: 192.168.101.86 Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 22:08:20 -0000 Hello Michael, Alex, all > For example, one wouldn't appreciate to have both AH protection of the > entire packet _and_ RPL CCM protection. It is redundant. Yes I agree, that it is redundant. I was checking the RFC4302 section 3.3.3.1. Handling Mutable Fields, and I didn't see any problem to use these rules only with CCM*. What do you think of the following statements in the security section: -Any IPv6 frame with security must be prepared as RFC4302 section 3.3.3.1 specified for mutable fields -ccm* computation must take IPv6 header, and/or IPv6 extension headers as clear text, the rest of the packet must be encrypted Using these two rules statements we would be following the rules of RFC4302, providing authentication for the entire IPv6 frame, and we keeping encrypted RPL data. Best regards Rodolfo. -------------------------------------------------- From: "Alexandru Petrescu" Sent: Thursday, August 26, 2010 7:42 AM To: "Michael Richardson" Cc: "Rodolfo Gonzalez Bernaldez" ; "ROLL WG" Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit > Le 26/08/2010 15:31, Michael Richardson a écrit : >>>>>>> "Alexandru" == Alexandru >>>>>>> Petrescu writes: >> Alexandru> On another hand, risks do exist in the base header >> Alexandru> (spoofing the src address is one widely known). It is >> Alexandru> thus good to use AH to protect it. RPL text would >> simply Alexandru> refer to rfc4302, and implementations of AH exist. >> I Alexandru> support this. >> >> AH does not offer any assymetric signature modes on the packet >> itself. It also does not offer any encryption. > > Right, and I don'think there's anything wrong with that. Both require > more computation. I think symmetric signature and authentication are > sufficient here. > >> The right answer is for the security section to reference the >> RFC4302 instructions on dealing with mutable fields. > > WEll, I agree mostly. But dealing with more than mutable fields. > > I think there are several ways of referencing RFC4302 ("AH") in the RPL > spec. > > For example, one wouldn't appreciate to have both AH protection of the > entire packet _and_ RPL CCM protection. It is redundant. > > Alex > From pister@eecs.berkeley.edu Thu Aug 26 17:57:44 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CA313A6B17 for ; Thu, 26 Aug 2010 17:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11bhowAfgtAJ for ; Thu, 26 Aug 2010 17:57:43 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 1B42E3A6837 for ; Thu, 26 Aug 2010 17:57:43 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o7R0w7q6012444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 26 Aug 2010 17:58:09 -0700 (PDT) Message-ID: <4C770D9F.4080408@eecs.berkeley.edu> Date: Thu, 26 Aug 2010 17:58:07 -0700 From: Kris Pister User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: "Colin O'Flynn" , "'Philip Levis'" References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> <11260.1282789126@marajade.sandelman.ca> <22002.1282828315@marajade.sandelman.ca> <00dc01cb452c$422b4280$c681c780$@com> In-Reply-To: <00dc01cb452c$422b4280$c681c780$@com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 00:57:44 -0000 On 8/26/2010 7:37 AM, Colin O'Flynn wrote: > Hello, > > Philip> you can burn CPU energy by doing AES in software, but the > Philip> cost of an interrupt is really insignificant. The dominant > Philip> cost is networking. > > Philip I think you are absolutely correct here for embedded devices that RPL > is primarily concerned about. Waking up the CPU isn't a big issue. > > Larger devices (Linux/etc) are completely different in terms of both > hardware and software architecture. But the main concern should be the tiny > nodes IMHO. > > Unless you are using synchronization between devices (which so far I don't > see happening in real networks), Colin - if you live near a refinery, you can see a real 15.4 network running with mean time error across the entire network of less than 0.1ms . There aren't many refineries left that aren't deploying this technology (IEC62591, soon to be 802.15.4E). If you're in SF or LA, you might get a parking ticket because of such a synchronized network (sorry - it's evil, but it's a living). There's even open source code that runs on Atmel HW that you can use. Your battery impedance argument is a good one, as are Phil's, both pushing to more spread out, or at least randomized, transmissions. Phil - I agree with your anti-"thought experiment" bias. At the same time though, we're combining a lot of good tested ideas into one largely untested standard at this point. We're going to learn a lot, and some trickle-truths may turn out to be different in RPL than they are elsewhere. So I lean toward Colin's final conclusion below: leave it to the individual implementations to optimize as they see fit. ksjp > you have no option but to do "low power > listening" to receive the async transmission from other nodes. In this mode > you wake up frequently, switch on the transceiver, and listen for a brief > period. Since you've already waken up the CPU& radio, doing a radio > transmission at that time only "costs" you the extra time to do the actual > transmission. Thus probably most people would just synchronize DIO > transmissions to the nearest time the radio will be active anyway. This > could be every 10mS or more frequently. > > A quick "reality check" on the actual costs of waking up: > > Consider the time it takes to transmit a single message: 100 bytes at 250 > kbits/second is 3.2 mS. That ignores time waiting for ACK, etc etc. At 16 > MIPS you can do 51200 instructions. A micro such as the ATMega128RFA1 can > wake up in 6 cycles from standby, and 210 from total power down. > > The radio in that micro takes a little longer though: typically going from > sleep to transmitting takes in the vicinity of 0.5 mS (equiv to 8000 cycles > per my last example). Still, compared to actually doing the transmission > this isn't *that* long. > >> is there a DOWNSIDE to sending out DIOs for different DODAGs at the >> same time? > There is situations where there could be. For example your power source > doesn't have low enough impedance to deliver the current to actually send a > bunch of data back-to-back. With coin cell batteries for example you run > into this problem. > > But I'd say it really doesn't matter and RPL shouldn't try to specify if you > should or shouldn't do this optimization. It's a case of implementation > optimizations specific to your link-layer, processor, and network > architecture. > > Regards, > > -Colin From jhui@archrock.com Thu Aug 26 21:07:50 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1707B3A6966 for ; Thu, 26 Aug 2010 21:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OM9eh9Jhv7vK for ; Thu, 26 Aug 2010 21:07:49 -0700 (PDT) Received: from mail.sf.archrock.com (mail.sf.archrock.com [216.74.40.86]) by core3.amsl.com (Postfix) with ESMTP id F176F3A6962 for ; Thu, 26 Aug 2010 21:07:48 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.sf.archrock.com (Postfix) with ESMTP id 53D6EAFA2A; Thu, 26 Aug 2010 21:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at Received: from mail.sf.archrock.com ([127.0.0.1]) by localhost (mail.sf.archrock.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lL4fB+2ZFSZH; Thu, 26 Aug 2010 21:08:16 -0700 (PDT) Received: from [10.0.1.3] (adsl-71-142-90-58.dsl.pltn13.pacbell.net [71.142.90.58]) by mail.sf.archrock.com (Postfix) with ESMTP id 649EBAF8EB; Thu, 26 Aug 2010 21:08:16 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Jonathan Hui In-Reply-To: <4C770D9F.4080408@eecs.berkeley.edu> Date: Thu, 26 Aug 2010 21:08:15 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4BEAE8C3-B669-4EF1-85DA-7F262CCB25F5@archrock.com> References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> <11260.1282789126@marajade.sandelman.ca> <22002.1282828315@marajade.sandelman.ca> <00dc01cb452c$422b4280$c681c780$@com> <4C770D9F.4080408@eecs.berkeley.edu> To: Kris Pister X-Mailer: Apple Mail (2.1081) Cc: roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 04:07:50 -0000 On Aug 26, 2010, at 5:58 PM, Kris Pister wrote: > On 8/26/2010 7:37 AM, Colin O'Flynn wrote: >> Unless you are using synchronization between devices (which so far I = don't >> see happening in real networks), > Colin - if you live near a refinery, you can see a real 15.4 network = running with mean time error across the entire network of less than = 0.1ms . There aren't many refineries left that aren't deploying this = technology (IEC62591, soon to be 802.15.4E). If you're in SF or LA, you = might get a parking ticket because of such a synchronized network (sorry = - it's evil, but it's a living). There's even open source code that = runs on Atmel HW that you can use. I think it's fair to say that for most readily available radios today, = any sizable network with reasonable traffic loads must use some form of = synchronization for routers to last years on modest batteries. Not to = mention that regulations may require networks to utilize frequency = hopping. > Your battery impedance argument is a good one, as are Phil's, both = pushing to more spread out, or at least randomized, transmissions. Phil = - I agree with your anti-"thought experiment" bias. At the same time = though, we're combining a lot of good tested ideas into one largely = untested standard at this point. We're going to learn a lot, and some = trickle-truths may turn out to be different in RPL than they are = elsewhere. So I lean toward Colin's final conclusion below: leave it to = the individual implementations to optimize as they see fit. In general, I'm a big supporter of implementation-specific optimizations = for a particular link-layer. But I'd echo Phil's warning that you also = don't want to change the behavior of an algorithm. Trickle was designed = to operate in isolation - combining Trickle timers in the abstract can = be problematic. The case where all nodes combine Trickle timers in the = same way is tantamount to have a single Trickle timer, so that is not an = issue. But when different nodes combine Trickle timers in different = ways, then you can run into issues with uneven transmission load, = suppression, etc. -- Jonathan Hui From coflynn@newae.com Fri Aug 27 00:32:52 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC7203A6A24 for ; Fri, 27 Aug 2010 00:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.114 X-Spam-Level: X-Spam-Status: No, score=-2.114 tagged_above=-999 required=5 tests=[AWL=0.485, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPIzr4bG+iq9 for ; Fri, 27 Aug 2010 00:31:08 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id F15483A6823 for ; Fri, 27 Aug 2010 00:31:07 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1OotOp-0004yC-8p; Fri, 27 Aug 2010 03:30:55 -0400 From: "Colin O'Flynn" To: "'Jonathan Hui'" , "'Kris Pister'" References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> <11260.1282789126@marajade.sandelman.ca> <22002.1282828315@marajade.sandelman.ca> <00dc01cb452c$422b4280$c681c780$@com> <4C770D9F.4080408@eecs.berkeley.edu> <4BEAE8C3-B669-4EF1-85DA-7F262CCB25F5@archrock.com> In-Reply-To: <4BEAE8C3-B669-4EF1-85DA-7F262CCB25F5@archrock.com> Date: Fri, 27 Aug 2010 08:30:49 +0100 Message-ID: <001b01cb45b9$c89a8ff0$59cfafd0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActFnX44yMHHYjK0R76vQeRJZOvoowAGtKHg Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 07:33:01 -0000 Hi Jonathan & Kris, Alright, perhaps I was far too dismissive of synchronization ;-) But it would be the same point as low power listening: the devices won't wake up specifically to send a DIO, it will send the DIO when it's next awake. For synchronization you would have to wait until the next sync cycle anyway for anyone to hear you. I do agree that any optimization shouldn't change the base design of Trickle. Would it make sense to say that an implementation must specify the maximum jitter allowed? Something along the lines of when Trickle says you must transmit at time X, it means time X +/- Y. I have minimal experience with Trickle, so would be interested in learning how much would be "allowed". Such a recommendation would put an upper limit on any optimizations. This limit would also affect devices which do need to sleep by effectively limiting their sleep cycles though, so not sure if it's an overall good idea. Regards, -Colin -----Original Message----- From: Jonathan Hui [mailto:jhui@archrock.com] Sent: August 27, 2010 5:08 AM To: Kris Pister Cc: Colin O'Flynn; 'Philip Levis'; roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs On Aug 26, 2010, at 5:58 PM, Kris Pister wrote: > On 8/26/2010 7:37 AM, Colin O'Flynn wrote: >> Unless you are using synchronization between devices (which so far I don't >> see happening in real networks), > Colin - if you live near a refinery, you can see a real 15.4 network running with mean time error across the entire network of less than 0.1ms . There aren't many refineries left that aren't deploying this technology (IEC62591, soon to be 802.15.4E). If you're in SF or LA, you might get a parking ticket because of such a synchronized network (sorry - it's evil, but it's a living). There's even open source code that runs on Atmel HW that you can use. I think it's fair to say that for most readily available radios today, any sizable network with reasonable traffic loads must use some form of synchronization for routers to last years on modest batteries. Not to mention that regulations may require networks to utilize frequency hopping. > Your battery impedance argument is a good one, as are Phil's, both pushing to more spread out, or at least randomized, transmissions. Phil - I agree with your anti-"thought experiment" bias. At the same time though, we're combining a lot of good tested ideas into one largely untested standard at this point. We're going to learn a lot, and some trickle-truths may turn out to be different in RPL than they are elsewhere. So I lean toward Colin's final conclusion below: leave it to the individual implementations to optimize as they see fit. In general, I'm a big supporter of implementation-specific optimizations for a particular link-layer. But I'd echo Phil's warning that you also don't want to change the behavior of an algorithm. Trickle was designed to operate in isolation - combining Trickle timers in the abstract can be problematic. The case where all nodes combine Trickle timers in the same way is tantamount to have a single Trickle timer, so that is not an issue. But when different nodes combine Trickle timers in different ways, then you can run into issues with uneven transmission load, suppression, etc. -- Jonathan Hui From alexandru.petrescu@gmail.com Fri Aug 27 00:34:47 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71E913A6B6E for ; Fri, 27 Aug 2010 00:34:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.528 X-Spam-Level: X-Spam-Status: No, score=-1.528 tagged_above=-999 required=5 tests=[AWL=-0.479, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_35=0.6, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OQZPvNoCUW0g for ; Fri, 27 Aug 2010 00:34:42 -0700 (PDT) Received: from sainfoin-out.extra.cea.fr (sainfoin-out.extra.cea.fr [132.166.172.107]) by core3.amsl.com (Postfix) with ESMTP id 368783A6B85 for ; Fri, 27 Aug 2010 00:34:25 -0700 (PDT) Received: from pisaure.intra.cea.fr (pisaure.intra.cea.fr [132.166.88.21]) by sainfoin.extra.cea.fr (8.14.2/8.14.2/CEAnet-Internet-out-2.0) with ESMTP id o7R7Yk0a008996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 27 Aug 2010 09:34:46 +0200 Received: from muguet2.intra.cea.fr (muguet2.intra.cea.fr [132.166.192.7]) by pisaure.intra.cea.fr (8.14.4/8.14.4) with ESMTP id o7R7Yjnq003205; Fri, 27 Aug 2010 09:34:46 +0200 (envelope-from alexandru.petrescu@gmail.com) Received: from [127.0.0.1] ([132.166.133.173]) by muguet2.intra.cea.fr (8.13.8/8.13.8/CEAnet-Intranet-out-1.1) with ESMTP id o7R7YiRK019543; Fri, 27 Aug 2010 09:34:45 +0200 Message-ID: <4C776A94.7000104@gmail.com> Date: Fri, 27 Aug 2010 09:34:44 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rodolfo Gonzalez Bernaldez References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> In-Reply-To: <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 07:34:47 -0000 Le 27/08/2010 00:08, Rodolfo Gonzalez Bernaldez a écrit : > Hello Michael, Alex, all > > >> For example, one wouldn't appreciate to have both AH protection of >> the entire packet _and_ RPL CCM protection. It is redundant. > > > Yes I agree, that it is redundant. > > I was checking the RFC4302 section 3.3.3.1. Handling Mutable Fields, I think that is the right section to think of. > and I didn't see any problem to use these rules only with CCM*. Well, depends how we refer to it. Intuitively, it may be easy indeed to apply that "rfc4302 mutable field" rules to CCM*. However, this may introduce new misunderstandings too. Because that section explicitely says "IPsec": > [...] If a field is mutable, but its value at the (IPsec) receiver > is predictable, then [...] Here we don't have IPsec receivers, we have CCM* receivers - they are very different: CCM* MAC is present in ICMP headers, whereas IPsec ICV is present in Authentication Header. Thus, will that rfc4302 "If" rule apply here or not? If not, then we don't know what to do here with CCM* and mutable-but-predictable fields. We would have to specify what CCM* does with them, couldn't simply refer to rfc4302. There are several mentionings of "IPsec" in that section, and here we don't currently do IPsec. To solve that, it may lead to copy&paste that section into RPL doc and substitute "CCM* MAC" for "ICV", "RPL" for "IPsec", remove IPv4, etc. Suddenly that sounds not as a simple straight referral to rfc4302. It may lead to rewriting IPsec specs altogether. > What do you think of the following statements in the security > section: -Any IPv6 frame with security must be prepared as RFC4302 > section 3.3.3.1 specified for mutable fields Ok, sounds good as first step, for mutable fields. How about the "Mutable but Predictable Fields", i.e. dst address in presence of a Routing Header. MAC should cover them too, especially knowing that a new Routing Header is under discussion in 6MAN WG, for RPL. > -ccm* computation must take IPv6 header, and/or IPv6 extension > headers as clear text, the rest of the packet must be encrypted I kind of understand and I can agree. However, will the rest of the packet (encrypted) be also applied authentication, or just leave it encrypted. This should be clarified one way or another, so implementer knows what to implement. This again risks leading to rewriting IPsec specifications. At which point I wonder why all the effort? Wouldn't it be easier to identify what's the real core of the RPL security - is it CCM* only? If yes - could we use CCM* with IPsec Authentication Header? That may be simpler to spec and implement, rather than carrying new MAC fields in ICMP. > Using these two rules statements we would be following the rules of > RFC4302, providing authentication for the entire IPv6 frame, and we > keeping encrypted RPL data. Yes, that is one possible way of doing it. I just wanted to mention that here we have a context: a number of IPv6 fields, extension headers and other standards are present - we should consider them all. Alex > > Best regards Rodolfo. > -------------------------------------------------- From: "Alexandru > Petrescu" Sent: Thursday, August 26, > 2010 7:42 AM To: "Michael Richardson" Cc: "Rodolfo > Gonzalez Bernaldez" ; "ROLL WG" > Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop > Limit > >> Le 26/08/2010 15:31, Michael Richardson a écrit : >>>>>>>> "Alexandru" == Alexandru >>>>>>>> Petrescu writes: >>> Alexandru> On another hand, risks do exist in the base header >>> Alexandru> (spoofing the src address is one widely known). It is >>> Alexandru> thus good to use AH to protect it. RPL text would >>> simply Alexandru> refer to rfc4302, and implementations of AH >>> exist. I Alexandru> support this. >>> >>> AH does not offer any assymetric signature modes on the packet >>> itself. It also does not offer any encryption. >> >> Right, and I don'think there's anything wrong with that. Both >> require more computation. I think symmetric signature and >> authentication are sufficient here. >> >>> The right answer is for the security section to reference the >>> RFC4302 instructions on dealing with mutable fields. >> >> WEll, I agree mostly. But dealing with more than mutable fields. >> >> I think there are several ways of referencing RFC4302 ("AH") in the >> RPL spec. >> >> For example, one wouldn't appreciate to have both AH protection of >> the entire packet _and_ RPL CCM protection. It is redundant. >> >> Alex >> > > From mcr@sandelman.ca Fri Aug 27 06:05:07 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C4D43A67F3 for ; Fri, 27 Aug 2010 06:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.755 X-Spam-Level: X-Spam-Status: No, score=-1.755 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, HOST_MISMATCH_NET=0.311, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLqHc6SPIha0 for ; Fri, 27 Aug 2010 06:05:06 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [67.23.6.41]) by core3.amsl.com (Postfix) with ESMTP id 567A93A685E for ; Fri, 27 Aug 2010 06:05:05 -0700 (PDT) Received: from marajade.sandelman.ca (wlan202.sandelman.ca [209.87.252.202]) by relay.sandelman.ca (Postfix) with ESMTPS id AD779345AF; Fri, 27 Aug 2010 09:05:37 -0400 (EDT) Received: from marajade.sandelman.ca (unknown [127.0.0.1]) by marajade.sandelman.ca (Postfix) with ESMTP id 4A7AE98A94; Fri, 27 Aug 2010 09:05:36 -0400 (EDT) From: Michael Richardson To: "Colin O'Flynn" In-Reply-To: <001b01cb45b9$c89a8ff0$59cfafd0$@com> References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> <11260.1282789126@marajade.sandelman.ca> <22002.1282828315@marajade.sandelman.ca> <00dc01cb452c$422b4280$c681c780$@com> <4C770D9F.4080408@eecs.berkeley.edu> <4BEAE8C3-B669-4EF1-85DA-7F262CCB25F5@archrock.com> <001b01cb45b9$c89a8ff0$59cfafd0$@com> X-Mailer: MH-E 8.1; nmh 1.1; XEmacs 21.4 (patch 21) Date: Fri, 27 Aug 2010 09:05:36 -0400 Message-ID: <22341.1282914336@marajade.sandelman.ca> Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 13:05:07 -0000 >>>>> "Colin" == Colin O'Flynn writes: Colin> Alright, perhaps I was far too dismissive of synchronization Colin> ;-) But it would be the same point as low power listening: Colin> the devices won't wake up specifically to send a DIO, it will Colin> send the DIO when it's next awake. For synchronization you Colin> would have to wait until the next sync cycle anyway for Colin> anyone to hear you. So, my understanding is that some link layers have a network wide synchronization so that receivers wake up together so that they can hear the transmissions? That this cycle really quantizes the values of 't' that can be picked? -- ] 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 pal@cs.stanford.edu Fri Aug 27 09:52:07 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26A323A6985 for ; Fri, 27 Aug 2010 09:52:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.539 X-Spam-Level: X-Spam-Status: No, score=-6.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osnlM4Uk8Hqb for ; Fri, 27 Aug 2010 09:52:06 -0700 (PDT) Received: from cs-smtp-1.Stanford.EDU (cs-smtp-1.Stanford.EDU [171.64.64.25]) by core3.amsl.com (Postfix) with ESMTP id 40D023A6843 for ; Fri, 27 Aug 2010 09:52:06 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.127]) by cs-smtp-1.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Op2AQ-0006OR-6I; Fri, 27 Aug 2010 09:52:38 -0700 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Philip Levis In-Reply-To: <001b01cb45b9$c89a8ff0$59cfafd0$@com> Date: Fri, 27 Aug 2010 09:52:39 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <908E2D0E-1D35-4CAB-B590-E7301DFF946A@cs.stanford.edu> References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> <11260.1282789126@marajade.sandelman.ca> <22002.1282828315@marajade.sandelman.ca> <00dc01cb452c$422b4280$c681c780$@com> <4C770D9F.4080408@eecs.berkeley.edu> <4BEAE8C3-B669-4EF1-85DA-7F262CCB25F5@archrock.com> <001b01cb45b9$c89a8ff0$59cfafd0$@com> To: Colin O'Flynn X-Mailer: Apple Mail (2.1081) X-Scan-Signature: 3134a374f3853b94094f80bd9e2b84a0 Cc: roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 16:52:07 -0000 On Aug 27, 2010, at 12:30 AM, Colin O'Flynn wrote: > Hi Jonathan & Kris, >=20 > Alright, perhaps I was far too dismissive of synchronization ;-) But = it > would be the same point as low power listening: the devices won't wake = up > specifically to send a DIO, it will send the DIO when it's next awake. = For > synchronization you would have to wait until the next sync cycle = anyway for > anyone to hear you. >=20 > I do agree that any optimization shouldn't change the base design of > Trickle.=20 >=20 > Would it make sense to say that an implementation must specify the = maximum > jitter allowed? Something along the lines of when Trickle says you = must > transmit at time X, it means time X +/- Y.=20 What purpose would this serve? >=20 > I have minimal experience with Trickle, so would be interested in = learning > how much would be "allowed". Such a recommendation would put an upper = limit > on any optimizations. This limit would also affect devices which do = need to > sleep by effectively limiting their sleep cycles though, so not sure = if it's > an overall good idea. I don't think it matters. There are lots of reasons that a node might = not actually be able to transmit at time t; there is MAC backoff, after = all. As long as most Trickle intervals are much larger than the latency = the link layer introduces, it won't really disrupt the algorithm. Since = Trickle spends most of its time at large intervals (if the network is = actually in low power operation), I don't think this is a big deal. It does mean that, at very small intervals, transmitter selection may be = affected by link layer latency. This could lead to uneven transmission = loads. But since these intervals are comparatively rare, and this effect = is generally less pronounced than the application-load variations caused = by resets, I'm not sure how significant it is. Seems like a good thing = to measure in a real system, so we can better understand the problem. Phil= From coflynn@newae.com Fri Aug 27 10:10:41 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9275B3A69C5 for ; Fri, 27 Aug 2010 10:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.156 X-Spam-Level: X-Spam-Status: No, score=-2.156 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EojoBImuulx3 for ; Fri, 27 Aug 2010 10:10:36 -0700 (PDT) Received: from s034.panelboxmanager.com (s034.panelboxmanager.com [72.55.186.54]) by core3.amsl.com (Postfix) with ESMTP id 8560D3A69BF for ; Fri, 27 Aug 2010 10:10:35 -0700 (PDT) Received: from 94-193-243-129.zone7.bethere.co.uk ([94.193.243.129] helo=colinlaptop) by s034.panelboxmanager.com with esmtpa (Exim 4.69) (envelope-from ) id 1Op2SE-0003P6-FM; Fri, 27 Aug 2010 13:11:02 -0400 From: "Colin O'Flynn" To: "'Philip Levis'" References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> <11260.1282789126@marajade.sandelman.ca> <22002.1282828315@marajade.sandelman.ca> <00dc01cb452c$422b4280$c681c780$@com> <4C770D9F.4080408@eecs.berkeley.edu> <4BEAE8C3-B669-4EF1-85DA-7F262CCB25F5@archrock.com> <001b01cb45b9$c89a8ff0$59cfafd0$@com> <908E2D0E-1D35-4CAB-B590-E7301DFF946A@cs.stanford.edu> In-Reply-To: <908E2D0E-1D35-4CAB-B590-E7301DFF946A@cs.stanford.edu> Date: Fri, 27 Aug 2010 18:10:54 +0100 Message-ID: <007a01cb460a$d2026260$76072720$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActGCEKG5sjE7B9vS6WUG9gBvDf+tgAAhbRQ Content-Language: en-ca X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - s034.panelboxmanager.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - newae.com X-Source: X-Source-Args: X-Source-Dir: Cc: roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 17:10:41 -0000 Hi Phil, > I don't think it matters. Ah alright. I was trying to address the original question about synchronizing multiple DIOs. Essentially say how far an implementation can push the Trickle timer w/o "breaking" anything. Thus if it's preferable in a Linux implementation to try and aggregate sending DIOs, the implementer knows they can do this as long as you don't exceed the allowed jitter. Regards, -Colin -----Original Message----- From: Philip Levis [mailto:pal@cs.stanford.edu] Sent: August 27, 2010 5:53 PM To: Colin O'Flynn Cc: 'Jonathan Hui'; 'Kris Pister'; roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs On Aug 27, 2010, at 12:30 AM, Colin O'Flynn wrote: > Hi Jonathan & Kris, > > Alright, perhaps I was far too dismissive of synchronization ;-) But it > would be the same point as low power listening: the devices won't wake up > specifically to send a DIO, it will send the DIO when it's next awake. For > synchronization you would have to wait until the next sync cycle anyway for > anyone to hear you. > > I do agree that any optimization shouldn't change the base design of > Trickle. > > Would it make sense to say that an implementation must specify the maximum > jitter allowed? Something along the lines of when Trickle says you must > transmit at time X, it means time X +/- Y. What purpose would this serve? > > I have minimal experience with Trickle, so would be interested in learning > how much would be "allowed". Such a recommendation would put an upper limit > on any optimizations. This limit would also affect devices which do need to > sleep by effectively limiting their sleep cycles though, so not sure if it's > an overall good idea. I don't think it matters. There are lots of reasons that a node might not actually be able to transmit at time t; there is MAC backoff, after all. As long as most Trickle intervals are much larger than the latency the link layer introduces, it won't really disrupt the algorithm. Since Trickle spends most of its time at large intervals (if the network is actually in low power operation), I don't think this is a big deal. It does mean that, at very small intervals, transmitter selection may be affected by link layer latency. This could lead to uneven transmission loads. But since these intervals are comparatively rare, and this effect is generally less pronounced than the application-load variations caused by resets, I'm not sure how significant it is. Seems like a good thing to measure in a real system, so we can better understand the problem. Phil From pal@cs.stanford.edu Fri Aug 27 11:52:11 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 976443A6A76 for ; Fri, 27 Aug 2010 11:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.391 X-Spam-Level: X-Spam-Status: No, score=-5.391 tagged_above=-999 required=5 tests=[AWL=-1.092, BAYES_00=-2.599, MANGLED_LINKS=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pMQZgT8SM67M for ; Fri, 27 Aug 2010 11:52:10 -0700 (PDT) Received: from cs-smtp-2.Stanford.EDU (cs-smtp-2.Stanford.EDU [171.64.64.26]) by core3.amsl.com (Postfix) with ESMTP id 326003A686B for ; Fri, 27 Aug 2010 11:52:10 -0700 (PDT) Received: from [76.14.65.187] (helo=[192.168.1.106]) by cs-smtp-2.Stanford.EDU with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.60) (envelope-from ) id 1Op42c-000204-23; Fri, 27 Aug 2010 11:52:42 -0700 In-Reply-To: <007a01cb460a$d2026260$76072720$@com> References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> <11260.1282789126@marajade.sandelman.ca> <22002.1282828315@marajade.sandelman.ca> <00dc01cb452c$422b4280$c681c780$@com> <4C770D9F.4080408@eecs.berkeley.edu> <4BEAE8C3-B669-4EF1-85DA-7F262CCB25F5@archrock.com> <001b01cb45b9$c89a8ff0$59cfafd0$@com> <908E2D0E-1D35-4CAB-B590-E7301DFF946A@cs.stanford.edu> <007a01cb460a$d2026260$76072720$@com> Mime-Version: 1.0 (Apple Message framework v753.1) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Philip Levis Date: Fri, 27 Aug 2010 11:51:49 -0700 To: Colin O'Flynn X-Mailer: Apple Mail (2.753.1) X-Scan-Signature: f9929892efd47015c544d6ca2fb551e9 Cc: roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 18:52:11 -0000 On Aug 27, 2010, at 10:10 AM, Colin O'Flynn wrote: > Hi Phil, > >> I don't think it matters. > > Ah alright. I was trying to address the original question about > synchronizing multiple DIOs. > > Essentially say how far an implementation can push the Trickle > timer w/o > "breaking" anything. Thus if it's preferable in a Linux > implementation to > try and aggregate sending DIOs, the implementer knows they can do > this as > long as you don't exceed the allowed jitter. One well-understood and tested approach to aggregate Trickle transmissions is what DIP[1] and DHV[2] do. If you have two independent Trickle timers A and B which have the same interval I, then you can just select a single time t for both of them and send an aggregate at that t. Because it's a single value drawn from the uniform distribution, it doesn't suffer from the min() problem of on- the-fly aggregation. If A and B have different intervals then you treat them separately. The one minor issue is that aggregating A and B in this way can induce a phase shift in the intervals; but given that Trickle is robust to in-phase and out-of-phase timers, this doesn't tend to cause a big problem. Does that make sense? Phil [1] Lin, K. and P. Levis, "Data Discovery and Dissemination with DIP", Proceedings of the 7th international conference on Information processing in sensor networks IPSN 2008, April 2008. [2] Dang, T., Bulusu, N., Feng, W., and S. Park, "DHV: A Code Consistency Maintenance Protocol for Multi-hop Wireless Networks", Wireless Sensor Networks: 6th European Conference Proceedings EWSN 2009 Cork, February 2009. From rodolfo@ubilogix.com Fri Aug 27 15:50:38 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F38823A6988 for ; Fri, 27 Aug 2010 15:50:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[AWL=0.454, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fr5x13LKUI-j for ; Fri, 27 Aug 2010 15:50:36 -0700 (PDT) Received: from dpmailmta03.doteasy.com (dpmailmta03-28.doteasy.com [65.61.219.48]) by core3.amsl.com (Postfix) with ESMTP id EB5DE3A68CE for ; Fri, 27 Aug 2010 15:50:31 -0700 (PDT) Received: from dpmail31pro.doteasy.com ([192.168.101.31]) by dpmailrp06.doteasy.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7RMostw031583; Fri, 27 Aug 2010 15:50:54 -0700 Received: from 189.222.82.34.dsl.dyn.telnor.net [189.222.82.34] by dpmail31pro.doteasy.com with SMTP; Fri, 27 Aug 2010 15:50:42 -0700 Message-ID: <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> From: "Rodolfo Gonzalez Bernaldez" To: "Alexandru Petrescu" References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> In-Reply-To: <4C776A94.7000104@gmail.com> Date: Fri, 27 Aug 2010 15:50:35 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: No geolocation information available for 192.168.101.31 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 01CXyOSC6 - b25fa73afd2e X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.86 X-Originating-IP: 192.168.101.86 Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 22:50:38 -0000 Hello Alex, all CCM* and IPSEC, both provide data authentication and encryption and it's that what we are looking for Using the security level 5, 6, or 7, you can define the number of bytes for clear text. In CCM* using the security level 5, 6 or 7 may have the next form for data: A) encrypted data : MAC B) clear text : MAC C) clear text - encrypted data : MAC For example using CCM* level 6 on the next data and an input with 8 cleartext header octets AES Key = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB CC CD CE CF Nonce = 00 00 00 03 02 01 00 A0 A1 A2 A3 A4 A5 Data= 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E we get the next result: CCM* level 6 Data= 00 01 02 03 04 05 06 07 58 8C 97 9A 61 C6 63 D2 F0 66 D0 C2 C0 F9 89 80 6D 5F 6B 61 DA C3 84 17 E8 D1 2C FD F9 26 E0 As you see the first 8 bytes were unchanged, but were used to create the CBC-MAC. For more details see rfc3610 packet vector #1 With this in mind, lest to suppose that we have the next IPv6 packet: FF 01 02 03 44 55 66 77 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E and the byte cero is one of the mutable fields (e.g. the Hop limit) and the byte 4,5,6, and 7 are a mutable field but predictable and the predictable values are for byte 4 = 04, byte 5 = 05, byte 6 = 06 and byte 7 = 07, so now following the rules of RFC4302 our packet will change to: 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E Now lest to use CCM* level 6, the result is the next: 00 01 02 03 04 05 06 07 58 8C 97 9A 61 C6 63 D2 F0 66 D0 C2 C0 F9 89 80 6D 5F 6B 61 DA C3 84 17 E8 D1 2C FD F9 26 E0 And the destination node knowing the rules of RFC4302, just needs to apply the same rules and set the ceros for mutable fields and the corresponding values for the mutable but predictable fields. The only issue that I see at this moment is were to put the CBC-MAC data, for example here we have 64 bit of CBC-MAC, we can just leave them at the end of the packet or maybe create a field at the end of each RPL frame with security with the name CBC-MAC or something like that. The other option is to create a AH for RPL designed for CCM* (I don't like this idea, because the IEEE 802.15.4-2006 frame already have an auxiliary security header), or make modifications to IPSEC to support CCM*. Sorry for the long email, comments are welcome. Best regards Rodolfo. -------------------------------------------------- From: "Alexandru Petrescu" Sent: Friday, August 27, 2010 12:34 AM To: "Rodolfo Gonzalez Bernaldez" Cc: "Michael Richardson" ; "ROLL WG" Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit > Le 27/08/2010 00:08, Rodolfo Gonzalez Bernaldez a écrit : >> Hello Michael, Alex, all >> >> >>> For example, one wouldn't appreciate to have both AH protection of >>> the entire packet _and_ RPL CCM protection. It is redundant. >> >> >> Yes I agree, that it is redundant. >> >> I was checking the RFC4302 section 3.3.3.1. Handling Mutable Fields, > > I think that is the right section to think of. > >> and I didn't see any problem to use these rules only with CCM*. > > Well, depends how we refer to it. Intuitively, it may be easy indeed to > apply that "rfc4302 mutable field" rules to CCM*. > > However, this may introduce new misunderstandings too. Because that > section explicitely says "IPsec": >> [...] If a field is mutable, but its value at the (IPsec) receiver >> is predictable, then [...] > > Here we don't have IPsec receivers, we have CCM* receivers - they are > very different: CCM* MAC is present in ICMP headers, whereas IPsec ICV > is present in Authentication Header. > > Thus, will that rfc4302 "If" rule apply here or not? If not, then we > don't know what to do here with CCM* and mutable-but-predictable fields. > We would have to specify what CCM* does with them, couldn't simply > refer to rfc4302. > > There are several mentionings of "IPsec" in that section, and here we > don't currently do IPsec. > > To solve that, it may lead to copy&paste that section into RPL doc and > substitute "CCM* MAC" for "ICV", "RPL" for "IPsec", remove IPv4, etc. > Suddenly that sounds not as a simple straight referral to rfc4302. > > It may lead to rewriting IPsec specs altogether. > >> What do you think of the following statements in the security >> section: -Any IPv6 frame with security must be prepared as RFC4302 >> section 3.3.3.1 specified for mutable fields > > Ok, sounds good as first step, for mutable fields. > > How about the "Mutable but Predictable Fields", i.e. dst address in > presence of a Routing Header. MAC should cover them too, especially > knowing that a new Routing Header is under discussion in 6MAN WG, for RPL. > >> -ccm* computation must take IPv6 header, and/or IPv6 extension >> headers as clear text, the rest of the packet must be encrypted > > I kind of understand and I can agree. > > However, will the rest of the packet (encrypted) be also applied > authentication, or just leave it encrypted. This should be clarified > one way or another, so implementer knows what to implement. This again > risks leading to rewriting IPsec specifications. > > At which point I wonder why all the effort? Wouldn't it be easier to > identify what's the real core of the RPL security - is it CCM* only? If > yes - could we use CCM* with IPsec Authentication Header? That may be > simpler to spec and implement, rather than carrying new MAC fields in > ICMP. > >> Using these two rules statements we would be following the rules of >> RFC4302, providing authentication for the entire IPv6 frame, and we >> keeping encrypted RPL data. > > Yes, that is one possible way of doing it. > > I just wanted to mention that here we have a context: a number of IPv6 > fields, extension headers and other standards are present - we should > consider them all. > > Alex > >> >> Best regards Rodolfo. >> -------------------------------------------------- From: "Alexandru >> Petrescu" Sent: Thursday, August 26, >> 2010 7:42 AM To: "Michael Richardson" Cc: "Rodolfo >> Gonzalez Bernaldez" ; "ROLL WG" >> Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop >> Limit >> >>> Le 26/08/2010 15:31, Michael Richardson a écrit : >>>>>>>>> "Alexandru" == Alexandru >>>>>>>>> Petrescu writes: >>>> Alexandru> On another hand, risks do exist in the base header >>>> Alexandru> (spoofing the src address is one widely known). It is >>> From alexandru.petrescu@gmail.com Sun Aug 29 10:45:31 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F23A73A6853 for ; Sun, 29 Aug 2010 10:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[AWL=-0.952, BAYES_50=0.001, HELO_EQ_FR=0.35, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RBaIzhfTzPlc for ; Sun, 29 Aug 2010 10:45:29 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 5CCEC3A682D for ; Sun, 29 Aug 2010 10:45:25 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id CFDA894013C; Sun, 29 Aug 2010 19:45:50 +0200 (CEST) Message-ID: <4C7A9CC8.8000400@gmail.com> Date: Sun, 29 Aug 2010 19:45:44 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rodolfo Gonzalez Bernaldez References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> In-Reply-To: <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100829-0, 29/08/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Aug 2010 17:45:31 -0000 Le 28/08/2010 00:50, Rodolfo Gonzalez Bernaldez a écrit : > Hello Alex, all > > CCM* and IPSEC, both provide data authentication and encryption and > it's that what we are looking for [sidenote to clarify terminology as I read: one would compare CCM* to AH (for authentication) and to ESP (for enc + auth). IPsec is more than just these two, often comprising IKE (key generation), databases, rules, policies, firewalls, and more - these are not covered by CCM* but IPsec does.] > Using the security level 5, 6, or 7, you can define the number of > bytes for clear text. > > In CCM* using the security level 5, 6 or 7 may have the next form for > data: A) encrypted data : MAC B) clear text : MAC C) clear text - > encrypted data : MAC > > For example using CCM* level 6 on the next data and an input with 8 > cleartext header octets AES Key = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB > CC CD CE CF Nonce = 00 00 00 03 02 01 00 A0 A1 A2 A3 A4 A5 Data= 00 > 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 > 18 19 1A 1B 1C 1D 1E we get the next result: CCM* level 6 Data= 00 01 > 02 03 04 05 06 07 58 8C 97 9A 61 C6 63 D2 F0 66 D0 C2 C0 F9 89 80 6D > 5F 6B 61 DA C3 84 17 E8 D1 2C FD F9 26 E0 As you see the first 8 > bytes were unchanged, but were used to create the CBC-MAC. For more > details see rfc3610 packet vector #1 > > With this in mind, lest to suppose that we have the next IPv6 > packet: FF 01 02 03 44 55 66 77 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 > 14 15 16 17 18 19 1A 1B 1C 1D 1E and the byte cero is one of the > mutable fields (e.g. the Hop limit) and the byte 4,5,6, and 7 are a > mutable field but predictable and the predictable values are for byte > 4 = 04, byte 5 = 05, byte 6 = 06 and byte 7 = 07, so now following > the rules of RFC4302 our packet will change to: 00 01 02 03 04 05 06 > 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D > 1E Now lest to use CCM* level 6, the result is the next: 00 01 02 03 > 04 05 06 07 58 8C 97 9A 61 C6 63 D2 F0 66 D0 C2 C0 F9 89 80 6D 5F 6B > 61 DA C3 84 17 E8 D1 2C FD F9 26 E0 > > And the destination node knowing the rules of RFC4302, just needs to > apply the same rules and set the ceros for mutable fields and the > corresponding values for the mutable but predictable fields. That sounds right. Provided the Hop Limit mutable field is set to 0 at MAC computing time by sender, and also by receiver. Your example seems to say so. I agree with it. > The only issue that I see at this moment is were to put the CBC-MAC > data, I agree, that is a right question: where to put the CBC-MAC data? > for example here we have 64 bit of CBC-MAC, we can just leave them at > the end of the packet or maybe create a field at the end of each RPL > frame with security with the name CBC-MAC or something like that. I propose to put the CBC-MAC data in the Authentication Header - the Integrity Check Value (ICV) field of a typical Authentication Header rfc4302, instead of putting it as a field in the RPL header. What do you think about this? Interested people? This is a central issue to clarify. Depending on this we can see further. Alex > > The other option is to create a AH for RPL designed for CCM* (I don't > like this idea, because the IEEE 802.15.4-2006 frame already have an > auxiliary security header), or make modifications to IPSEC to > support CCM*. > > Sorry for the long email, comments are welcome. > > Best regards Rodolfo. > > -------------------------------------------------- From: "Alexandru > Petrescu" Sent: Friday, August 27, > 2010 12:34 AM To: "Rodolfo Gonzalez Bernaldez" > Cc: "Michael Richardson" ; > "ROLL WG" Subject: Re: [Roll] Messg Auth Code > covering the mutable IP Hop Limit > >> Le 27/08/2010 00:08, Rodolfo Gonzalez Bernaldez a écrit : >>> Hello Michael, Alex, all >>> >>> >>>> For example, one wouldn't appreciate to have both AH protection >>>> of the entire packet _and_ RPL CCM protection. It is >>>> redundant. >>> >>> >>> Yes I agree, that it is redundant. >>> >>> I was checking the RFC4302 section 3.3.3.1. Handling Mutable >>> Fields, >> >> I think that is the right section to think of. >> >>> and I didn't see any problem to use these rules only with CCM*. >> >> Well, depends how we refer to it. Intuitively, it may be easy >> indeed to apply that "rfc4302 mutable field" rules to CCM*. >> >> However, this may introduce new misunderstandings too. Because >> that section explicitely says "IPsec": >>> [...] If a field is mutable, but its value at the (IPsec) >>> receiver is predictable, then [...] >> >> Here we don't have IPsec receivers, we have CCM* receivers - they >> are very different: CCM* MAC is present in ICMP headers, whereas >> IPsec ICV is present in Authentication Header. >> >> Thus, will that rfc4302 "If" rule apply here or not? If not, then >> we don't know what to do here with CCM* and mutable-but-predictable >> fields. We would have to specify what CCM* does with them, couldn't >> simply refer to rfc4302. >> >> There are several mentionings of "IPsec" in that section, and here >> we don't currently do IPsec. >> >> To solve that, it may lead to copy&paste that section into RPL doc >> and substitute "CCM* MAC" for "ICV", "RPL" for "IPsec", remove >> IPv4, etc. Suddenly that sounds not as a simple straight referral >> to rfc4302. >> >> It may lead to rewriting IPsec specs altogether. >> >>> What do you think of the following statements in the security >>> section: -Any IPv6 frame with security must be prepared as >>> RFC4302 section 3.3.3.1 specified for mutable fields >> >> Ok, sounds good as first step, for mutable fields. >> >> How about the "Mutable but Predictable Fields", i.e. dst address >> in presence of a Routing Header. MAC should cover them too, >> especially knowing that a new Routing Header is under discussion in >> 6MAN WG, for RPL. >> >>> -ccm* computation must take IPv6 header, and/or IPv6 extension >>> headers as clear text, the rest of the packet must be encrypted >> >> I kind of understand and I can agree. >> >> However, will the rest of the packet (encrypted) be also applied >> authentication, or just leave it encrypted. This should be >> clarified one way or another, so implementer knows what to >> implement. This again risks leading to rewriting IPsec >> specifications. >> >> At which point I wonder why all the effort? Wouldn't it be easier >> to identify what's the real core of the RPL security - is it CCM* >> only? If yes - could we use CCM* with IPsec Authentication Header? >> That may be simpler to spec and implement, rather than carrying new >> MAC fields in ICMP. >> >>> Using these two rules statements we would be following the rules >>> of RFC4302, providing authentication for the entire IPv6 frame, >>> and we keeping encrypted RPL data. >> >> Yes, that is one possible way of doing it. >> >> I just wanted to mention that here we have a context: a number of >> IPv6 fields, extension headers and other standards are present - we >> should consider them all. >> >> Alex >> >>> >>> Best regards Rodolfo. >>> -------------------------------------------------- From: >>> "Alexandru Petrescu" Sent: >>> Thursday, August 26, 2010 7:42 AM To: "Michael Richardson" >>> Cc: "Rodolfo Gonzalez Bernaldez" >>> ; "ROLL WG" Subject: Re: >>> [Roll] Messg Auth Code covering the mutable IP Hop Limit >>> >>>> Le 26/08/2010 15:31, Michael Richardson a écrit : >>>>>>>>>> "Alexandru" == Alexandru >>>>>>>>>> Petrescu writes: >>>>> Alexandru> On another hand, risks do exist in the base >>>>> header Alexandru> (spoofing the src address is one widely >>>>> known). It is >>>> > > From pister@eecs.berkeley.edu Mon Aug 30 11:47:36 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A35D3A69BA for ; Mon, 30 Aug 2010 11:47:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.854 X-Spam-Level: X-Spam-Status: No, score=-5.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1vSuJEIUROgh for ; Mon, 30 Aug 2010 11:47:35 -0700 (PDT) Received: from gateway0.EECS.Berkeley.EDU (gateway0.EECS.Berkeley.EDU [169.229.60.87]) by core3.amsl.com (Postfix) with ESMTP id 933103A6814 for ; Mon, 30 Aug 2010 11:47:35 -0700 (PDT) Received: from [127.0.0.1] (dhcp-32-46.EECS.Berkeley.EDU [128.32.32.46]) (authenticated bits=0) by gateway0.EECS.Berkeley.EDU (8.14.4/8.13.5) with ESMTP id o7UIm5VY023755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 30 Aug 2010 11:48:06 -0700 (PDT) Message-ID: <4C7BFCE5.5010508@eecs.berkeley.edu> Date: Mon, 30 Aug 2010 11:48:05 -0700 From: Kris Pister User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Michael Richardson References: <8455.1282782327@marajade.sandelman.ca> <4FDDEBF6-A797-4D93-882E-C0FAA1AD35DE@cs.stanford.edu> <11260.1282789126@marajade.sandelman.ca> <22002.1282828315@marajade.sandelman.ca> <00dc01cb452c$422b4280$c681c780$@com> <4C770D9F.4080408@eecs.berkeley.edu> <4BEAE8C3-B669-4EF1-85DA-7F262CCB25F5@archrock.com> <001b01cb45b9$c89a8ff0$59cfafd0$@com> <22341.1282914336@marajade.sandelman.ca> In-Reply-To: <22341.1282914336@marajade.sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] implementation questions: sending DIOs for multiple DODAGs X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Aug 2010 18:47:36 -0000 On 8/27/2010 6:05 AM, Michael Richardson wrote: > Colin> ;-) But it would be the same point as low power listening: > Colin> the devices won't wake up specifically to send a DIO, it will > Colin> send the DIO when it's next awake. For synchronization you > Colin> would have to wait until the next sync cycle anyway for > Colin> anyone to hear you. > > So, my understanding is that some link layers have a network wide > synchronization so that receivers wake up together so that they can hear the transmissions? Not quite. Having everyone wake up at the same time is (usually) extremely inefficient. Those networks that have a "sync cycle" approach do not scale well. What is being standardized in 15.4E (through several different mechanisms) is the ability to have pairwise synchronization, so when node A sends unicast to node B, only A and B are awake and on that channel at that time. This is very efficient for, e.g., MP2P traffic up the DODAG. For traffic down the DODAG, you may or may not want to have all of your children listening to a broadcast slot. You may also want to have all nodes listening infrequently to a neighbor-discovery slot. There is certainly some overhead for this approach, but as Jonathan pointed out, the benefits are substantial. > That this cycle really quantizes the values of 't' that can be picked? Yes, but at very fine granularity - in the range from hundreds of milliseconds down to single-digit milliseconds. Much finer than (typical) trickle values. ksjp From rodolfo@ubilogix.com Mon Aug 30 17:39:53 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34A9E3A68C5 for ; Mon, 30 Aug 2010 17:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.482 X-Spam-Level: ** X-Spam-Status: No, score=2.482 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, J_CHICKENPOX_45=0.6, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I1shzmFH5otA for ; Mon, 30 Aug 2010 17:39:51 -0700 (PDT) Received: from dpmailmta03.doteasy.com (dpmailmta03-08.doteasy.com [65.61.218.48]) by core3.amsl.com (Postfix) with ESMTP id CB4193A68B1 for ; Mon, 30 Aug 2010 17:39:51 -0700 (PDT) Received: from dpmail31pro.doteasy.com ([192.168.101.31]) by dpmailrp06.doteasy.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o7V0eDcg020426; Mon, 30 Aug 2010 17:40:13 -0700 Received: from 201.143.145.205.dsl.dyn.telnor.net [201.143.145.205] by dpmail31pro.doteasy.com with SMTP; Mon, 30 Aug 2010 17:40:01 -0700 Message-ID: <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> From: "Rodolfo Gonzalez Bernaldez" To: "Alexandru Petrescu" References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> In-Reply-To: <4C7A9CC8.8000400@gmail.com> Date: Mon, 30 Aug 2010 17:39:55 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 14.0.8089.726 X-MimeOLE: Produced By Microsoft MimeOLE V14.0.8089.726 X-Bayes-Prob: 0.0001 (Score 0, tokens from: @@RPTN) X-CanIt-Geo: No geolocation information available for 192.168.101.31 X-CanItPRO-Stream: base:default X-Canit-Stats-ID: 01D0MEd44 - 190d1920be2a X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.168.101.86 X-Originating-IP: 192.168.101.86 Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 00:39:53 -0000 Hello Alex, all My comments in message bracket by Best regards Rodolfo. -------------------------------------------------- From: "Alexandru Petrescu" Sent: Sunday, August 29, 2010 10:45 AM To: "Rodolfo Gonzalez Bernaldez" Cc: "Michael Richardson" ; "ROLL WG" Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit > Le 28/08/2010 00:50, Rodolfo Gonzalez Bernaldez a écrit : >> Hello Alex, all >> >> CCM* and IPSEC, both provide data authentication and encryption and >> it's that what we are looking for > > [sidenote to clarify terminology as I read: one would compare CCM* to > AH (for authentication) and to ESP (for enc + auth). IPsec is more > than just these two, often comprising IKE (key generation), databases, > rules, policies, firewalls, and more - these are not covered by CCM* > but IPsec does.] > Yes I agree, I don't specify clearly my idea here. I was thought only in authentication and encryption of the packet, for these reasons I focused only in that two features. By the way the zigbeeIP group is working on PANA and EAP, in case you are interested >> Using the security level 5, 6, or 7, you can define the number of >> bytes for clear text. >> >> In CCM* using the security level 5, 6 or 7 may have the next form for >> data: A) encrypted data : MAC B) clear text : MAC C) clear text - >> encrypted data : MAC >> >> For example using CCM* level 6 on the next data and an input with 8 >> cleartext header octets AES Key = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB >> CC CD CE CF Nonce = 00 00 00 03 02 01 00 A0 A1 A2 A3 A4 A5 Data= 00 >> 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 >> 18 19 1A 1B 1C 1D 1E we get the next result: CCM* level 6 Data= 00 01 >> 02 03 04 05 06 07 58 8C 97 9A 61 C6 63 D2 F0 66 D0 C2 C0 F9 89 80 6D >> 5F 6B 61 DA C3 84 17 E8 D1 2C FD F9 26 E0 As you see the first 8 >> bytes were unchanged, but were used to create the CBC-MAC. For more >> details see rfc3610 packet vector #1 >> >> With this in mind, lest to suppose that we have the next IPv6 >> packet: FF 01 02 03 44 55 66 77 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 >> 14 15 16 17 18 19 1A 1B 1C 1D 1E and the byte cero is one of the >> mutable fields (e.g. the Hop limit) and the byte 4,5,6, and 7 are a >> mutable field but predictable and the predictable values are for byte >> 4 = 04, byte 5 = 05, byte 6 = 06 and byte 7 = 07, so now following >> the rules of RFC4302 our packet will change to: 00 01 02 03 04 05 06 >> 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D >> 1E Now lest to use CCM* level 6, the result is the next: 00 01 02 03 >> 04 05 06 07 58 8C 97 9A 61 C6 63 D2 F0 66 D0 C2 C0 F9 89 80 6D 5F 6B >> 61 DA C3 84 17 E8 D1 2C FD F9 26 E0 >> >> And the destination node knowing the rules of RFC4302, just needs to >> apply the same rules and set the ceros for mutable fields and the >> corresponding values for the mutable but predictable fields. > > That sounds right. Provided the Hop Limit mutable field is set to 0 at > MAC computing time by sender, and also by receiver. Your example seems > to say so. I agree with it. > >> The only issue that I see at this moment is were to put the CBC-MAC >> data, > > I agree, that is a right question: where to put the CBC-MAC data? > >> for example here we have 64 bit of CBC-MAC, we can just leave them at >> the end of the packet or maybe create a field at the end of each RPL >> frame with security with the name CBC-MAC or something like that. > > I propose to put the CBC-MAC data in the Authentication Header - the > Integrity Check Value (ICV) field of a typical Authentication Header > rfc4302, instead of putting it as a field in the RPL header. > What do you think about this? Interested people? > The only issue that I see with the AH, is the size of the AH header, is a big header. But if we are talked of MAC security (IEEE 802.15.4-2006-MAC) lest just to leave the MIC (CBC-MAC) as is defined by the standard, and the MIC is just another field of the MAC frame like the field MFR. What do you think about this?. > This is a central issue to clarify. Depending on this we can see further. > > Alex > >> >> The other option is to create a AH for RPL designed for CCM* (I don't >> like this idea, because the IEEE 802.15.4-2006 frame already have an >> auxiliary security header), or make modifications to IPSEC to >> support CCM*. >> >> Sorry for the long email, comments are welcome. >> >> Best regards Rodolfo. >> >> -------------------------------------------------- From: "Alexandru >> Petrescu" Sent: Friday, August 27, >> 2010 12:34 AM To: "Rodolfo Gonzalez Bernaldez" >> Cc: "Michael Richardson" ; >> "ROLL WG" Subject: Re: [Roll] Messg Auth Code >> covering the mutable IP Hop Limit >> >>> Le 27/08/2010 00:08, Rodolfo Gonzalez Bernaldez a écrit : >>>> Hello Michael, Alex, all >>>> >>>> >>>>> For example, one wouldn't appreciate to have both AH protection >>>>> of the entire packet _and_ RPL CCM protection. It is >>>>> redundant. >>>> >>>> >>>> Yes I agree, that it is redundant. >>>> >>>> I was checking the RFC4302 section 3.3.3.1. Handling Mutable >>>> Fields, >>> >>> I think that is the right section to think of. >>> >>>> and I didn't see any problem to use these rules only with CCM*. >>> >>> Well, depends how we refer to it. Intuitively, it may be easy >>> indeed to apply that "rfc4302 mutable field" rules to CCM*. >>> >>> However, this may introduce new misunderstandings too. Because >>> that section explicitely says "IPsec": >>>> [...] If a field is mutable, but its value at the (IPsec) >>>> receiver is predictable, then [...] >>> >>> Here we don't have IPsec receivers, we have CCM* receivers - they >>> are very different: CCM* MAC is present in ICMP headers, whereas >>> IPsec ICV is present in Authentication Header. >>> >>> Thus, will that rfc4302 "If" rule apply here or not? If not, then >>> we don't know what to do here with CCM* and mutable-but-predictable >>> fields. We would have to specify what CCM* does with them, couldn't >>> simply refer to rfc4302. >>> >>> There are several mentionings of "IPsec" in that section, and here >>> we don't currently do IPsec. >>> >>> To solve that, it may lead to copy&paste that section into RPL doc >>> and substitute "CCM* MAC" for "ICV", "RPL" for "IPsec", remove >>> IPv4, etc. Suddenly that sounds not as a simple straight referral >>> to rfc4302. >>> >>> It may lead to rewriting IPsec specs altogether. >>> >>>> What do you think of the following statements in the security >>>> section: -Any IPv6 frame with security must be prepared as >>>> RFC4302 section 3.3.3.1 specified for mutable fields >>> >>> Ok, sounds good as first step, for mutable fields. >>> >>> How about the "Mutable but Predictable Fields", i.e. dst address >>> in presence of a Routing Header. MAC should cover them too, >>> especially knowing that a new Routing Header is under discussion in >>> 6MAN WG, for RPL. >>> >>>> -ccm* computation must take IPv6 header, and/or IPv6 extension >>>> headers as clear text, the rest of the packet must be encrypted >>> >>> I kind of understand and I can agree. >>> >>> However, will the rest of the packet (encrypted) be also applied >>> authentication, or just leave it encrypted. This should be >>> clarified one way or another, so implementer knows what to >>> implement. This again risks leading to rewriting IPsec >>> specifications. >>> >>> At which point I wonder why all the effort? Wouldn't it be easier >>> to identify what's the real core of the RPL security - is it CCM* >>> only? If yes - could we use CCM* with IPsec Authentication Header? >>> That may be simpler to spec and implement, rather than carrying new >>> MAC fields in ICMP. >>> >>>> Using these two rules statements we would be following the rules >>>> of RFC4302, providing authentication for the entire IPv6 frame, >>>> and we keeping encrypted RPL data. >>> >>> Yes, that is one possible way of doing it. >>> >>> I just wanted to mention that here we have a context: a number of >>> IPv6 fields, extension headers and other standards are present - we >>> should consider them all. >>> >>> Alex >>> >>>> >>>> Best regards Rodolfo. >>>> -------------------------------------------------- From: >>>> "Alexandru Petrescu" Sent: >>>> Thursday, August 26, 2010 7:42 AM To: "Michael Richardson" >>>> Cc: "Rodolfo Gonzalez Bernaldez" >>>> ; "ROLL WG" Subject: Re: >>>> [Roll] Messg Auth Code covering the mutable IP Hop Limit >>>> >>>>> Le 26/08/2010 15:31, Michael Richardson a écrit : >>>>>>>>>>> "Alexandru" == Alexandru >>>>>>>>>>> Petrescu writes: >>>>>> Alexandru> On another hand, risks do exist in the base >>>>>> header Alexandru> (spoofing the src address is one widely >>>>>> known). It is >>>>> >> >> > > From robert.cragie@gridmerge.com Tue Aug 31 08:53:34 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D4773A6846 for ; Tue, 31 Aug 2010 08:53:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.678 X-Spam-Level: X-Spam-Status: No, score=-3.678 tagged_above=-999 required=5 tests=[AWL=-0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XVPuK6j3C1Yf for ; Tue, 31 Aug 2010 08:53:31 -0700 (PDT) Received: from mail78.extendcp.co.uk (mail78.extendcp.co.uk [79.170.40.78]) by core3.amsl.com (Postfix) with ESMTP id 2147F3A6804 for ; Tue, 31 Aug 2010 08:53:29 -0700 (PDT) Received: from client-86-23-94-106.brhm.adsl.virginmedia.com ([86.23.94.106] helo=[192.168.1.66]) by mail78.extendcp.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) id 1OqT9o-0007QY-IO; Tue, 31 Aug 2010 16:53:57 +0100 Message-ID: <4C7D2596.3090108@gridmerge.com> Date: Tue, 31 Aug 2010 16:53:58 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rodolfo Gonzalez Bernaldez References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> In-Reply-To: <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms030600060400060603030802" Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: robert.cragie@gridmerge.com List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 15:53:34 -0000 This is a cryptographically signed message in MIME format. --------------ms030600060400060603030802 Content-Type: multipart/alternative; boundary="------------010606090107050505010904" This is a multi-part message in MIME format. --------------010606090107050505010904 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Rodolfo, I agree about treatment of mutable fields. Setting them to 0 for MAC=20 calculation is an acceptable way of doing it although it is a little=20 clumsy for inline packet security processing (done by certain devices).=20 The alternative would be to elide the fields completely but this is=20 probably more work in practice. > That sounds right. Provided the Hop Limit mutable field is set to 0 at= > MAC computing time by sender, and also by receiver. Your example seems= > to say so. I agree with it. > >> The only issue that I see at this moment is were to put the CBC-MAC >> data, > > I agree, that is a right question: where to put the CBC-MAC data? > >> for example here we have 64 bit of CBC-MAC, we can just leave them at >> the end of the packet or maybe create a field at the end of each RPL >> frame with security with the name CBC-MAC or something like that. > > I propose to put the CBC-MAC data in the Authentication Header - the > Integrity Check Value (ICV) field of a typical Authentication Header > rfc4302, instead of putting it as a field in the RPL header. > What do you think about this? Interested people? > The only issue that I see with the AH, is the size of the AH header, is=20 a big header. But if we are talked of MAC security (IEEE 802.15.4-2006-MAC) lest just=20 to leave the MIC (CBC-MAC) as is defined by the standard, and the MIC is = just another field of the MAC frame like the field MFR. What do you=20 think about this?. AES-CCM (SP 800-38C) specifies concatenation of the encrypted MAC (MIC,=20 schmac, schmic :-) at the end of the payload. I would keep it there. It=20 makes the MPDU larger. If doing it like this, it should be shown on=20 Figure 7, appended after the options. Robert Robert Cragie (Pacific Gas & Electric) Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 1924 910888 +1 415 513 0064 http://www.gridmerge.com --------------010606090107050505010904 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Rodolfo,

I agree about treatment of mutable fields. Setting them to 0 for MAC calculation is an acceptable way of doing it although it is a little clumsy for inline packet security processing (done by certain devices). The alternative would be to elide the fields completely but this is probably more work in practice.

That sounds right.  Provided the Hop L= imit mutable field is set to 0 at
MAC computing time by sender, and also by receiver.  Your exam= ple seems
to say so.  I agree with it.

The only issue that I see at this moment is were to put the CBC-MAC
data,

I agree, that is a right question: where to put the CBC-MAC data?

for example here we have 64 bit of CBC-MAC, we can just leave them at
the end of the packet or maybe create a field at the end of each RPL
 frame with security with the name CBC-MAC or something like= that.

I propose to put the CBC-MAC data in the Authentication Header - the
Integrity Check Value (ICV) field of a typical Authentication Header
rfc4302, instead of putting it as a field in the RPL header.
What do you think about this?  Interested people?


<RGB>
The only issue that I see with the AH, is the size of the AH header, is a big header.
But if we are talked of MAC security (IEEE 802.15.4-2006-MAC) lest just to leave the MIC (CBC-MAC) as is defined by the standard, and the MIC is just another field of the MAC frame like the field MFR. What do you think about this?.
</RGB>

AES-CCM (SP 800-38C) specifies concatenation of the encrypted MAC (MIC, schmac, schmic :-) at the end of the payload. I would keep it there. It makes the MPDU larger. If doing it like this, it should be shown on Figure 7, appended after the options.

Robert

Robert Cragie (Pacific Gas & Electric)

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


--------------010606090107050505010904-- --------------ms030600060400060603030802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIRZTCC BN0wggPFoAMCAQICEHGS++YZX6xNEoV0cTSiGKcwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UE BhMCR0IxGzAZBgNVBAgMEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEa MBgGA1UECgwRQ29tb2RvIENBIExpbWl0ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBT ZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0yODEyMzEyMzU5NTlaMIGuMQswCQYDVQQGEwJV UzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUg VVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWls MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5 ShpHornMSMxqmNVNNRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqk kqgX8pgV8pPMyaQylbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWL eeEeaYji5kbNoKXqvgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJ Q/wWWq8dcdcRWdq6hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udl y/hNVyh00jT/MLbu9mIwFIws6wIDAQABo4IBJzCCASMwHwYDVR0jBBgwFoAUoBEKIz6W8Qfs 4q8p74Klf9AwpLQwHQYDVR0OBBYEFImCZ33EnSZwAEu0UEh83j2uBG59MA4GA1UdDwEB/wQE AwIBBjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAR BgNVHSAECjAIMAYGBFUdIAAwewYDVR0fBHQwcjA4oDagNIYyaHR0cDovL2NybC5jb21vZG9j YS5jb20vQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwNqA0oDKGMGh0dHA6Ly9jcmwuY29t b2RvLm5ldC9BQUFDZXJ0aWZpY2F0ZVNlcnZpY2VzLmNybDARBglghkgBhvhCAQEEBAMCAQYw DQYJKoZIhvcNAQEFBQADggEBAJ2Vyzy4fqUJxB6/C8LHdo45PJTGEKpPDMngq4RdiVTgZTvz bRx8NywlVF+WIfw3hJGdFdwUT4HPVB1rbEVgxy35l1FM+WbKPKCCjKbI8OLp1Er57D9Wyd12 jMOCAU9sAPMeGmF0BEcDqcZAV5G8ZSLFJ2dPV9tkWtmNH7qGL/QGrpxp7en0zykX2OBKnxog L5dMUbtGB8SKN04g4wkxaMeexIud6H4RvDJoEJYRmETYKlFgTYjrdDrfQwYyyDlWjDoRUtNB pEMD9O3vMyfbOeAUTibJ2PU54om4k123KSZB6rObroP8d3XK6Mq1/uJlSmM+RMTQw16Hc6mY HK9/FX8wggY+MIIFJqADAgECAhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbDAeFw0xMDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVy Z2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRth Gtth3YcCbhLPjfAcnDKcEGSrkZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jF z4S1ZNk1if6V9QEiyBHdE1qMUQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBz aJMI2N/E5XGGYpKFj9vxnEiQ7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tq JLIiG8Argf0+bWaxmuSUihKoakhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk0 0vQPvgH5GEi6zSB9QvqWCdBH/rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJn fcSdJnAAS7RQSHzePa4Ebn0wHQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1Ud DwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIx AQMFAjARBglghkgBhvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzAp BggrBgEFBQcCARYdaHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCB mjBMoEqgSIZGaHR0cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRB dXRoZW50aWNhdGlvbmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0 L1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYB BQUHAQEEYDBeMDYGCCsGAQUFBzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFD bGllbnRDQS5jcnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNV HREEHzAdgRtyb2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEB ADcjSJQKgVIfD/IztFrhx2YqR9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rN fNoaqr5LZwDeVflMnZd0rPcTA9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o 7mSbxSSBZHuVLObx/E5E+D5fjWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QH IIxdR91N2vHuNXWIPROPFMl7y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4K A8aD9RaBR8FNQHq+JusC2tf11qdHBpHrVAK7dHodKDnbRr2t9VdrU2owggY+MIIFJqADAgEC AhEAtlwUjTTxveqQY8soFvBYEjANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJU UlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNV BAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0x MDA4MzAwMDAwMDBaFw0xMTA4MzAyMzU5NTlaMIHkMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3Qg TmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENv bmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0G A1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEq MCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdpZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtAJ+m9Tgd3li8BgAIRthGtth3YcCbhLPjfAcnDKcEGSr kZqao79Jg2uDW62IOwNCq9ae3VweBlvg3UUVu8upXzgDR/jFz4S1ZNk1if6V9QEiyBHdE1qM UQeeytedk3qw93CU5snWiXgVRacU8H8Dv+WJPsb4WYAH4MBzaJMI2N/E5XGGYpKFj9vxnEiQ 7h83jXxw3Ee2rXCCbhJEci/tUl+Cx40pB3m7nlEdASY+A3tqJLIiG8Argf0+bWaxmuSUihKo akhHQruAylWY9EVtbKg8SACYZhdHCx2+ZSSrxbbAKSv0cDk00vQPvgH5GEi6zSB9QvqWCdBH /rL0XfV5jQIDAQABo4ICHTCCAhkwHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHzePa4Ebn0w HQYDVR0OBBYEFGkahOqOBMk95XAb8dpcRdaef8AYMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMB Af8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgBhvhCAQEE BAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYdaHR0cHM6 Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0cDovL2Ny bC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlvbmFuZEVt YWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwbAYIKwYBBQUHAQEEYDBeMDYGCCsGAQUF BzAChipodHRwOi8vY3J0LmNvbW9kb2NhLmNvbS9VVE5BQUFDbGllbnRDQS5jcnQwJAYIKwYB BQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRtyb2JlcnQuY3Jh Z2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBADcjSJQKgVIfD/IztFrhx2Yq R9mKsDs3XakKd4hUoeunHgskiaMIQY2Kcfob48OuzrfY73rNfNoaqr5LZwDeVflMnZd0rPcT A9rAHq5l/qwdSta3k0xvBui0NAtOrSBdbqC4vggLKuZvoR2o7mSbxSSBZHuVLObx/E5E+D5f jWC7ffNvr9y/uFXeCYFsM+Hc9VPIZ+cAY7JQFJEK/Nuti2QHIIxdR91N2vHuNXWIPROPFMl7 y8ltO/fONwhxMcY2dH4JkDH6pdNzMtzykvsO0NeiRHnNlS4KA8aD9RaBR8FNQHq+JusC2tf1 1qdHBpHrVAK7dHodKDnbRr2t9VdrU2oxggRgMIIEXAIBATCBxDCBrjELMAkGA1UEBhMCVVMx CzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVT RVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0 BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIR ALZcFI008b3qkGPLKBbwWBIwCQYFKw4DAhoFAKCCAnAwGAYJKoZIhvcNAQkDMQsGCSqGSIb3 DQEHATAcBgkqhkiG9w0BCQUxDxcNMTAwODMxMTU1MzU4WjAjBgkqhkiG9w0BCQQxFgQUCJIh us5umw7iT/yYITgTEZrZLJEwXwYJKoZIhvcNAQkPMVIwUDALBglghkgBZQMEAQIwCgYIKoZI hvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3 DQMCAgEoMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJV VDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4t VVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQC2XBSNNPG96pBj yygW8FgSMIHXBgsqhkiG9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgT AlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBO ZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIRALZcFI008b3q kGPLKBbwWBIwDQYJKoZIhvcNAQEBBQAEggEArTHUXF84EVAPOh4Fc2PRxQsWKNqAvx9GHPkC JasT4r6E9btHGT8eqZEik3MZkRzR4xLoYscZR22ApzCd6p9IjxC8gCeodxiPScGeRr2tbP8V dDJMi72w6yx0LnXfZQKMyjmb068oAxm9UKvv/ynw3pCbH7G3qsmQjoJrDu2odnMNPEmhq9nW Wc1marOu0+MjVoI8hjQD6m0rJMKM3hTBFI/fpDs1RVZuRSvOczWiI1o1x1ByGnO8lzzF747m WScKFWqMtBSKuuBvImbGZL5zPjcblj6jQQG0UTo+UBMFH2tJ/H6VPm2ryKNVlBr7hjQt1XUa fPDx6YpnhD8BU3ulFAAAAAAAAA== --------------ms030600060400060603030802-- From alexandru.petrescu@gmail.com Tue Aug 31 13:49:01 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F1EE3A6A76 for ; Tue, 31 Aug 2010 13:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.288 X-Spam-Level: X-Spam-Status: No, score=-1.288 tagged_above=-999 required=5 tests=[AWL=0.361, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_45=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qp8xMvfpwDnP for ; Tue, 31 Aug 2010 13:48:59 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id 7ABFD3A6A88 for ; Tue, 31 Aug 2010 13:48:57 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 60FFC9400E5; Tue, 31 Aug 2010 22:49:21 +0200 (CEST) Message-ID: <4C7D6ACF.6040109@gmail.com> Date: Tue, 31 Aug 2010 22:49:19 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Rodolfo Gonzalez Bernaldez References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> In-Reply-To: <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100831-1, 31/08/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 20:49:01 -0000 Le 31/08/2010 02:39, Rodolfo Gonzalez Bernaldez a écrit : > Hello Alex, all > > My comments in message bracket by > > Best regards > Rodolfo. > > -------------------------------------------------- > From: "Alexandru Petrescu" > Sent: Sunday, August 29, 2010 10:45 AM > To: "Rodolfo Gonzalez Bernaldez" > Cc: "Michael Richardson" ; "ROLL WG" > Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit > >> Le 28/08/2010 00:50, Rodolfo Gonzalez Bernaldez a écrit : >>> Hello Alex, all >>> >>> CCM* and IPSEC, both provide data authentication and encryption and >>> it's that what we are looking for >> >> [sidenote to clarify terminology as I read: one would compare CCM* to >> AH (for authentication) and to ESP (for enc + auth). IPsec is more >> than just these two, often comprising IKE (key generation), databases, >> rules, policies, firewalls, and more - these are not covered by CCM* >> but IPsec does.] >> > > Yes I agree, I don't specify clearly my idea here. I was thought > only in authentication and encryption of the packet, for these reasons I > focused only in that two features. By the way the zigbeeIP group is > working on PANA and EAP, in case you are interested > >>> Using the security level 5, 6, or 7, you can define the number of >>> bytes for clear text. >>> >>> In CCM* using the security level 5, 6 or 7 may have the next form for >>> data: A) encrypted data : MAC B) clear text : MAC C) clear text - >>> encrypted data : MAC >>> >>> For example using CCM* level 6 on the next data and an input with 8 >>> cleartext header octets AES Key = C0 C1 C2 C3 C4 C5 C6 C7 C8 C9 CA CB >>> CC CD CE CF Nonce = 00 00 00 03 02 01 00 A0 A1 A2 A3 A4 A5 Data= 00 >>> 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 >>> 18 19 1A 1B 1C 1D 1E we get the next result: CCM* level 6 Data= 00 01 >>> 02 03 04 05 06 07 58 8C 97 9A 61 C6 63 D2 F0 66 D0 C2 C0 F9 89 80 6D >>> 5F 6B 61 DA C3 84 17 E8 D1 2C FD F9 26 E0 As you see the first 8 >>> bytes were unchanged, but were used to create the CBC-MAC. For more >>> details see rfc3610 packet vector #1 >>> >>> With this in mind, lest to suppose that we have the next IPv6 >>> packet: FF 01 02 03 44 55 66 77 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 >>> 14 15 16 17 18 19 1A 1B 1C 1D 1E and the byte cero is one of the >>> mutable fields (e.g. the Hop limit) and the byte 4,5,6, and 7 are a >>> mutable field but predictable and the predictable values are for byte >>> 4 = 04, byte 5 = 05, byte 6 = 06 and byte 7 = 07, so now following >>> the rules of RFC4302 our packet will change to: 00 01 02 03 04 05 06 >>> 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D >>> 1E Now lest to use CCM* level 6, the result is the next: 00 01 02 03 >>> 04 05 06 07 58 8C 97 9A 61 C6 63 D2 F0 66 D0 C2 C0 F9 89 80 6D 5F 6B >>> 61 DA C3 84 17 E8 D1 2C FD F9 26 E0 >>> >>> And the destination node knowing the rules of RFC4302, just needs to >>> apply the same rules and set the ceros for mutable fields and the >>> corresponding values for the mutable but predictable fields. >> >> That sounds right. Provided the Hop Limit mutable field is set to 0 at >> MAC computing time by sender, and also by receiver. Your example seems >> to say so. I agree with it. >> >>> The only issue that I see at this moment is were to put the CBC-MAC >>> data, >> >> I agree, that is a right question: where to put the CBC-MAC data? >> >>> for example here we have 64 bit of CBC-MAC, we can just leave them at >>> the end of the packet or maybe create a field at the end of each RPL >>> frame with security with the name CBC-MAC or something like that. >> >> I propose to put the CBC-MAC data in the Authentication Header - the >> Integrity Check Value (ICV) field of a typical Authentication Header >> rfc4302, instead of putting it as a field in the RPL header. >> What do you think about this? Interested people? >> > > > The only issue that I see with the AH, is the size of the AH header, is > a big header. > But if we are talked of MAC security (IEEE 802.15.4-2006-MAC) lest just > to leave the MIC (CBC-MAC) as is defined by the standard, and the MIC is > just another field of the MAC frame like the field MFR. What do you > think about this?. > MAkes sense, one would like to avoid long additional data. Any more detail of comparison on length you would like to share? How long is a "big" header such as AH? And "big" compared to what? Is it much bigger than the mandatory IPv6 base header? How much additional AH header bytes are added to an RPL (IPv6 base + RPL ICMP) compared to putting the CBC-MAC in the same packet, as an RPL field. I think that delta is 96bits (the AH specific fields, figure 1 rfc4302). This is much shorter than the potentially multiple 128bits of each IPv6 address potentially in a ROuting Header of RPL. There may be certain advantages of AH specific fields: SPI, seqno field. SPI (Security parm index) helps interoperate with existing databases in existing firewalls. seqno helps with replay protection. Does CBC-MAC per se offer replay protection? Reusing AH could help an RPL node to talk to a non-RPL node, authenticated. (for same reusability reasons for which RPL is an ICMP header...) Alex >> This is a central issue to clarify. Depending on this we can see further. >> >> Alex >> >>> >>> The other option is to create a AH for RPL designed for CCM* (I don't >>> like this idea, because the IEEE 802.15.4-2006 frame already have an >>> auxiliary security header), or make modifications to IPSEC to >>> support CCM*. >>> >>> Sorry for the long email, comments are welcome. >>> >>> Best regards Rodolfo. >>> >>> -------------------------------------------------- From: "Alexandru >>> Petrescu" Sent: Friday, August 27, >>> 2010 12:34 AM To: "Rodolfo Gonzalez Bernaldez" >>> Cc: "Michael Richardson" ; >>> "ROLL WG" Subject: Re: [Roll] Messg Auth Code >>> covering the mutable IP Hop Limit >>> >>>> Le 27/08/2010 00:08, Rodolfo Gonzalez Bernaldez a écrit : >>>>> Hello Michael, Alex, all >>>>> >>>>> >>>>>> For example, one wouldn't appreciate to have both AH protection >>>>>> of the entire packet _and_ RPL CCM protection. It is >>>>>> redundant. >>>>> >>>>> >>>>> Yes I agree, that it is redundant. >>>>> >>>>> I was checking the RFC4302 section 3.3.3.1. Handling Mutable >>>>> Fields, >>>> >>>> I think that is the right section to think of. >>>> >>>>> and I didn't see any problem to use these rules only with CCM*. >>>> >>>> Well, depends how we refer to it. Intuitively, it may be easy >>>> indeed to apply that "rfc4302 mutable field" rules to CCM*. >>>> >>>> However, this may introduce new misunderstandings too. Because >>>> that section explicitely says "IPsec": >>>>> [...] If a field is mutable, but its value at the (IPsec) >>>>> receiver is predictable, then [...] >>>> >>>> Here we don't have IPsec receivers, we have CCM* receivers - they >>>> are very different: CCM* MAC is present in ICMP headers, whereas >>>> IPsec ICV is present in Authentication Header. >>>> >>>> Thus, will that rfc4302 "If" rule apply here or not? If not, then >>>> we don't know what to do here with CCM* and mutable-but-predictable >>>> fields. We would have to specify what CCM* does with them, couldn't >>>> simply refer to rfc4302. >>>> >>>> There are several mentionings of "IPsec" in that section, and here >>>> we don't currently do IPsec. >>>> >>>> To solve that, it may lead to copy&paste that section into RPL doc >>>> and substitute "CCM* MAC" for "ICV", "RPL" for "IPsec", remove >>>> IPv4, etc. Suddenly that sounds not as a simple straight referral >>>> to rfc4302. >>>> >>>> It may lead to rewriting IPsec specs altogether. >>>> >>>>> What do you think of the following statements in the security >>>>> section: -Any IPv6 frame with security must be prepared as >>>>> RFC4302 section 3.3.3.1 specified for mutable fields >>>> >>>> Ok, sounds good as first step, for mutable fields. >>>> >>>> How about the "Mutable but Predictable Fields", i.e. dst address >>>> in presence of a Routing Header. MAC should cover them too, >>>> especially knowing that a new Routing Header is under discussion in >>>> 6MAN WG, for RPL. >>>> >>>>> -ccm* computation must take IPv6 header, and/or IPv6 extension >>>>> headers as clear text, the rest of the packet must be encrypted >>>> >>>> I kind of understand and I can agree. >>>> >>>> However, will the rest of the packet (encrypted) be also applied >>>> authentication, or just leave it encrypted. This should be >>>> clarified one way or another, so implementer knows what to >>>> implement. This again risks leading to rewriting IPsec >>>> specifications. >>>> >>>> At which point I wonder why all the effort? Wouldn't it be easier >>>> to identify what's the real core of the RPL security - is it CCM* >>>> only? If yes - could we use CCM* with IPsec Authentication Header? >>>> That may be simpler to spec and implement, rather than carrying new >>>> MAC fields in ICMP. >>>> >>>>> Using these two rules statements we would be following the rules >>>>> of RFC4302, providing authentication for the entire IPv6 frame, >>>>> and we keeping encrypted RPL data. >>>> >>>> Yes, that is one possible way of doing it. >>>> >>>> I just wanted to mention that here we have a context: a number of >>>> IPv6 fields, extension headers and other standards are present - we >>>> should consider them all. >>>> >>>> Alex >>>> >>>>> >>>>> Best regards Rodolfo. >>>>> -------------------------------------------------- From: >>>>> "Alexandru Petrescu" Sent: >>>>> Thursday, August 26, 2010 7:42 AM To: "Michael Richardson" >>>>> Cc: "Rodolfo Gonzalez Bernaldez" >>>>> ; "ROLL WG" Subject: Re: >>>>> [Roll] Messg Auth Code covering the mutable IP Hop Limit >>>>> >>>>>> Le 26/08/2010 15:31, Michael Richardson a écrit : >>>>>>>>>>>> "Alexandru" == Alexandru >>>>>>>>>>>> Petrescu writes: >>>>>>> Alexandru> On another hand, risks do exist in the base >>>>>>> header Alexandru> (spoofing the src address is one widely >>>>>>> known). It is >>>>>> >>> >>> >> >> > > From alexandru.petrescu@gmail.com Tue Aug 31 13:52:26 2010 Return-Path: X-Original-To: roll@core3.amsl.com Delivered-To: roll@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0E523A6A76 for ; Tue, 31 Aug 2010 13:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.593 X-Spam-Level: X-Spam-Status: No, score=-1.593 tagged_above=-999 required=5 tests=[AWL=0.656, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ByyrWJ3JL-rM for ; Tue, 31 Aug 2010 13:52:25 -0700 (PDT) Received: from smtp1-g21.free.fr (smtp1-g21.free.fr [212.27.42.1]) by core3.amsl.com (Postfix) with ESMTP id B67A53A6B18 for ; Tue, 31 Aug 2010 13:52:20 -0700 (PDT) Received: from [127.0.0.1] (unknown [82.239.213.32]) by smtp1-g21.free.fr (Postfix) with ESMTP id 544EF9400EF; Tue, 31 Aug 2010 22:52:44 +0200 (CEST) Message-ID: <4C7D6B9A.6050108@gmail.com> Date: Tue, 31 Aug 2010 22:52:42 +0200 From: Alexandru Petrescu User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: robert.cragie@gridmerge.com References: <13773.1282327971@marajade.sandelman.ca> <4313.1282486877@marajade.sandelman.ca><4C7273DB.5080306@gridmerge.com> <4C72AF1E.9050200@gmail.com><4C73E2BE.3070603@gridmerge.com> <4C755F46.9090809@gmail.com> <0E8F884CB49749B98A5FBE5EBA5C457B@ubilogixrodo> <4C7631F3.2040409@gmail.com> <22565.1282829468@marajade.sandelman.ca> <4C767D61.2050701@gmail.com> <147D73F3BCE248AAAF5B5197C012B512@ubilogixrodo> <4C776A94.7000104@gmail.com> <687BA2A7DB004600B9CE77EEEE4D0A98@ubilogixrodo> <4C7A9CC8.8000400@gmail.com> <41D966CDE02A4DEBB9D7AA597D7D9B24@ubilogixrodo> <4C7D2596.3090108@gridmerge.com> In-Reply-To: <4C7D2596.3090108@gridmerge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Antivirus: avast! (VPS 100831-1, 31/08/2010), Outbound message X-Antivirus-Status: Clean Cc: ROLL WG Subject: Re: [Roll] Messg Auth Code covering the mutable IP Hop Limit X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Aug 2010 20:52:27 -0000 Le 31/08/2010 17:53, Robert Cragie a écrit : > Hi Rodolfo, > > I agree about treatment of mutable fields. Setting them to 0 for MAC > calculation is an acceptable way of doing it although it is a little > clumsy for inline packet security processing (done by certain > devices). The alternative would be to elide the fields completely but > this is probably more work in practice. > >> That sounds right. Provided the Hop Limit mutable field is set to 0 >> at MAC computing time by sender, and also by receiver. Your example >> seems to say so. I agree with it. >> >>> The only issue that I see at this moment is were to put the >>> CBC-MAC data, >> >> I agree, that is a right question: where to put the CBC-MAC data? >> >>> for example here we have 64 bit of CBC-MAC, we can just leave >>> them at the end of the packet or maybe create a field at the end >>> of each RPL frame with security with the name CBC-MAC or >>> something like that. >> >> I propose to put the CBC-MAC data in the Authentication Header - >> the Integrity Check Value (ICV) field of a typical Authentication >> Header rfc4302, instead of putting it as a field in the RPL >> header. What do you think about this? Interested people? >> > > The only issue that I see with the AH, is the size of the AH > header, is a big header. But if we are talked of MAC security (IEEE > 802.15.4-2006-MAC) lest just to leave the MIC (CBC-MAC) as is defined > by the standard, and the MIC is just another field of the MAC frame > like the field MFR. What do you think about this?. > > AES-CCM (SP 800-38C) specifies concatenation of the encrypted MAC > (MIC, schmac, schmic :-) at the end of the payload. I would keep it > there. It makes the MPDU larger. If doing it like this, it should be > shown on Figure 7, appended after the options. I think it would be good to agree whether encryption is absolutely needed in RPL or considered as luxury, assuming that encryption would take more computing power than very simple authentication. About placement: would an MPDU with MAC at its end be understood by a non-RPL node at the other end of the Internet (but running IPsec)? Alex > > Robert > > Robert Cragie (Pacific Gas & Electric) > > Gridmerge Ltd. 89 Greenfield Crescent, Wakefield, WF4 4WA, UK +44 > 1924 910888 +1 415 513 0064 http://www.gridmerge.com > > >