From iesg-secretary@ietf.org Mon Jan 7 07:14:51 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1D4921F88F1; Mon, 7 Jan 2013 07:14:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.213 X-Spam-Level: X-Spam-Status: No, score=-102.213 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3TtiSDqUG2V; Mon, 7 Jan 2013 07:14:51 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1792F21F8614; Mon, 7 Jan 2013 07:14:51 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130107151451.17405.93346.idtracker@ietfa.amsl.com> Date: Mon, 07 Jan 2013 07:14:51 -0800 Cc: roll@ietf.org Subject: [Roll] Last Call: (A Mechanism to Measure the Routing Metrics along a Point-to-point Route in a Low Power and Lossy Network) to Experimental RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@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, 07 Jan 2013 15:14:51 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'A Mechanism to Measure the Routing Metrics along a Point-to-point Route in a Low Power and Lossy Network' as Experimental RFC 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 2013-01-21. 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. Abstract This document specifies a mechanism that enables an RPL router to measure the aggregated values of given routing metrics along an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement/ballot/ No IPR declarations have been submitted directly on this I-D. From iesg-secretary@ietf.org Mon Jan 7 07:21:28 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE32521F892D; Mon, 7 Jan 2013 07:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.245 X-Spam-Level: X-Spam-Status: No, score=-102.245 tagged_above=-999 required=5 tests=[AWL=0.354, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iiVzqh3kN1rM; Mon, 7 Jan 2013 07:21:26 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7117421F891A; Mon, 7 Jan 2013 07:21:25 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130107152125.14939.17751.idtracker@ietfa.amsl.com> Date: Mon, 07 Jan 2013 07:21:25 -0800 Cc: roll@ietf.org Subject: [Roll] Last Call: (A Security Threat Analysis for Routing over Low Power and Lossy Networks) to Informational RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@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, 07 Jan 2013 15:21:28 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'A Security Threat Analysis for Routing over Low Power and Lossy Networks' as Informational RFC 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 2013-01-21. 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. Abstract This document presents a security threat analysis for routing over low power and lossy networks (LLN). The development builds upon previous work on routing security and adapts the assessments to the issues and constraints specific to low power and lossy networks. A systematic approach is used in defining and evaluating the security threats. Applicable countermeasures are application specific and are addressed in relevant applicability statements. These assessments provide the basis of the security recommendations for incorporation into low power, lossy network routing protocols. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-roll-security-threats/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-roll-security-threats/ballot/ No IPR declarations have been submitted directly on this I-D. From mcr@sandelman.ca Wed Jan 9 08:07:52 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AFC21F866D for ; Wed, 9 Jan 2013 08:07:52 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMwukLpipDGI for ; Wed, 9 Jan 2013 08:07:51 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 8A55621F841B for ; Wed, 9 Jan 2013 08:07:51 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5548A2016D for ; Wed, 9 Jan 2013 11:12:09 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 3269863761; Wed, 9 Jan 2013 11:07:03 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2124F636C7 for ; Wed, 9 Jan 2013 11:07:03 -0500 (EST) From: Michael Richardson to: roll@ietf.org In-Reply-To: <25865.1356111022@obiwan.sandelman.ca> References: <25865.1356111022@obiwan.sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] start of Working Group Last Call (WGLC) on draft-ietf-roll-terminology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 16:07:52 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Just a reminder of WG LC active: >Given that there are seasonal holidays starting, I am setting this >WGLC to end two weeks from Dec. 31, so for Monday 2013-01-14. In addition, there are a number of tickets still unresolved on trickle-mcas= t. I will post a summary today. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUO2Vp4qHRg3pndX9AQJbpQP+PjKlEGSiYr/riYnYmhRmw3M8fLiCggiP V6H8mnjHTWnse0DhlK5ybSOa1i7vyBgn6l5psXjKW7l4xc+2NEb7LQWu+gJ7yzC5 GZ6W3ye8FBBXg2AXK8RasibwnqtMThf4nKW+JUKuTQ/+2UVic7jlSuxqA2lltT+E mSCoItfPK+E= =mWD6 -----END PGP SIGNATURE----- --=-=-=-- From jmh@joelhalpern.com Wed Jan 9 17:46:58 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DED801F0CF5; Wed, 9 Jan 2013 17:46:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.248 X-Spam-Level: X-Spam-Status: No, score=-102.248 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z5xM+UiU3WbS; Wed, 9 Jan 2013 17:46:58 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 2C1231F0C6A; Wed, 9 Jan 2013 17:46:58 -0800 (PST) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) by morbo.tigertech.net (Postfix) with ESMTP id 7F8B2A36F6; Wed, 9 Jan 2013 17:46:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 8D7741C0B58; Wed, 9 Jan 2013 17:46:55 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from [10.155.107.75] (unknown [129.192.170.160]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 62BAA1C07B6; Wed, 9 Jan 2013 17:46:55 -0800 (PST) Message-ID: <50EE1D8F.6050407@joelhalpern.com> Date: Wed, 09 Jan 2013 20:46:55 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: "rtg-ads@tools.ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "rtg-dir@ietf.org" , roll@ietf.org, draft-ietf-roll-p2p-measurement@tools.ietf.org Subject: [Roll] RtgDir review: draft-ietf-roll-p2p-measurement-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Jan 2013 01:46:59 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-roll-p2p-measurement-07.txt Reviewer: Joel M. Halpern Review Date: 9-Januar-2013 IETF LC End Date: 21-January-2013 Intended Status: Experimental Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Generally, this is a well written and readable specification addressing an understandable problem. Major Issues: Minor Issues: I had not realized until section 4.3 that NUM (and the structure of the message) had to allow for the desired limit on the Address Accumulation. (I had originally inferred a rather painful strategy.) Could this be stated earlier in the document please? Can the first sentence of the text in the nested bullet on Source Routed Address vectors ("When the Measurement Request is traveling along a Source Route...") be moved before the description of the bits (sorry, it may need to be slightly reworded to do so.) This restriction is very helpful in understand the behaviors defined by the various flags in the message header. (Also, if it wouldn't bother the ROLL/RPL experts too much, a comment about he root not needing to add a source route for a local RPLInstance would complete the picture nicely. I am merely inferring this behavior from the fact that accumulate is allowed with hop-by-hop and local RPLInstances.) It appears that the loop prevention requirement on source routes requires every router that handles the packet to examine every entry in the source route to make sure that the inspecting router does not appear anywhere except a the current index entry. ("MUST ensure that o address appears more than once" in section 5.1, and text in section 5.3.) That would seem to be a significant cost, for no obvious benefit. Why is it required? (Yes, I have read the last bullet of section 9. This seems to be a very expensive set of extra protections. Given that the index gets increment, the cost of a loop seems pretty small.) I section 5.2 and 5.3, how can the processing node determine the "Address vector is present in the received message" if the Num field is 0? Nits: Could the first bullet in section 5.1 be re-ordered so that the condition ("if it does not know how to reach the End Point") occurs before the "MUST discard". As written, the reader is startled by thinking that the first thing the root must do is discard the request. Could the same be done to the second and third paragraphs of 5.2? And the second and third paragraphs of section 5.3? And the second paragraph of section 5.4? (The third paragraph of 5.4 has things in the order which I think is clearer for the reader.) The last sentence of the next to last paragraph of 5.5 could also be reversed, although for some unknown reason I find that one less bothersome. Section 7, second paragraph could also be usefully reversed. I presume that all the "dropped with no further processing" is not intended to preclude updating error counters and similar actions. Is there a place that could be said? Yours, Joel M. Halpern From esko.dijk@philips.com Fri Jan 11 02:51:36 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12B121F88FB for ; Fri, 11 Jan 2013 02:51:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3JcAP9BAS0Va for ; Fri, 11 Jan 2013 02:51:34 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 4321521F88EF for ; Fri, 11 Jan 2013 02:51:32 -0800 (PST) Received: from mail138-co9-R.bigfish.com (10.236.132.252) by CO9EHSOBE041.bigfish.com (10.236.130.104) with Microsoft SMTP Server id 14.1.225.23; Fri, 11 Jan 2013 10:51:31 +0000 Received: from mail138-co9 (localhost [127.0.0.1]) by mail138-co9-R.bigfish.com (Postfix) with ESMTP id 86BC4200294; Fri, 11 Jan 2013 10:51:31 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VPS-31(zz217bI15d6O9251J542Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz8275dh1033IL17326ahz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h1155h) Received: from mail138-co9 (localhost.localdomain [127.0.0.1]) by mail138-co9 (MessageSwitch) id 1357901488706988_4199; Fri, 11 Jan 2013 10:51:28 +0000 (UTC) Received: from CO9EHSMHS031.bigfish.com (unknown [10.236.132.226]) by mail138-co9.bigfish.com (Postfix) with ESMTP id 9B51F14005A; Fri, 11 Jan 2013 10:51:28 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS031.bigfish.com (10.236.130.41) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 11 Jan 2013 10:51:26 +0000 Received: from 011-DB3MPN2-082.MGDPHG.emi.philips.com ([169.254.2.241]) by 011-DB3MMR1-002.MGDPHG.emi.philips.com ([10.128.28.52]) with mapi id 14.02.0318.003; Fri, 11 Jan 2013 10:51:25 +0000 From: "Dijk, Esko" To: Michael Richardson , "roll@ietf.org" Thread-Topic: [Roll] start of Working Group Last Call (WGLC) on draft-ietf-roll-terminology Thread-Index: AQHN36MQsVYf2gBMIUGYkWphKQRdCZhEEwQA Date: Fri, 11 Jan 2013 10:51:24 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B5EFFA@011-DB3MPN2-082.MGDPHG.emi.philips.com> References: <28228.1356111726@obiwan.sandelman.ca> In-Reply-To: <28228.1356111726@obiwan.sandelman.ca> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.94.216.29] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Subject: Re: [Roll] start of Working Group Last Call (WGLC) on draft-ietf-roll-terminology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 10:51:36 -0000 Dear Michael, all, here is one WGLC comment: the draft does not yet contain the definition of = 'RPL domain' which still needed to be added. (Outcome of list discussion en= ding with this message http://www.ietf.org/mail-archive/web/roll/current/ms= g06561.html) RFC 6550 uses this definition so it would be useful to have in. regards, Esko -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mic= hael Richardson Sent: Friday 21 December 2012 18:42 To: roll@ietf.org Subject: [Roll] start of Working Group Last Call (WGLC) on draft-ietf-roll-= terminology The document https://datatracker.ietf.org/doc/draft-ietf-roll-terminology was always intended to be published as an Informational RFC along with RFC6= 550, but it fell between the cracks. This became obvious when other working groups tried to reference it. I am starting a Working Group Last Call on this document. We have had significant discussion of this document in 2010 and 2011. Version 07 was posted, some minor revisions produced version 08. Given that there are seasonal holidays starting, I am setting this WGLC to = end two weeks from Dec. 31, so for Monday 2013-01-14. I do not believe that there is anything controversial about this document. If you have comments on this document, please post them to this list. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From prvs=716e5d5b3=mukul@uwm.edu Fri Jan 11 06:00:47 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C92AD21F8984 for ; Fri, 11 Jan 2013 06:00:47 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9eOAeEeQhGGX for ; Fri, 11 Jan 2013 06:00:47 -0800 (PST) Received: from ip3mta.uwm.edu (ip3mta.uwm.edu [129.89.7.192]) by ietfa.amsl.com (Postfix) with ESMTP id 0DE0921F8976 for ; Fri, 11 Jan 2013 06:00:46 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EADka8FB/AAAB/2dsb2JhbABEhjm3VoMRAQEBBAEBASBLCwwPEQQBAQMCDRYDAikfCQgGEwmIEAylGIlEhhCBIos6G4MVgRMDiGCNKoEcjy2DFIFQNQ Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id F2C4F2E0D7A; Fri, 11 Jan 2013 08:00:45 -0600 (CST) X-Virus-Scanned: amavisd-new at Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHCL3ahsyCcI; Fri, 11 Jan 2013 08:00:45 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 9EE772E0D75; Fri, 11 Jan 2013 08:00:45 -0600 (CST) Date: Fri, 11 Jan 2013 08:00:45 -0600 (CST) From: Mukul Goyal To: Esko Dijk Message-ID: <1682836180.361975.1357912845498.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B5EFFA@011-DB3MPN2-082.MGDPHG.emi.philips.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] start of Working Group Last Call (WGLC) on draft-ietf-roll-terminology X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 14:00:47 -0000 Section 1 of RFC 6554 defines RPL routing domain in an informal manner: "A RPL routing domain is a collection of RPL routers under the control of a single administration. The boundaries of routing domains are defined by network management by setting some links to be exterior, or inter- domain, links. " It will be good if the terminology draft could include this definition formally. Thanks Mukul ----- Original Message ----- From: "Esko Dijk" To: "Michael Richardson" , roll@ietf.org Sent: Friday, January 11, 2013 4:51:24 AM Subject: Re: [Roll] start of Working Group Last Call (WGLC) on draft-ietf-roll-terminology Dear Michael, all, here is one WGLC comment: the draft does not yet contain the definition of 'RPL domain' which still needed to be added. (Outcome of list discussion ending with this message http://www.ietf.org/mail-archive/web/roll/current/msg06561.html) RFC 6550 uses this definition so it would be useful to have in. regards, Esko -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Michael Richardson Sent: Friday 21 December 2012 18:42 To: roll@ietf.org Subject: [Roll] start of Working Group Last Call (WGLC) on draft-ietf-roll-terminology The document https://datatracker.ietf.org/doc/draft-ietf-roll-terminology was always intended to be published as an Informational RFC along with RFC6550, but it fell between the cracks. This became obvious when other working groups tried to reference it. I am starting a Working Group Last Call on this document. We have had significant discussion of this document in 2010 and 2011. Version 07 was posted, some minor revisions produced version 08. Given that there are seasonal holidays starting, I am setting this WGLC to end two weeks from Dec. 31, so for Monday 2013-01-14. I do not believe that there is anything controversial about this document. If you have comments on this document, please post them to this list. -- Michael Richardson , Sandelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message. _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=716e5d5b3=mukul@uwm.edu Fri Jan 11 07:09:10 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C93CA21F886F for ; Fri, 11 Jan 2013 07:09:10 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+0yVTHCOqhZ for ; Fri, 11 Jan 2013 07:09:10 -0800 (PST) Received: from ip3mta.uwm.edu (ip3mta.uwm.edu [129.89.7.192]) by ietfa.amsl.com (Postfix) with ESMTP id CE82B21F880B for ; Fri, 11 Jan 2013 07:09:09 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAFsq8FB/AAAB/2dsb2JhbABBA4Y5t1qDEQEBBSNWDAINDgIBBAEBAwINGQIdNAgGE4gZpT2JRIYQBIEfjFWCG4ETA4hhjSqQSYMUggU Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 1ABA8120E6D; Fri, 11 Jan 2013 09:09:09 -0600 (CST) X-Virus-Scanned: amavisd-new at 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 wkVvHvo3uVUa; Fri, 11 Jan 2013 09:09:08 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id A39F2120E65; Fri, 11 Jan 2013 09:09:08 -0600 (CST) Date: Fri, 11 Jan 2013 09:09:08 -0600 (CST) From: Mukul Goyal To: Juergen Schoenwaelder Message-ID: <669995897.363060.1357916948558.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20130111130838.GA4530@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: Re: [Roll] OPS-DIR review for draft-ietf-roll-p2p-measurement-07 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Jan 2013 15:09:11 -0000 Thanks. I thought I will send your review to ROLL list as well. Mukul ----- Original Message ----- From: "Juergen Schoenwaelder" To: ops-dir@ietf.org, draft-ietf-roll-p2p-measurement@tools.ietf.org Cc: ops-ads@tools.ietf.org Sent: Friday, January 11, 2013 7:08:38 AM Subject: OPS-DIR review for draft-ietf-roll-p2p-measurement-07 I have reviewed draft-ietf-roll-p2p-measurement-07 as part of the operations directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the ops area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies a mechanism that allows an RPL router to measure aggregated values of routing metrics along an existing path towards another RPL router. The idea is that an RPL router may use this information to decide whether it is worth to establish a P2P route towards a certain destination. The security considerations discuss certain possible ways to misuse the mechanism and that RPL routers may deal with some of them by not processing all requests according to local policy. It is not further detailed how such policy is configured (this is also true for the policy on which it is decided to attempt establishing a P2P path) or monitored. Since this document goes for Experimental, I think this is fine (and inline with the fact that there is in general no specification how to configure or monitor RPL routers in general and in some of the deloyment scenarios, the policy likely will be hard wired into certain types of devices). Bottom line: I think the document is fine to go ahead. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From prvs=72081a62a=mukul@uwm.edu Mon Jan 14 23:43:49 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF0321F8B11; Mon, 14 Jan 2013 23:43:49 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id An5A0tHCJhQN; Mon, 14 Jan 2013 23:43:48 -0800 (PST) Received: from ip3mta.uwm.edu (ip3mta.uwm.edu [129.89.7.192]) by ietfa.amsl.com (Postfix) with ESMTP id C7D9221F8B0C; Mon, 14 Jan 2013 23:43:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAIoH9VB/AAAB/2dsb2JhbAA6CoY6t1GDEQEBBSNIDgwPFAYCDRkCWQaILAylPoJAhzCHBQSBI4tZBYMagRMDiGGCcYcGgzOGWolvgxSBRwEfBBo Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id 3E4C21209DF; Tue, 15 Jan 2013 01:43:47 -0600 (CST) X-Virus-Scanned: amavisd-new at Received: from mta03.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta03.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VWvuD0D1dh64; Tue, 15 Jan 2013 01:43:46 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id EEECE120960; Tue, 15 Jan 2013 01:43:46 -0600 (CST) Date: Tue, 15 Jan 2013 01:43:46 -0600 (CST) From: Mukul Goyal To: "Joel M. Halpern" Message-ID: <73569540.396597.1358235826869.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <50EE1D8F.6050407@joelhalpern.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - IE8 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: rtg-dir@ietf.org, roll@ietf.org, draft-ietf-roll-p2p-measurement@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [Roll] RtgDir review: draft-ietf-roll-p2p-measurement-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 07:43:49 -0000 Hi Joel Thanks for your review. I have made changes to the draft based on your comments. The modified draft can be seen at: https://pantherfile.uwm.edu/mukul/public/files/draft-ietf-roll-p2p-measurement-08.txt I will include these changes in the new version to be posted at the conclusion of the last call. Please see my response to your comments below and let me know if the modifications to the draft look OK to you. Thanks Mukul ----- Original Message ----- Document: draft-ietf-roll-p2p-measurement-07.txt Reviewer: Joel M. Halpern Review Date: 9-Januar-2013 IETF LC End Date: 21-January-2013 Intended Status: Experimental Summary: I have some minor concerns about this document that I think should be resolved before publication. Comments: Generally, this is a well written and readable specification addressing an understandable problem. Major Issues: Minor Issues: --------------------------------------------------------- [JH] I had not realized until section 4.3 that NUM (and the structure of the message) had to allow for the desired limit on the Address Accumulation. (I had originally inferred a rather painful strategy.) Could this be stated earlier in the document please? [MG] Done. Please see the text between (mods_1_begin) and (mods_1_end) tags in Sections 2 and 3. [JH] Can the first sentence of the text in the nested bullet on Source Routed Address vectors ("When the Measurement Request is traveling along a Source Route...") be moved before the description of the bits (sorry, it may need to be slightly reworded to do so.) This restriction is very helpful in understand the behaviors defined by the various flags in the message header. [MG] Done. Please see the text between (mods_1_begin) and (mods_1_end) tags in Section 2. [JH] (Also, if it wouldn't bother the ROLL/RPL experts too much, a comment about he root not needing to add a source route for a local RPLInstance would complete the picture nicely. I am merely inferring this behavior from the fact that accumulate is allowed with hop-by-hop and local RPLInstances.) [MG] To respond to your comment, I thought long and hard about including a brief section on global/local RPLInstanceIDs, storing/non-storing DAGs and other such RPL delicacies and then decided against it. I think this document is not the right place for such details. The biggest concern was that it would be impossible to keep the section "brief". I think RPL and P2P-RPL documents must be referred to get these details. I did add a tiny bit of text in the Overview Section (see the tags mods_2_...) regarding how Source/Hop-by-hop routes are identified. BTW, the specific comment you sought would go some thing like this: RPL provides local RPLInstanceIDs to allow routers to create local DAGs. P2P-RPL uses local RPLInstanceIDs in a particular fashion. Under P2P-RPL, a router (the Origin) discovers a route by creating (by acting as the root for) a temporary DAG that is identified by one of the Origin's IPv6 addresses and a local RPLInstanceID. The temporary DAG dies soon after a Source Route has been discovered or a Hop-by-hop Route has been established. Such a Hop-by-hop route, discovered using P2P-RPL, is identified by the same tuple that was used to identify the temporary DAG. So, a route discovered using P2P-RPL is always either a pure Source Route or a pure Hop-by-hop route and is never a "mixed" route. [JH] It appears that the loop prevention requirement on source routes requires every router that handles the packet to examine every entry in the source route to make sure that the inspecting router does not appear anywhere except a the current index entry. ("MUST ensure that o address appears more than once" in section 5.1, and text in section 5.3.) That would seem to be a significant cost, for no obvious benefit. Why is it required? (Yes, I have read the last bullet of section 9. This seems to be a very expensive set of extra protections. Given that the index gets increment, the cost of a loop seems pretty small.) [MG] You are right. I realized there is no real need for an Intermediate Point to check for loops. I also realized that this check does not always protect against a rogue Intermediate Point modifying the Address vector to insert a routing loop (suppose the nodes that appear multiple times in the modified Address vector wont see this Measurement Request). I have removed from the text this unnecessary check as well as the reference to it in the Security section. [JH] I section 5.2 and 5.3, how can the processing node determine the "Address vector is present in the received message" if the Num field is 0? [MG] Right. The Num value is the only way to tell whether an Address vector is present or not. Corrected the language everywhere. [JH] Nits: Could the first bullet in section 5.1 be re-ordered so that the condition ("if it does not know how to reach the End Point") occurs before the "MUST discard". As written, the reader is startled by thinking that the first thing the root must do is discard the request. Could the same be done to the second and third paragraphs of 5.2? And the second and third paragraphs of section 5.3? And the second paragraph of section 5.4? (The third paragraph of 5.4 has things in the order which I think is clearer for the reader.) [MG] Done. [JH] The last sentence of the next to last paragraph of 5.5 could also be reversed, although for some unknown reason I find that one less bothersome. [MG] OK. I did not change this particular sentence. [JH] Section 7, second paragraph could also be usefully reversed. [MG] Done. [JH] I presume that all the "dropped with no further processing" is not intended to preclude updating error counters and similar actions. Is there a place that could be said? [MG] Right. Added the relevant text towards the end of Section 3.1 (look for tags mods_3_...). Thanks Mukul From robert.cragie@gridmerge.com Tue Jan 15 00:13:23 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52AA21F8840 for ; Tue, 15 Jan 2013 00:13:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhv6-QjOOhmB for ; Tue, 15 Jan 2013 00:13:22 -0800 (PST) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 6297F21F883F for ; Tue, 15 Jan 2013 00:13:17 -0800 (PST) Received: from client-86-23-89-86.brhm.adsl.virginmedia.com ([86.23.89.86] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77) id 1Tv1e0-0006k8-3s for roll@ietf.org; Tue, 15 Jan 2013 08:13:16 +0000 Message-ID: <50F51018.9090705@gridmerge.com> Date: Tue, 15 Jan 2013 08:15:20 +0000 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: roll@ietf.org References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> <50932647.3050509@exegin.com> <5094202F.4010805@exegin.com> <509C03C2.50809@exegin.com> <509C5F00.2050204@exegin.com> <509D5AF5.4040304@exegin.com> <509DAFEF.5020504@exegin.com> <9143.1352758442@sandelman.ca> <50A382DA.9030706@gridmerge.com> <2150.1352927633@obiwan.sandelman.ca> <50A505AC.2000200@gridmerge.com> <21507.1356119684@sandelman.ca> In-Reply-To: <21507.1356119684@sandelman.ca> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020205030307000706040104" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 15 Jan 2013 08:13:23 -0000 This is a cryptographically signed message in MIME format. --------------ms020205030307000706040104 Content-Type: multipart/alternative; boundary="------------000604080507060202020809" This is a multi-part message in MIME format. --------------000604080507060202020809 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable Hi Michael, There isn't really a need for both #3 (subnet-local mc address) and #4=20 (link-local mc address) as they are both mechanisms for encapsulating a=20 mc message originating from or destined for outside the MPL Domain. I=20 think the original aim was to keep the specification flexible for=20 implementation choice. The latest draft will only specify #3. Robert On 21/12/2012 7:54 PM, Michael Richardson wrote: > (It has come to my attention that additional spam filtering @ietf.org > was dropping many of my emails, this is a resend) > >>>>>> "Robert" =3D=3D Robert Cragie writes= : > Robert> Almost there. In the case of forwarding using MPL > Robert> domain (subnet-local) mc address, the inner packet is > Robert> strictly tunnelled, i.e. there will be no hop count > Robert> decrementing per hop. I discussed this offline with Jonath= an > > okay, and this is because the packet is in a tunnel, which is not > addressed to the "link", so in effect, it is not a local packet. > > I can buy this, and so #3 does not decrement, while #4 does. > > What is the use case for #3 and what is the use case for #4? > What I'm trying to get at here is: what is the argument to have both? > > Who is going to need each one? > > On 14/11/2012 9:13 PM, Michael Richardson wrote: >> Robert, has written 3 rules about when to encapsulate, and how to >> recognize the MPL domain. With two options #3 and #4. >> >> the difference is (#3): >> >>> 2. Outer header will have subnet-local mc address (e.g. >>> FF03-based). This can be used to control propagation in >>> conjunction with the MPL option. >> vs (#4) >> >> < 2. Outer header will have link-local mc address (e.g. FF02-based)= =2E >> < This cannot be used to control propagation as it only goes one= >> < hop; the MPL option is used alone >> >> and as far as I can understand in both cases MPL forwarders will >> decapsulate and re-encapsulate, thus decrementing the inner TTL each >> time. Or did I misunderstand here? > > > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll --------------000604080507060202020809 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Michael,

There isn't really a need for both #3 (subnet-local mc address) and #4 (link-local mc address) as they are both mechanisms for encapsulating a mc message originating from or destined for outside the MPL Domain. I think the original aim was to keep the specification flexible for implementation choice. The latest draft will only specify #3.

Robert

On 21/12/2012 7:54 PM, Michael Richardson wrote:
= 
(It has come to my attention that additional spam filtering @ietf.org
was dropping many of my emails, this is a resend)


"Robert" =3D=3D Robert Cragie <ro=
bert.cragie@gridmerge.com> writes:

    Robert> <RCC> Almost there. In the case=
 of forwarding using MPL
    Robert> domain (subnet-local) mc address, the inner packet is
    Robert> strictly tunnelled, i.e. there will be no hop count
    Robert> decrementing per hop. I discussed this offline with Jonath=
an

okay, and this is because the packet is in a tunnel, which is not
addressed to the "link", so in effect, it is not a local packet.

I can buy this, and so #3 does not decrement, while #4 does.

What is the use case for #3 and what is the use case for #4?
What I'm trying to get at here is: what is the argument to have both?

Who is going to need each one?

On 14/11/2012 9:13 PM, Michael Richardson wrote:

Robert, has written 3 rules about when to encapsul=
ate, and how to
recognize the MPL domain.  With two options #3 and #4.

the difference is  (#3):


    2. Outer header will have subnet-local mc ad=
dress (e.g.
       FF03-based). This can be used to control propagation in
       conjunction with the MPL option.

vs (#4)

<    2. Outer header will have link-local mc address (e.g. FF02-based)=
=2E
<       This cannot be used to control propagation as it only goes one=

<       hop; the MPL option is used alone

and as far as I can understand in both cases MPL forwarders will
decapsulate and re-encapsulate, thus decrementing the inner TTL each
time.   Or did I misunderstand here?








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

--------------000604080507060202020809-- --------------ms020205030307000706040104 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzAxMTUwODE1MjBaMCMGCSqGSIb3DQEJBDEWBBT2kGQNhfsuW36RCPrqUhk6pdK9fjBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBABMxZ2cvC1001+wQZq7sGbZHdX080C7lt6vpDpn1OS5xm8C1 XjlMWqM/+XgSbEIzyHDZR6hYZv7QPyCbOali5AyflXO6HYRH3yXHW/Ev6KmZ/1TVDlxNELcX zeCQ4c2h/0Ckv6/oKo08tIfgx3gGjAsLsc8X+BUBnSvv50DW0Sr41+Abk6KbFNXTQ6q7ddsB 4FqMgcHA2G+k05lr+C+oGUysAXi1yWCOjDNPuvTfp9a1EVad1jLo/76+tNocwIrwoAM8uvfB jVJUd1uk2ZLwUhNqj3rTXp/s4X1dr7rGLgSnKCyO230e3W8niSqrp1k6xYTMYqQTQ5uhxvGS CtlRkgwAAAAAAAA= --------------ms020205030307000706040104-- From jmh@joelhalpern.com Tue Jan 15 11:51:03 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F5E611E809A; Tue, 15 Jan 2013 11:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d79S98oX769y; Tue, 15 Jan 2013 11:51:01 -0800 (PST) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6481B11E8099; Tue, 15 Jan 2013 11:51:01 -0800 (PST) Received: from mailc2.tigertech.net (mailc2.tigertech.net [208.80.4.156]) by morbo.tigertech.net (Postfix) with ESMTP id 164A7A6672; Tue, 15 Jan 2013 11:51:01 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailc2.tigertech.net (Postfix) with ESMTP id 5E298181116; Tue, 15 Jan 2013 11:51:00 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at c2.tigertech.net Received: from [10.10.10.104] (pool-70-106-135-60.clppva.east.verizon.net [70.106.135.60]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailc2.tigertech.net (Postfix) with ESMTPSA id E7015181112; Tue, 15 Jan 2013 11:50:58 -0800 (PST) Message-ID: <50F5B320.2050108@joelhalpern.com> Date: Tue, 15 Jan 2013 14:50:56 -0500 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Mukul Goyal References: <73569540.396597.1358235826869.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <73569540.396597.1358235826869.JavaMail.root@mail17.pantherlink.uwm.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: rtg-dir@ietf.org, roll@ietf.org, draft-ietf-roll-p2p-measurement@tools.ietf.org, rtg-ads@tools.ietf.org Subject: Re: [Roll] [RTG-DIR] RtgDir review: draft-ietf-roll-p2p-measurement-07.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jan 2013 19:51:03 -0000 Thank you very much. These changes very nicely address my concerns. I can understood why you chose not to make the one change about route construction restrictions. Your modified text does help that somewhat, without being verbose, and I can live with that. Yours, Joel On 1/15/2013 2:43 AM, Mukul Goyal wrote: > Hi Joel > > Thanks for your review. I have made changes to the draft based on your comments. The modified draft can be seen at: > > https://pantherfile.uwm.edu/mukul/public/files/draft-ietf-roll-p2p-measurement-08.txt > > I will include these changes in the new version to be posted at the conclusion of the last call. > > Please see my response to your comments below and let me know if the modifications to the draft look OK to you. > > Thanks > Mukul > > ----- Original Message ----- > > Document: draft-ietf-roll-p2p-measurement-07.txt > > Reviewer: Joel M. Halpern > Review Date: 9-Januar-2013 > IETF LC End Date: 21-January-2013 > Intended Status: Experimental > > Summary: I have some minor concerns about this document that I think > should be resolved before publication. > > Comments: > Generally, this is a well written and readable specification > addressing an understandable problem. > > Major Issues: > > Minor Issues: > --------------------------------------------------------- > [JH] > I had not realized until section 4.3 that NUM (and the structure of > the message) had to allow for the desired limit on the Address > Accumulation. (I had originally inferred a rather painful strategy.) > Could this be stated earlier in the document please? > > [MG] > Done. Please see the text between (mods_1_begin) and (mods_1_end) tags in Sections 2 and 3. > > [JH] > Can the first sentence of the text in the nested bullet on Source > Routed Address vectors ("When the Measurement Request is traveling along > a Source Route...") be moved before the description of the bits (sorry, > it may need to be slightly reworded to do so.) This restriction is very > helpful in understand the behaviors defined by the various flags in the > message header. > > [MG] > Done. Please see the text between (mods_1_begin) and (mods_1_end) tags in Section 2. > > [JH] > (Also, if it wouldn't bother the ROLL/RPL experts too > much, a comment about he root not needing to add a source route for a > local RPLInstance would complete the picture nicely. I am merely > inferring this behavior from the fact that accumulate is allowed with > hop-by-hop and local RPLInstances.) > > [MG] > To respond to your comment, I thought long and hard about including a brief section on global/local RPLInstanceIDs, storing/non-storing DAGs and other such RPL delicacies and then decided against it. I think this document is not the right place > for such details. The biggest concern was that it would be impossible to keep the section "brief". I think RPL and P2P-RPL documents must be referred to get these details. I did add a tiny bit of text in the Overview Section (see the tags mods_2_...) regarding how Source/Hop-by-hop routes are identified. > > BTW, the specific comment you sought would go some thing like this: RPL provides local RPLInstanceIDs to allow routers to create local DAGs. P2P-RPL uses local RPLInstanceIDs in a particular fashion. Under P2P-RPL, a router (the Origin) discovers a route by creating (by acting as the root for) a temporary DAG that is identified by one of the Origin's IPv6 addresses and a local RPLInstanceID. The temporary DAG dies soon after a Source Route has been discovered or a Hop-by-hop Route has been established. Such a Hop-by-hop route, discovered using P2P-RPL, is identified by the same tuple that was used to identify the temporary DAG. So, a route discovered using P2P-RPL is always either a pure Source Route or a pure Hop-by-hop route and is never a "mixed" route. > > [JH] > It appears that the loop prevention requirement on source routes > requires every router that handles the packet to examine every entry in > the source route to make sure that the inspecting router does not appear > anywhere except a the current index entry. ("MUST ensure that o address > appears more than once" in section 5.1, and text in section 5.3.) That > would seem to be a significant cost, for no obvious benefit. Why is it > required? (Yes, I have read the last bullet of section 9. This seems > to be a very expensive set of extra protections. Given that the index > gets increment, the cost of a loop seems pretty small.) > > [MG] > You are right. I realized there is no real need for an Intermediate Point to check for loops. I also realized that this check does not always protect against a rogue Intermediate Point modifying the Address vector to insert a routing loop (suppose the nodes that appear multiple times in the modified Address vector wont see this Measurement Request). I have removed from the text this unnecessary check as well as the reference to it in the Security section. > > [JH] > I section 5.2 and 5.3, how can the processing node determine the > "Address vector is present in the received message" if the Num field is 0? > > [MG] > Right. The Num value is the only way to tell whether an Address vector is present or not. Corrected the language everywhere. > > [JH] > Nits: > Could the first bullet in section 5.1 be re-ordered so that the > condition ("if it does not know how to reach the End Point") occurs > before the "MUST discard". As written, the reader is startled by > thinking that the first thing the root must do is discard the request. > Could the same be done to the second and third paragraphs of 5.2? > And the second and third paragraphs of section 5.3? > And the second paragraph of section 5.4? (The third paragraph of > 5.4 has things in the order which I think is clearer for the reader.) > > [MG] > Done. > > [JH] > The last sentence of the next to last paragraph of 5.5 could also > be reversed, although for some unknown reason I find that one less > bothersome. > > [MG] > OK. I did not change this particular sentence. > > [JH] > Section 7, second paragraph could also be usefully reversed. > > [MG] > Done. > > [JH] > I presume that all the "dropped with no further processing" is not > intended to preclude updating error counters and similar actions. Is > there a place that could be said? > > [MG] > Right. Added the relevant text towards the end of Section 3.1 (look for tags mods_3_...). > > Thanks > Mukul > From internet-drafts@ietf.org Wed Jan 16 22:47:24 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9F9B21F8B1A; Wed, 16 Jan 2013 22:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.514 X-Spam-Level: X-Spam-Status: No, score=-102.514 tagged_above=-999 required=5 tests=[AWL=0.085, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvcjbiCdlWww; Wed, 16 Jan 2013 22:47:24 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16E7921F8B1E; Wed, 16 Jan 2013 22:47:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130117064724.4425.19789.idtracker@ietfa.amsl.com> Date: Wed, 16 Jan 2013 22:47:24 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-terminology-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 06:47:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : Terminology in Low power And Lossy Networks Author(s) : JP Vasseur Filename : draft-ietf-roll-terminology-09.txt Pages : 8 Date : 2013-01-16 Abstract: The documents defines a terminology for discussing routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). A LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g. Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-terminology There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-terminology-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-terminology-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From russw@riw.us Wed Jan 16 18:24:04 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BF011E809C; Wed, 16 Jan 2013 18:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.796 X-Spam-Level: X-Spam-Status: No, score=-0.796 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, LONGWORDS=1.803] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzWMWRBSVYyW; Wed, 16 Jan 2013 18:24:03 -0800 (PST) Received: from da31.namelessnet.net (da31.namelessnet.net [74.124.205.66]) by ietfa.amsl.com (Postfix) with ESMTP id B385C1F0CF5; Wed, 16 Jan 2013 18:24:03 -0800 (PST) Received: from [216.53.138.131] (helo=[10.96.7.37]) by da31.namelessnet.net with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Tvf98-0004KU-Sk; Wed, 16 Jan 2013 18:24:03 -0800 Message-ID: <50F760C5.4030700@riw.us> Date: Wed, 16 Jan 2013 21:24:05 -0500 From: Russ White User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: rtg-ads@tools.ietf.org Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Antivirus-Scanner: Seems clean. You should still use an Antivirus Scanner X-Mailman-Approved-At: Mon, 21 Jan 2013 06:09:20 -0800 Cc: rtg-dir@ietf.org, roll@ietf.org, draft-ietf-roll-security-threats-00.all@tools.ietf.org Subject: [Roll] RtgDir review: X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jan 2013 02:24:04 -0000 Hello, I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-roll-security-threats-00.txt Reviewer: Russ White Review Date: 16 January 2013 IETF LC End Date: unknown Intended Status: Informational Summary: I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Comments: Philosophically, this document seems to treat routing as an "entity," that operates by itself, independent of other systems, within a network. In real networks, routing is primarily used to provide for forwarding, so security should really be couched in terms of how breaches in routing security impact forwarding. The direction taken in this draft leads to a single end --the encryption of all routing information carried through the network. I would really like to see routing security take a more creative turn, seeing routing as a part of an overall system, rather than as an end to end flow of information that must be secured in its own right --as "just another data stream." Specifically, the goals in section 3.4 would necessarily be resolvable only through the use of some form encrypted transport of routing information, which could easily overcome any possible low powered device in complexity and difficulty. It seems, to me, a better overall goal would be to ensure the routing database accurately reflects the actual state of the network topology, allowing for any means that will reach this goal, whether or not they include cryptography. A wider net is more likely to produce a stronger set of available options. The problems noted in section 4 are, in fact, countered with proposals in sections 5 and 6 that only propse cryptographic mechanisms generally planned around encrypting routing exchanges and/or signing routing information on the wire, adding weight to my thoughts above. It seems, to me, that sections 5 and 6 should be moved to a separate draft, so the general overview of the problems and possible solutions are decoupled a bit, to allow “breathing room,” for possible alternate solutions. == My one concern about section 3.2 is one of the implications carried in the statement, “non-repudiation will involve providing some ability to allow traceability or network management review of participants of the routing process including the ability to determine the events and actions leading to a particular routing state.” This implies, at least to me, that the actual processing of routing updates need to be logged in a way that prevents tampering at every node, as well as the actual routing updates received, transmitted, and otherwise handled by each node in the network — especially since routing is not always atomic, but rather timing dependent. How this particular “possible requirement,” might be implanted in a way that is practical. == The taxonomy in section 4 appears to be solid. == Overall, I found the writing style to be a bit opaque/obtuse — difficult to read in parts, perhaps a little “research,” if that makes sense. Some specific comments on the first few paragraphs are below, but I didn’t spend a great deal of time working through specific grammar issues throughout the entire document. == This document presents a framework for securing Routing Over LLNs (ROLL)... Using an acronym to expand another acronym will probably confuse at least some readers. LLNs also needs to be explained at it's first use. == Security, in essence, entails implementing measures to ensure controlled state changes... I'm not certain what's meant by "controlled," here, or how it relates to security. Is "unsecured," information about state changes therefore "uncontrolled?" Is "verifiable," what you're after here, or perhaps, "authorized," or... ?? == State changes would thereby involve proper authorization for actions, authentication, and potentially confidentiality, but also proper order of state changes through timeliness (since seriously delayed state changes, such as commands or updates of routing tables, may negatively impact system operation). Perhaps something like: Securing information about state changes would include ensuring devices match their claimed role (authentication), transmitted state changes are correct and allowed through policy (authorization), state changes are only visible to authorized devices (confidentiality), and operations are taken in the proper order (timeliness and atomicity). == An asset implies an important system component (including information, process, or physical resource), the access to, corruption or loss of which adversely affects the system. In network routing, assets lie in the routing information, routing process, and node's physical resources. That is, the access to, corruption, or loss of these elements adversely affects system routing. Perhaps something like: In the control plane context, an asset is information about the network, processes used to manage and manipulate this data, and the physical devices on which this data is stored and manipulated. The corruption or loss of these assets may adversely impact the control plane of the network. (Note you shouldn't imply any such breach "will," disrupt routing, because routing systems are, at base, designed to be resilient to information loss and corruption. There are some situations where loss or corruption will result in misrouted or lost data flows, but there are others where it will not.) == In network routing, a point of access refers to the point of entry facilitating communication with or other interaction with a system component in order to use system resources to either manipulate information or gain knowledge of the information contained within the system. Perhaps something like: Within the same context, a point of access is an interface or protocol that facilitates interaction between control plane components. == Security of the routing protocol must be focused on the assets of the routing nodes and the points of access of the information exchanges and information storage that may permit routing compromise. This sentence doesn't add to the flow of thought, so I would just remove it. == The identification of routing assets and points of access hence provides a basis for the identification of associated threats and attacks. Perhaps something like: Identifying these assets and points of access will provide a basis for enumerating the attack surface of the control plane. == This subsection identifies assets and points of access of a generic routing process with a level-0 data flow diagram [Yourdon1979] revealing how the routing protocol interacts with its environment. In particular, the use of the data flow diagram allows for a clear, concise model of the routing functionality; it also has the benefit of showing the manner in which nodes participate in the routing process, thus providing context when later threats and attacks are considered. Perhaps something like: A level-0 data flow diagram [Yourdon1979] is used here to identify the assets and points of access within a generic routing process. The use of a data flow diagram allows for a clear and concise model of the way in which routing nodes interact and process information, and hence provides a context for threats and attacks. Major Issues: My primary concern is the general philosophy within the draft --see my comments above. The working group may decide this philosophy is acceptable/good, but it should be brought out onto the table and discussed, and some explanation of why this path was chosen provided in the draft, rather than assumed, IMHO. Minor Issues: Writing style, as indicated in my comments above. == HTH :-) Russ From internet-drafts@ietf.org Mon Jan 21 11:13:14 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA41321F85B8; Mon, 21 Jan 2013 11:13:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ULzhyfXzV1Kw; Mon, 21 Jan 2013 11:13:14 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46AA921F8586; Mon, 21 Jan 2013 11:13:14 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130121191314.710.42628.idtracker@ietfa.amsl.com> Date: Mon, 21 Jan 2013 11:13:14 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-08.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 19:13:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : A Mechanism to Measure the Routing Metrics along a Point= -to-point Route in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-08.txt Pages : 25 Date : 2013-01-21 Abstract: This document specifies a mechanism that enables an RPL router to measure the aggregated values of given routing metrics along an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-p2p-measurement-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-p2p-measurement-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=726f547c2=mukul@uwm.edu Mon Jan 21 11:19:34 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84E9421F8645 for ; Mon, 21 Jan 2013 11:19:34 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mrCoIqyHdY0u for ; Mon, 21 Jan 2013 11:19:34 -0800 (PST) Received: from ip4mta.uwm.edu (ip4mta.uwm.edu [129.89.7.194]) by ietfa.amsl.com (Postfix) with ESMTP id 58BFD21F85C3 for ; Mon, 21 Jan 2013 11:19:33 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 29D422E1740; Mon, 21 Jan 2013 13:19:32 -0600 (CST) X-Virus-Scanned: amavisd-new at Received: from mta02.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta02.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id njH16dBChWjv; Mon, 21 Jan 2013 13:19:31 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id EDA612E173C; Mon, 21 Jan 2013 13:19:31 -0600 (CST) Date: Mon, 21 Jan 2013 13:19:31 -0600 (CST) From: Mukul Goyal To: "Joel M. Halpern" Message-ID: <820751917.10410.1358795971929.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20130121191314.710.42628.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - SAF3 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-08.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jan 2013 19:19:34 -0000 This version contains changes based on Joel Halpern's comments. I had earlier sent an email to the list that detailed these changes. Thanks Mukul ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Monday, January 21, 2013 1:13:14 PM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-08.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : A Mechanism to Measure the Routing Metrics along a Point-to-point Route in a Low Power and Lossy Network Author(s) : Mukul Goyal Emmanuel Baccelli Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-measurement-08.txt Pages : 25 Date : 2013-01-21 Abstract: This document specifies a mechanism that enables an RPL router to measure the aggregated values of given routing metrics along an existing route towards another RPL router in a low power and lossy network, thereby allowing the router to decide if it wants to initiate the discovery of a better route. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-measurement There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-p2p-measurement-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-p2p-measurement-08 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From internet-drafts@ietf.org Tue Jan 22 06:40:09 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785DA21F85EA; Tue, 22 Jan 2013 06:40:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.398 X-Spam-Level: X-Spam-Status: No, score=-102.398 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I54-QYAo8oSJ; Tue, 22 Jan 2013 06:40:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8334821F8613; Tue, 22 Jan 2013 06:39:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130122143937.17324.59444.idtracker@ietfa.amsl.com> Date: Tue, 22 Jan 2013 06:39:37 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-richardson-roll-applicability-template-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 14:40:10 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : ROLL Applicability Statement Template Author(s) : Michael C. Richardson Filename : draft-richardson-roll-applicability-template-01.txt Pages : 15 Date : 2013-01-22 Abstract: This document is a template applicability statement for the Routing over Low-power and Lossy Networks (ROLL) WG. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-richardson-roll-applicability-templa= te There's also a htmlized version available at: http://tools.ietf.org/html/draft-richardson-roll-applicability-template-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-richardson-roll-applicability-temp= late-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mcr@sandelman.ca Tue Jan 22 06:44:56 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769FE21F86D8 for ; Tue, 22 Jan 2013 06:44:56 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lalIpmDowiBX for ; Tue, 22 Jan 2013 06:44:56 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id E48A721F86C9 for ; Tue, 22 Jan 2013 06:44:55 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id C47B620168 for ; Tue, 22 Jan 2013 09:49:59 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 177D563765; Tue, 22 Jan 2013 09:44:02 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 0C18F636C4 for ; Tue, 22 Jan 2013 09:44:02 -0500 (EST) From: Michael Richardson To: roll@ietf.org X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 14:44:56 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable The security-threats documents makes reference to "sleepy node", and we do not have a definition of it in terminology-09.txt. Does someone have a good definition for such a thing? =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUP6lsYqHRg3pndX9AQJs6gQAiVWiu8JEDCgrSJEh79DAc/5qxzVO8k5W ET10T7mfvv5fNUzr/7yXQrGzVgAvrafW5MN51RBw2YTiPFbhNPNdeP5Pdf1WMIii 59hluBjWut3bR+lXD7pa/pYDdT/jZIcaNfLZpgiJVzTLDiZiJ0Tk4rY5Axy+EMfV lBp0C4rkizI= =EJK6 -----END PGP SIGNATURE----- --=-=-=-- From Matthew.Gillmore@itron.com Tue Jan 22 08:16:31 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A76D21F8AD6 for ; Tue, 22 Jan 2013 08:16:31 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OT2g+5l3sfu for ; Tue, 22 Jan 2013 08:16:30 -0800 (PST) Received: from mail.itron.com (mail.itron.com [198.182.8.116]) by ietfa.amsl.com (Postfix) with ESMTP id 9936721F8AD1 for ; Tue, 22 Jan 2013 08:16:30 -0800 (PST) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.110]) by spo-exchcn-2.itron.com ([192.168.9.116]) with mapi; Tue, 22 Jan 2013 08:16:26 -0800 From: "Gillmore, Matthew" To: Michael Richardson , "roll@ietf.org" Date: Tue, 22 Jan 2013 08:16:08 -0800 Thread-Topic: [Roll] definition of sleepy node Thread-Index: Ac34rxHa4wEuKUQoRTSRQvIhxoXtAAADF7WQ Message-ID: <626DFCA1C093F94D849B66B9E2F89A5F82AFC9A0@ITR-EXMBXVS-2.itron.com> References: <31718.1358865842@sandelman.ca> In-Reply-To: <31718.1358865842@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:16:31 -0000 Michael, How about this: "An energy constrained device that operates in a limited ca= pacity to conserve energy." I hesitate to explicitly state battery operated because the device may not = have a battery at all. Thanks -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mic= hael Richardson Sent: Tuesday, January 22, 2013 9:44 AM To: roll@ietf.org Subject: [Roll] definition of sleepy node The security-threats documents makes reference to "sleepy node", and we do = not have a definition of it in terminology-09.txt. Does someone have a goo= d definition for such a thing? -- Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ From abdussalambaryun@gmail.com Tue Jan 22 08:47:01 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DA4521F8A47 for ; Tue, 22 Jan 2013 08:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztOP91FoIOAc for ; Tue, 22 Jan 2013 08:47:00 -0800 (PST) Received: from mail-da0-f53.google.com (mail-da0-f53.google.com [209.85.210.53]) by ietfa.amsl.com (Postfix) with ESMTP id BB05D21F8A45 for ; Tue, 22 Jan 2013 08:47:00 -0800 (PST) Received: by mail-da0-f53.google.com with SMTP id x6so3311008dac.40 for ; Tue, 22 Jan 2013 08:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=pENoS6yUcr2eZq6R6sFCaDWmL6z9PCx+QcejMoAf/vI=; b=wbE7/DDpvLyNEwApPMeSBmZT2kAx0kh9khpGpSsxp0nYo4Frzf+xIsrT+eGi8AUQQN dOu2L+Vc5KTldGTkrswPsVtnBz46yqcnF/yL95f3JsHoN8GZBiYVpG4sxhPglZuZgYd5 ah574Fwbux/Qz2ctrc3aWOQrOjxhZehZPrf0T8rtQnIVUe8hFxIcM/sQKWWu+ybbHJdj LhqjAg7xhLBA7GGhcLxKWIzGqKLTSjinjnaJVCpkYmR34/3jSNGQobhDKV8fWVdiHeEn LMm920mf/zsIUkvOJIyQZNgXmEjqew82Pr0g0GfR3A2pJjBMs8l1Cl+iCtN46eVAqyie 3M0Q== MIME-Version: 1.0 X-Received: by 10.68.227.33 with SMTP id rx1mr41572548pbc.67.1358873220319; Tue, 22 Jan 2013 08:47:00 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 08:47:00 -0800 (PST) In-Reply-To: <31718.1358865842@sandelman.ca> References: <31718.1358865842@sandelman.ca> Date: Tue, 22 Jan 2013 17:47:00 +0100 Message-ID: From: Abdussalam Baryun To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 16:47:01 -0000 Hi Michael, Sleepy node: is a node that stops transmitting and receiving messages. This node still may partialy process or maintain needed information within the sleep mode. I still think that it is just a start definition may another thought to be better written, please advise, AB On 1/22/13, Michael Richardson wrote: > > The security-threats documents makes reference to "sleepy node", and > we do not have a definition of it in terminology-09.txt. Does someone > have a good definition for such a thing? > > > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > From mcr@sandelman.ca Tue Jan 22 09:22:45 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1575721F8A3D for ; Tue, 22 Jan 2013 09:22:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mciKMZQLeF8v for ; Tue, 22 Jan 2013 09:22:44 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 75D1421F8A06 for ; Tue, 22 Jan 2013 09:22:44 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id CF02420168 for ; Tue, 22 Jan 2013 12:27:42 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 8901063765; Tue, 22 Jan 2013 12:21:43 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 7C884636C4 for ; Tue, 22 Jan 2013 12:21:43 -0500 (EST) From: Michael Richardson to: roll@ietf.org In-Reply-To: <31718.1358865842@sandelman.ca> References: <31718.1358865842@sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 17:22:45 -0000 okay, how about: sleepy node: "An energy constrained device that has a sleep / wake cycle such that it is asleep more often than it is awake. It does this to conserve energy. A node can not transmit or receive messages while sleepy, but can maintain state. A sleepy node usually sleeps and wakes according to a set schedule. The sleep/wake cycle of an entire LLN usually needs to be coordinated so that transmitters are sending while receivers are awake the receive." From abdussalambaryun@gmail.com Tue Jan 22 10:18:53 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8813921F8749 for ; Tue, 22 Jan 2013 10:18:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R8npa9OYkRg5 for ; Tue, 22 Jan 2013 10:18:52 -0800 (PST) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id C6C3E21F8746 for ; Tue, 22 Jan 2013 10:18:52 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id mc8so4127634pbc.18 for ; Tue, 22 Jan 2013 10:18:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=uLT6WK4/ON6asCIj5nxO3rkYAgLT8wCZ3hASDYElVtg=; b=Ogvq+0tzvaiiveLrGUEeWlKqANPJVFXyw/V2qtTl2Ws17b+0h+SfaLOtdYrxAb+fDk nvCR9XW5T04a8jX/qtB9qalDUIoPGD5XPUBnWXYCSK0cFLFvFozcKcSlF1BG5vWTetFN rFuYGtA2PY/5eNvtXGyPPKK499f+3dGErsyHM3kwjBvnsSnX8ap4z6Mb2q5LpW1mDoIi cOnjPG+1yIgnRExDdfMDDyUA08Jl3WgtCzM36uAcYVribFfsXJMoBokLOMq1FKqr+mBu AqSNcDLIMNVJR47rZsOvabIwweRlNgc70i4vD02u8Xzk5IY8mHrwhRaEjFAwV9XfXI67 Qqtw== MIME-Version: 1.0 X-Received: by 10.68.136.132 with SMTP id qa4mr41265191pbb.166.1358878732511; Tue, 22 Jan 2013 10:18:52 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 10:18:52 -0800 (PST) In-Reply-To: <29902.1358875303@sandelman.ca> References: <31718.1358865842@sandelman.ca> <29902.1358875303@sandelman.ca> Date: Tue, 22 Jan 2013 19:18:52 +0100 Message-ID: From: Abdussalam Baryun To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 18:18:53 -0000 Hi Michael, Yes, I like the definition, thanks, AB On 1/22/13, Michael Richardson wrote: > > okay, how about: > > sleepy node: > > "An energy constrained device that has a sleep / wake cycle such that > it is asleep more often than it is awake. It does this to conserve > energy. A node can not transmit or receive messages while sleepy, but > can maintain state. A sleepy node usually sleeps and wakes according to > a set schedule. The sleep/wake cycle of an entire LLN usually needs to > be coordinated so that transmitters are sending while receivers are > awake the receive." > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From Matthew.Gillmore@itron.com Tue Jan 22 10:26:38 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3DEA21F874B for ; Tue, 22 Jan 2013 10:26:38 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdVsJkvFfZke for ; Tue, 22 Jan 2013 10:26:38 -0800 (PST) Received: from mail.itron.com (mail.itron.com [198.182.8.115]) by ietfa.amsl.com (Postfix) with ESMTP id 733F421F8749 for ; Tue, 22 Jan 2013 10:26:38 -0800 (PST) Received: from ITR-EXMBXVS-2.itron.com ([192.168.9.110]) by spo-exchcn-1.itron.com ([192.168.9.115]) with mapi; Tue, 22 Jan 2013 10:26:38 -0800 From: "Gillmore, Matthew" To: Michael Richardson , "roll@ietf.org" Date: Tue, 22 Jan 2013 10:26:13 -0800 Thread-Topic: [Roll] definition of sleepy node Thread-Index: Ac34xSI3TIjl6AATSySQYnNr80NxRQACKVeQ Message-ID: <626DFCA1C093F94D849B66B9E2F89A5F82AFCEAC@ITR-EXMBXVS-2.itron.com> References: <31718.1358865842@sandelman.ca> <29902.1358875303@sandelman.ca> In-Reply-To: <29902.1358875303@sandelman.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 18:26:39 -0000 Please consider a friendly amendment to the last sentence "A sleepy node usually sleeps and wakes according to a set schedule. The s= leep/wake cycle of an entire LLN usually needs to be coordinated so that tr= ansmitters are sending while receivers are awake to receive. "To" instead of "the" -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Mic= hael Richardson Sent: Tuesday, January 22, 2013 12:22 PM To: roll@ietf.org Subject: Re: [Roll] definition of sleepy node okay, how about: sleepy node: "An energy constrained device that has a sleep / wake cycle such that it is= asleep more often than it is awake. It does this to conserve energy. A node can not transmit or receive messages while sleepy, but can maintain state. A sleepy node usually sleeps and wakes according to a = set schedule. The sleep/wake cycle of an entire LLN usually needs to be co= ordinated so that transmitters are sending while receivers are awake the re= ceive." _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From Jerald.P.Martocci@jci.com Tue Jan 22 10:33:29 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C225521F8984; Tue, 22 Jan 2013 10:33:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.266 X-Spam-Level: X-Spam-Status: No, score=-3.266 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_IMAGE_ONLY_32=1.778, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57R4rJudXmBA; Tue, 22 Jan 2013 10:33:29 -0800 (PST) Received: from exprod8og112.obsmtp.com (exprod8og112.obsmtp.com [64.18.3.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7EA21F897A; Tue, 22 Jan 2013 10:33:28 -0800 (PST) Received: from smtpmke02.jci.com ([192.132.24.85]) (using SSLv3) by exprod8ob112.postini.com ([64.18.7.12]) with SMTP ID DSNKUP7bdfkXrLyWifmDTGuUHHiL6lL/r+h3@postini.com; Tue, 22 Jan 2013 10:33:28 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke02.jci.com (Lotus Domino Release 8.5.2FP3) with ESMTP id 2013012212330566-361381 ; Tue, 22 Jan 2013 12:33:05 -0600 In-Reply-To: References: <31718.1358865842@sandelman.ca> <29902.1358875303@sandelman.ca> To: Abdussalam Baryun MIME-Version: 1.0 X-KeepSent: DC76ED4D:B41DDA08-86257AFB:006565A4; 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: Tue, 22 Jan 2013 12:33:22 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 01/22/2013 12:33:22 PM, Serialize complete at 01/22/2013 12:33:22 PM, Itemize by SMTP Server on smtpmke02.jci.com/JCI_SMTP(Release 8.5.2FP3|July 10, 2011) at 01/22/2013 12:33:05 PM, Serialize by Router on smtpmke02.jci.com/JCI_SMTP(Release 8.5.2FP3|July 10, 2011) at 01/22/2013 12:33:11 PM, Serialize complete at 01/22/2013 12:33:11 PM Content-Type: multipart/related; boundary="=_related 0065EF9686257AFB_=" Cc: roll-bounces@ietf.org, roll@ietf.org, Michael Richardson Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 18:33:30 -0000 This is a multipart message in MIME format. --=_related 0065EF9686257AFB_= Content-Type: text/html; charset="US-ASCII"
Michael,

Some sleepy nodes are periodic, some aperiodic.  

For periodic nodes (e.g. a temperature sensor), although it awakens on a set schedule, it may not transmit and receive on a set schedule.  A temp sensor may awaken each minute to sense the ambient temperature.  If it hasn't changed since its last transmission, it may go back to sleep without transmitting or receiving.

Aperiodic devices (e.g. a light switch) may only access the network when the light switch is depressed.

Your definition implies to me that sleepy nodes will have a set accessibility time on the network.  This is not true.

Jerry





From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: Michael Richardson <mcr@sandelman.ca>
Cc: roll@ietf.org
Date: 01/22/2013 12:19 PM
Subject: Re: [Roll] definition of sleepy node




Hi Michael,

Yes, I like the definition, thanks,

AB

On 1/22/13, Michael Richardson <mcr@sandelman.ca> wrote:
>
> okay, how about:
>
> sleepy node:
>
> "An energy constrained device that has a sleep / wake cycle such that
> it is asleep more often than it is awake.  It does this to conserve
> energy.   A node can not transmit or receive messages while sleepy, but
> can maintain state.  A sleepy node usually sleeps and wakes according to
> a set schedule.  The sleep/wake cycle of an entire LLN usually needs to
> be coordinated so that transmitters are sending while receivers are
> awake the receive."
>
>
> _______________________________________________
> 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

--=_related 0065EF9686257AFB_= Content-Transfer-Encoding: base64 Content-Type: image/jpeg Content-ID: <_2_0A0D34000A0D31C00065EF9686257AFB> /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 0065EF9686257AFB_=-- From mcr@sandelman.ca Tue Jan 22 10:48:56 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EC6321F89C3 for ; Tue, 22 Jan 2013 10:48:56 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jPrFMzdq2XvJ for ; Tue, 22 Jan 2013 10:48:56 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 1B55221F8992 for ; Tue, 22 Jan 2013 10:48:56 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8838D20168 for ; Tue, 22 Jan 2013 13:53:59 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 4FA3363765; Tue, 22 Jan 2013 13:48:00 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 40734636C4 for ; Tue, 22 Jan 2013 13:48:00 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: References: <31718.1358865842@sandelman.ca> <29902.1358875303@sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 18:48:56 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable sleepy node: "An energy constrained device that has a sleep / wake cycle such that it is asleep more often than it is awake. It does this to conserve=20 energy. A node can not transmit or receive messages while sleepy, but can maintain state.=20=20 A sleepy node may sleep and wakes according to a set schedule, or it may wake as a result of external stimulous. The sleep/wake cycle of an entire LLN usually needs to be coordinated so that transmitters are sending while receivers are awake to receive." =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUP7e4IqHRg3pndX9AQJDuAQAzqwvTlTcBDIk0UbLR5/PaGci7SPAA5rW pmt4VLDZ5Roe7YDTAWoZRLhzBMZZMta5gYfUzx28pK3HITzvaLUNosPo+2XROsfD y1ZYafD/Dhn059A5qxonn66mVn5bCAWSua9lLuBvZU1Dk0lC2AVMeDh8uFOsWIpY EU2HoAJyKGY= =I7v5 -----END PGP SIGNATURE----- --=-=-=-- From abdussalambaryun@gmail.com Tue Jan 22 10:49:39 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A7F21F89C3; Tue, 22 Jan 2013 10:49:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCKAlKXSTFdp; Tue, 22 Jan 2013 10:49:39 -0800 (PST) Received: from mail-pb0-f44.google.com (mail-pb0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3767021F8992; Tue, 22 Jan 2013 10:49:39 -0800 (PST) Received: by mail-pb0-f44.google.com with SMTP id uo1so4137628pbc.31 for ; Tue, 22 Jan 2013 10:49:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=XD5FTt3WP69UKiC8IvWkRLQfIE5Ke6aSbsX0HdcpgzM=; b=WMQQ/7DrfDdMR/bjAWvszL/yt7Yke4hUoyrx13u8Xk+xa88KOQdGO+jvr1LqMnkna8 MdRWD92yhlUGQKpYElgULGoheYiCHTPWi26fbJByCW8vmystYsLw1238oQVeX57vosTS QmxxydZqpFP9tEtDT+5/u4wOI1u9id3VXTtfHB2nWYiRJJEIR7Lb9on/HvRJsgDs9CTe 3LRjq2b2NTCfqGtqjP1FWd5um3cYatLPxtSVrw+ylxbyZ4H8ZfsrvcDepqukOQjeqjRS dpawvmD17ikhoL1g89vmwUIvpXlDqlA6EYVYM2vRFuAIuLJp8XB5DKzSyv6OqB2A+wpF dvUg== MIME-Version: 1.0 X-Received: by 10.66.80.202 with SMTP id t10mr58460601pax.81.1358880578990; Tue, 22 Jan 2013 10:49:38 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 10:49:38 -0800 (PST) In-Reply-To: References: <31718.1358865842@sandelman.ca> <29902.1358875303@sandelman.ca> Date: Tue, 22 Jan 2013 19:49:38 +0100 Message-ID: From: Abdussalam Baryun To: Jerald.P.Martocci@jci.com Content-Type: text/plain; charset=ISO-8859-1 Cc: roll-bounces@ietf.org, roll@ietf.org, Michael Richardson Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 18:49:39 -0000 Hi Jerry, It says *usually* not always. However, could you suggest a modify text, or your opinion definition, AB On 1/22/13, Jerald.P.Martocci@jci.com wrote: > > Michael, > > Some sleepy nodes are periodic, some aperiodic. > > For periodic nodes (e.g. a temperature sensor), although it awakens on a set > schedule, it may not transmit and receive on a set schedule. A temp sensor > may awaken each minute to sense the ambient temperature. If it hasn't > changed since its last transmission, it may go back to sleep without > transmitting or receiving. > > Aperiodic devices (e.g. a light switch) may only access the network when the > light switch is depressed. > > Your definition implies to me that sleepy nodes will have a set > accessibility time on the network. This is not true. > > Jerry > > > [image] > > > From: > Abdussalam Baryun > To: > Michael Richardson > Cc: > roll@ietf.org > Date: > 01/22/2013 12:19 PM > Subject: > Re: [Roll] definition of sleepy node > > ________________________________ > > > > Hi Michael, > > Yes, I like the definition, thanks, > > AB > > On 1/22/13, Michael Richardson wrote: >> >> okay, how about: >> >> sleepy node: >> >> "An energy constrained device that has a sleep / wake cycle such that >> it is asleep more often than it is awake. It does this to conserve >> energy. A node can not transmit or receive messages while sleepy, but >> can maintain state. A sleepy node usually sleeps and wakes according to >> a set schedule. The sleep/wake cycle of an entire LLN usually needs to >> be coordinated so that transmitters are sending while receivers are >> awake the receive." >> >> >> _______________________________________________ >> 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 Ted.Humpal@jci.com Tue Jan 22 10:59:33 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8D821F8A45; Tue, 22 Jan 2013 10:59:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.044 X-Spam-Level: X-Spam-Status: No, score=-5.044 tagged_above=-999 required=5 tests=[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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJjqCgQUs-6a; Tue, 22 Jan 2013 10:59:32 -0800 (PST) Received: from exprod8og115.obsmtp.com (exprod8og115.obsmtp.com [64.18.3.30]) by ietfa.amsl.com (Postfix) with ESMTP id 423E221F8A43; Tue, 22 Jan 2013 10:59:32 -0800 (PST) Received: from smtpmke01.jci.com ([192.132.24.85]) (using SSLv3) by exprod8ob115.postini.com ([64.18.7.12]) with SMTP ID DSNKUP7higSXGcLK6HgCOuoM/CN77DNAEKDM@postini.com; Tue, 22 Jan 2013 10:59:32 PST Received: from jwimkrs1.na.jci.com ([10.10.6.31]) by smtpmke01.jci.com (Lotus Domino Release 8.5.2FP3) with ESMTP id 2013012212585781-365835 ; Tue, 22 Jan 2013 12:58:57 -0600 In-Reply-To: <14235.1358880480@sandelman.ca> References: <31718.1358865842@sandelman.ca> <29902.1358875303@sandelman.ca> <14235.1358880480@sandelman.ca> To: Michael Richardson MIME-Version: 1.0 X-KeepSent: FFFA913A:2E4D33F1-86257AFB:0067852F; type=4; flags=0; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 FP4 December 11, 2009 From: Ted.Humpal@jci.com Message-ID: Date: Tue, 22 Jan 2013 12:59:14 -0600 X-MIMETrack: Serialize by Router on jwimkrs1.na.jci.com/NA/Johnson_Controls at 01/22/2013 12:59:15 PM, Serialize complete at 01/22/2013 12:59:15 PM, Itemize by SMTP Server on smtpmke01.jci.com/JCI_SMTP(Release 8.5.2FP3|July 10, 2011) at 01/22/2013 12:58:57 PM, Serialize by Router on smtpmke01.jci.com/JCI_SMTP(Release 8.5.2FP3|July 10, 2011) at 01/22/2013 12:59:15 PM Content-Type: text/html; charset="US-ASCII" Cc: roll@ietf.org, roll-bounces@ietf.org Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 18:59:33 -0000
You wrote:

The sleep/wake cycle of an
entire LLN usually needs to be coordinated so that transmitters are
sending while receivers are awake to receive.

This may be proper for an entire sleepy LLN, that sleeps and wakes together, but
their is also the case where individual nodes sleep and the LLN stays active.  In this case,
 aperiodic sensors ( temperature and others)  may transmit and receive at different times / relative to each other, would it
not be better in this case to state  that each 'parent' synchronize transmitters to their respective sleeping children, for this type of network?

 We are discussing two different type of sleepy architectures that behave differently with respect to their waking characteristics.

Consider for sleepy nodes (not applicable for sleepy LLNs)

The sleep/wake cycle of
each parent usually needs to be coordinated their children, so that the parents
transmitters are sending while receivers are awake to receive.

Ted


From: Michael Richardson <mcr+ietf@sandelman.ca>
To: roll@ietf.org
Date: 01/22/2013 12:48 PM
Subject: Re: [Roll] definition of sleepy node





sleepy node:

"An energy constrained device that has a sleep / wake cycle such that it
is asleep more often than it is awake.  It does this to conserve
energy.   A node can not transmit or receive messages while sleepy, but
can maintain state.  

A sleepy node may sleep and wakes according to a set schedule, or it may
wake as a result of external stimulous.  The sleep/wake cycle of an
entire LLN usually needs to be coordinated so that transmitters are
sending while receivers are awake to receive."





--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
IETF ROLL WG co-chair.    http://datatracker.ietf.org/wg/roll/charter/

[attachment "att3aq77.dat" deleted by Ted Humpal/CORP/Johnson_Controls] _______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll

From salo@saloits.com Tue Jan 22 11:06:40 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E6821F8A90 for ; Tue, 22 Jan 2013 11:06:40 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PZfrRr1eM7iO for ; Tue, 22 Jan 2013 11:06:39 -0800 (PST) Received: from server.saloits.com (saloits.com [208.42.140.127]) by ietfa.amsl.com (Postfix) with ESMTP id 97D9421F8A6F for ; Tue, 22 Jan 2013 11:06:32 -0800 (PST) Received: from [192.168.1.145] (c-174-53-189-20.hsd1.mn.comcast.net [174.53.189.20]) by server.saloits.com (8.14.4/8.14.3) with ESMTP id r0MJ6UFt012256; Tue, 22 Jan 2013 13:06:31 -0600 Message-ID: <50FEE333.5080706@saloits.com> Date: Tue, 22 Jan 2013 13:06:27 -0600 From: "Timothy J. Salo" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: roll@ietf.org References: <31718.1358865842@sandelman.ca> <29902.1358875303@sandelman.ca> In-Reply-To: <29902.1358875303@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 19:06:40 -0000 I suggest that the definition of a sleepy node not include prescriptions about how networks ought to be designed to accommodate nodes that sleep. I also suggest that the definition encompass the broadest range of nodes that sleep. Here is my attempt. It's still not right, but perhaps some of the language might be of use. A "sleepy node" is a device that episodically [from time-to-time] puts itself in a low-power, quiescent state, or "sleeps". While sleeping, these devices cannot perform major functions, such as transmitting packets, receiving packets or performing computations. Often, these devices wake on the expiration of a timer, although some devices are capable of waking in response to an external event. A sleep state differs from a power-down state in that most device state is preserved; therefore, the transition from a sleep state to an operating state requires much less time than does booting from a powered-down state. Generally, these devices sleep to conserve energy. For example, battery-powered devices may sleep in order to extend their lifetimes. - - - - > "An energy constrained device that has a sleep / wake cycle such that > it is asleep more often than it is awake. A node that sleeps only 49% of the time ought to be considered a sleep node, (in my view). It presents the same problems to the design of network protocols. > A node can not transmit or receive messages while sleepy, but > can maintain state. The issue of preserving state gets complicated: the amount of state that is preserved varies between devices, and some devices have several sleep states that preserve different amounts of state. And, it is possible to preserve state across reboots. I tried to cast state preservation in terms supporting "waking", which is much less dramatic than booting. But, a protocol ought not care whether a device wakes or boots. (Actually, there are a whole range of energy-saving strategies. Even what I wrote probably conflicts with some strategies, such as shutting down major subsystems, but keeping a processor awake; keeping only a small processor alive, put putting the main processor to sleep; or reducing the processor clock rate, but keeping the processor alive.) (I believe that some devices can wake on the receipt of a packet. But, this probably isn't of much use with the typical LAN/PAN chips, where receiving is expensive, and often requires almost as much power as transmitting!) > A sleepy node usually sleeps and wakes according to > a set schedule. Devices may also wake in response to external events. I hope that ROLL can accommodate these devices... > The sleep/wake cycle of an entire LLN usually needs to > be coordinated so that transmitters are sending while receivers are > awake the receive." This sounds overly prescriptive to me. In some systems, some nodes may not be energy constrained, and so are capable of listening continuously. These non-sleeping nodes may respond to sleeping nodes that wake asynchronously. Actually, I think these sorts of systems are pretty common. It is not clear to me that this less-synchronous behavior is included in: "The sleep/wake cycle of an entire LLN usually needs to be coordinated". I don't think that a protocol should require that all devices in a network have the same sleep cycle. For example, some nodes ought to be permitted to sleep for a long time, while other nodes may wake more often. Plus, the clocks in many of these devices are so crummy that a node that sleeps for a long time is no longer synchronized with the rest of the network. Sleeping, and how sleep cycles are or aren't coordinated have implications about whether broadcast or multicast have any meaning... But mostly, I suggest that a prescription about how a network protocol ought to handle sleeping nodes not be included in the definition of a sleepy node. Again, I hope this helps, -tjs From sistopefuni@gmail.com Tue Jan 22 11:19:29 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 736E321F8A79 for ; Tue, 22 Jan 2013 11:19:29 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kb0mQlgijw7m for ; Tue, 22 Jan 2013 11:19:28 -0800 (PST) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) by ietfa.amsl.com (Postfix) with ESMTP id 734AC21F8A50 for ; Tue, 22 Jan 2013 11:19:28 -0800 (PST) Received: by mail-ob0-f177.google.com with SMTP id wc20so6764683obb.36 for ; Tue, 22 Jan 2013 11:19:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=xa7DrrG7Sg0TVdOaftiGi4eOR9KWJQu+bS/ez6Z/WUo=; b=xfRnjPRKvzdAm+cWLw/FbbhV+Ikcx0R4Q2mBucXAsONmDhZbWOpv4EwIkdPXwwIldM cs5NAZT5zn2ibZb57E6ZqY6yxs77Pw8twyhHrPfjM6593eNleUv7Rpg3YzR99NrLJvYN zXASAur0aXryLCP5dlg1FIXZr6udbr4CyMowQCIuimq9sQdvEq9AibxLtcTMYZpqiolt AccEa/iWHCt4de/xB+9QoU7HJwkj76Y/4RPk2jGwUvfux7+mpPVIS6GQj0MF1boVeg7C gqd4e597cENEQVUjBckRuBAK3mP2VxqwfiGgLHcYAaaNdjd7mhE2e5/C6JY1p5LEqT78 VBXQ== MIME-Version: 1.0 X-Received: by 10.182.78.168 with SMTP id c8mr1118276obx.30.1358882367929; Tue, 22 Jan 2013 11:19:27 -0800 (PST) Received: by 10.182.192.101 with HTTP; Tue, 22 Jan 2013 11:19:27 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Jan 2013 16:19:27 -0300 Message-ID: From: Sistemas Operativos To: roll@ietf.org Content-Type: multipart/alternative; boundary=f46d0444ef2fd4fef304d3e57466 Subject: [Roll] Fwd: definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 19:20:38 -0000 --f46d0444ef2fd4fef304d3e57466 Content-Type: text/plain; charset=ISO-8859-1 Hello, I like the definition with "To" proposed, just adding some comment, in core was defined. what is a sleepy node and what is not a sleepy node, just thinking that both terms could be added in the terminology -09 draft. Just thinking for this case: Non-Sleepy Node: A device that is always awake, it usually is available to transmit and receive anytime. " http://tools.ietf.org/html/draft-rahman-core-sleepy-01 Sleepy Node A sleepy node is a CoAP client or server that may sometimes go into a sleep mode (i.e. go into a low power state to conserve power) and temporarily suspend CoAP protocol communication. A sleepy node may also sometimes remain in a fully powered on state where it has the capability to perform full CoAP protocol communication. Non-Sleepy Node A non-sleepy node is a CoAP client or server that always remains in a fully powered on state (i.e. always awake) where it has the capability to perform full CoAP protocol communication. The general operation of non-sleepy nodes are assumed to be well known and so are not explicitly spelled out in this document except where needed for clarity. " Thanks and Regards, irobles. ------------------------------ Message: 6 Date: Tue, 22 Jan 2013 19:18:52 +0100 From: Abdussalam Baryun To: Michael Richardson Cc: roll@ietf.org Subject: Re: [Roll] definition of sleepy node Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, Yes, I like the definition, thanks, AB On 1/22/13, Michael Richardson wrote: > > okay, how about: > > sleepy node: > > "An energy constrained device that has a sleep / wake cycle such that > it is asleep more often than it is awake. It does this to conserve > energy. A node can not transmit or receive messages while sleepy, but > can maintain state. A sleepy node usually sleeps and wakes according to > a set schedule. The sleep/wake cycle of an entire LLN usually needs to > be coordinated so that transmitters are sending while receivers are > awake the receive." > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --f46d0444ef2fd4fef304d3e57466 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

=
Hello,

I like the definition with "To" proposed, just adding some commen= t, in core was defined. what is a sleepy node and what is not a sleepy node= , just thinking that both terms could be added in the terminology -09 draft= .

Just thinki= ng for this case:

<=
span style=3D"font-family:arial;font-size:small;white-space:normal">Non-Sle=
epy Node:=A0A device that is always awake, it usually is available to tran=
smit and receive anytime.


"
h= ttp://tools.ietf.org/html/draft-rahman-core-sleepy-01

 Sleepy Node
      A sleepy node is a CoAP client or server that may sometimes go
      into a sleep mode (i.e. go into a low power state to conserve
      power) and temporarily suspend CoAP protocol communication.  A
      sleepy node may also sometimes remain in a fully powered on state
      where it has the capability to perform full CoAP protocol
      communication.

   Non-Sleepy Node
      A non-sleepy node is a CoAP client or server that always remains
      in a fully powered on state (i.e. always awake) where it has the
      capability to perform full CoAP protocol communication.  The
      general operation of non-sleepy nodes are assumed to be well known
      and so are not explicitly spelled out in this document except
      where needed for clarity.

<= /div>
"

Thanks and Regards,

irobles.

------------------------------

Message: 6
Date: Tue, 22 Jan 2013 19:18:52 +0100
From: Abdussalam Baryun <abdussalambaryun@gmail.com>
To: Michael Richardson <mcr@sandelman.ca>
Cc: roll@ietf.org Subject: Re: [Roll] definition of sleepy node
Message-ID:
=A0 =A0 =A0 =A0 <CADnDZ88F=3D=3DY3A_OXFOnKrtp=3DzXg68Q3uch1Yq6upRftW= aWnCGQ@mail.gmail.com>
Content-Type: text/plain; charset=3DISO-8859-1

Hi Michael,

Yes, I like the definition, thanks,

AB

On 1/22/13, Michael Richardson <mcr@sandelman.ca> wrote:
>
> okay, how about:
>
> sleepy node:
>
> "An energy constrained device that has a sleep / wake cycle such = that
> it is asleep more often than it is awake. =A0It does this to conserve<= br> > energy. =A0 A node can not transmit or receive messages while sleepy, = but
> can maintain state. =A0A sleepy node usually sleeps and wakes accordin= g to
> a set schedule. =A0The sleep/wake cycle of an entire LLN usually needs= to
> be coordinated so that transmitters are sending while receivers are > awake the receive."
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll
>




--f46d0444ef2fd4fef304d3e57466-- From alessandro.bogliolo@uniurb.it Tue Jan 22 11:26:18 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B654121F8A8E for ; Tue, 22 Jan 2013 11:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+LZRBp5dUDB for ; Tue, 22 Jan 2013 11:26:18 -0800 (PST) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3161021F84F2 for ; Tue, 22 Jan 2013 11:26:17 -0800 (PST) Received: by mail-ob0-f173.google.com with SMTP id dn14so270048obc.4 for ; Tue, 22 Jan 2013 11:26:17 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=goJnUWtAsqX+JMi7cvEMjYxp7/CEvKSb4uKisHqRBRc=; b=jcFv5bQlyv8DUfalb8xu4KJPKmW7ggSZ8zT3ySsBDehng+qevdnqdYM3TvNEceSQNc FuXXMWiBB+Gvxv+yMs03TEpIcBcvhpP3ESvmf3RGcADXlVKsIUjU7rQhU+djOIXaWmTb RqOLHaJbVf62jVi9c45t/Lv2p35BMMk1mcuQtHAC2cz1iNdKp7X/p+4JSTN3NMHyz8Jt Z/biFj8g0H6s8COubI5st1qHbAnv3zABmp4ag+JsxkKWWl8rMVPkr6nYlxAdVFiZhKiv SEIm8fWRBqcxRRTu64NIMcwGsRNgQ4HEpfBrbxd68Anyi2qPVjh/P3DJNV7GLHSIKnCC 9bUg== MIME-Version: 1.0 X-Received: by 10.60.3.167 with SMTP id d7mr17496184oed.85.1358882777320; Tue, 22 Jan 2013 11:26:17 -0800 (PST) Received: by 10.76.80.165 with HTTP; Tue, 22 Jan 2013 11:26:17 -0800 (PST) In-Reply-To: <50FEE333.5080706@saloits.com> References: <31718.1358865842@sandelman.ca> <29902.1358875303@sandelman.ca> <50FEE333.5080706@saloits.com> Date: Tue, 22 Jan 2013 20:26:17 +0100 Message-ID: From: "Bogliolo, Alessandro" To: "Timothy J. Salo" Content-Type: multipart/alternative; boundary=e89a8ff1ce423bcc0104d3e58d6a X-Gm-Message-State: ALoCoQnaT3oCNuGGQDOsTyt4h4OpGSgawGPeZowtNvevqb2i71ftRCZnMDCQj58o4/DHcx54tl39 Cc: roll@ietf.org Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 19:26:18 -0000 --e89a8ff1ce423bcc0104d3e58d6a Content-Type: text/plain; charset=ISO-8859-1 2013/1/22 Timothy J. Salo > I suggest that the definition of a sleepy node not include prescriptions > about how networks ought to be designed to accommodate nodes that > sleep. I also suggest that the definition encompass the broadest range > of nodes that sleep. > I fully agree. Also, based on a background on wireless sensor networks and dynamic power management, I would suggest to see as a distinguishing feature of a sleepy node the availability of a low-power inactive state that can be entered to save energy while maintaining state information and some reactivity to timeouts (self wake ups) and external events. A. --e89a8ff1ce423bcc0104d3e58d6a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2013/1/22 Timothy J. Salo <salo@saloits.com>
<= div class=3D"gmail_quote">
I suggest that the definition of a sleepy node not include prescriptions about how networks ought to be designed to accommodate nodes that
sleep. =A0I also suggest that the definition encompass the broadest range of nodes that sleep.

I fully agree.

Also, based on a background on wireless sensor networ= ks and dynamic power management,
I would suggest to see as a dist= inguishing feature of a sleepy node the availability of a low-power
inactive state that can be entered to save energy while maintaining st= ate information and
some reactivity to timeouts (self wake ups) a= nd external events.

A.
--e89a8ff1ce423bcc0104d3e58d6a-- From mcr@sandelman.ca Tue Jan 22 12:54:13 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE27D21F8A7B for ; Tue, 22 Jan 2013 12:54:13 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nLfVYIWC5itK for ; Tue, 22 Jan 2013 12:54:13 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA7321F8A51 for ; Tue, 22 Jan 2013 12:54:13 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id A6B2320168 for ; Tue, 22 Jan 2013 15:59:18 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id E55C063765; Tue, 22 Jan 2013 15:53:19 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id D526E636C4 for ; Tue, 22 Jan 2013 15:53:19 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <50FEE333.5080706@saloits.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 20:54:14 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Please be aware that the definition of sleepy node need not be=20 pendantically precise. The purpose of the glossary of terms is mostly so that when discussing LLNs with non-LLN network specialists that we give them an idea what this could mean, not that we find do LLN taxonomy. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUP78P4qHRg3pndX9AQJAOgP/QZTTI4cM5HXEWnfV0gdpl28r6LYIPwMq LrVwZte8qUce7t6ZB91drnI1TS0ysRic9zciGjKm0Nn7EGj3LvTPsZGZU8d/MoEr PdEwBD1Fuu31FeeeNJn8OCZQEWZlXxWFAoE7vQvKdHOE751ISJqKJ9eR49USp7KW VGhTnqbd9X8= =etUw -----END PGP SIGNATURE----- --=-=-=-- From mariainesrobles@googlemail.com Tue Jan 22 10:56:29 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F97C21F8A3D for ; Tue, 22 Jan 2013 10:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KcUtRD0DYhh for ; Tue, 22 Jan 2013 10:56:28 -0800 (PST) Received: from mail-vc0-f180.google.com (mail-vc0-f180.google.com [209.85.220.180]) by ietfa.amsl.com (Postfix) with ESMTP id 4A82821F899F for ; Tue, 22 Jan 2013 10:56:28 -0800 (PST) Received: by mail-vc0-f180.google.com with SMTP id fo13so2141118vcb.25 for ; Tue, 22 Jan 2013 10:56:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=TFYj/u8WuCjL2NU+QErR9K5U9YauOndIADRwRy4vE3Y=; b=P0InX7F0q8pekFCzrs4HIBFUDWBkZ5hJvISQ7UaeJLGea4Zv8EZRJmdmSU5q/sQKb9 iYTHooe0P9svqLswHCqSt8JSzIZsDhkPqdG016xUn8A0WnM6dv8YwJ/Y41MfglpZgov+ IFm74KAN5oWznhjj55Q9i+IGbBckZGaycFqL2WemZESdMJzq5kTbhnlmQy9Mn/f5xqHv dYxhUWe5cFPhky5wmrj0FWsWehPp+COFWbkyN2sqhNesAEpv63Uy4A2HkGe+nCtLxczD 4RhJsfua4SIa1bBkdwWY4dgTq4rvVJmuvpZ5veesMEbZMDu6DVnKgVd8ZfLlSafi7ODR VnKA== MIME-Version: 1.0 X-Received: by 10.220.219.73 with SMTP id ht9mr15233843vcb.47.1358880987659; Tue, 22 Jan 2013 10:56:27 -0800 (PST) Received: by 10.58.187.14 with HTTP; Tue, 22 Jan 2013 10:56:27 -0800 (PST) Date: Tue, 22 Jan 2013 15:56:27 -0300 Message-ID: From: Ines Robles To: roll@ietf.org Content-Type: multipart/alternative; boundary=14dae9cfceb48fbc1f04d3e522c9 X-Mailman-Approved-At: Tue, 22 Jan 2013 12:54:29 -0800 Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 18:56:29 -0000 --14dae9cfceb48fbc1f04d3e522c9 Content-Type: text/plain; charset=ISO-8859-1 Hello, I like the definition with "To" proposed, just adding some comment, in core was defined. what is a sleepy node and what is not a sleepy node. " Sleepy Node A sleepy node is a CoAP client or server that may sometimes go into a sleep mode (i.e. go into a low power state to conserve power) and temporarily suspend CoAP protocol communication. A sleepy node may also sometimes remain in a fully powered on state where it has the capability to perform full CoAP protocol communication. Non-Sleepy Node A non-sleepy node is a CoAP client or server that always remains in a fully powered on state (i.e. always awake) where it has the capability to perform full CoAP protocol communication. The general operation of non-sleepy nodes are assumed to be well known and so are not explicitly spelled out in this document except where needed for clarity. http://tools.ietf.org/html/draft-rahman-core-sleepy-01 " Thanks and Regards, IRobles. ------------------------------ Message: 6 Date: Tue, 22 Jan 2013 19:18:52 +0100 From: Abdussalam Baryun To: Michael Richardson Cc: roll@ietf.org Subject: Re: [Roll] definition of sleepy node Message-ID: Content-Type: text/plain; charset=ISO-8859-1 Hi Michael, Yes, I like the definition, thanks, AB On 1/22/13, Michael Richardson wrote: > > okay, how about: > > sleepy node: > > "An energy constrained device that has a sleep / wake cycle such that > it is asleep more often than it is awake. It does this to conserve > energy. A node can not transmit or receive messages while sleepy, but > can maintain state. A sleepy node usually sleeps and wakes according to > a set schedule. The sleep/wake cycle of an entire LLN usually needs to > be coordinated so that transmitters are sending while receivers are > awake the receive." > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --14dae9cfceb48fbc1f04d3e522c9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello,

I like the definition with "To" propo= sed, just adding some comment, in core was defined. what is a sleepy node a= nd what is not a sleepy node.=A0

"
 Sleepy Node
      A sleepy node is a CoAP client or server that may sometimes go
      into a sleep mode (i.e. go into a low power state to conserve
      power) and temporarily suspend CoAP protocol communication.  A
      sleepy node may also sometimes remain in a fully powered on state
      where it has the capability to perform full CoAP protocol
      communication.

   Non-Sleepy Node
      A non-sleepy node is a CoAP client or server that always remains
      in a fully powered on state (i.e. always awake) where it has the
      capability to perform full CoAP protocol communication.  The
      general operation of non-sleepy nodes are assumed to be well known
      and so are not explicitly spelled out in this document except
      where needed for clarity.

<= /div>
http://tools.ietf.org/html/draft-rahman-core-sleepy= -01
"

Thanks and Regards,

IRobles.

------------------------------

Message: 6
Date: Tue, 22 Jan 2013 19:18:52 +0100
From: Abdussalam Baryun <a= bdussalambaryun@gmail.com>
To: Michael Richardson <mcr@sandelma= n.ca>
Cc: roll@ietf.org
Subject: Re: [Roll] definition of sleepy node
Message-ID:
=A0 =A0 =A0 =A0 <CADnDZ88F=3D=3DY3A_OXFOnKrtp=3DzXg68Q3uch1Yq6upRftWaWnCGQ@mail.gmail.= com>
Content-Type: text/plain; charset=3DISO-8859-1

Hi Michael,

Yes, I like the definition, thanks,

AB

On 1/22/13, Michael Richardson <mcr@= sandelman.ca> wrote:
>
> okay, how about:
>
> sleepy node:
>
> "An energy constrained device that has a sleep / wake cycle such = that
> it is asleep more often than it is awake. =A0It does this to conserve<= br> > energy. =A0 A node can not transmit or receive messages while sleepy, = but
> can maintain state. =A0A sleepy node usually sleeps and wakes accordin= g to
> a set schedule. =A0The sleep/wake cycle of an entire LLN usually needs= to
> be coordinated so that transmitters are sending while receivers are > awake the receive."
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>


--14dae9cfceb48fbc1f04d3e522c9-- From mcr@sandelman.ca Tue Jan 22 13:18:41 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77A1F21F8960 for ; Tue, 22 Jan 2013 13:18:41 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Djv9YAhkKbhw for ; Tue, 22 Jan 2013 13:18:41 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id DB04021F8958 for ; Tue, 22 Jan 2013 13:18:40 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 640DA20168 for ; Tue, 22 Jan 2013 16:23:45 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 94D3263765; Tue, 22 Jan 2013 16:17:46 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 8010F63761 for ; Tue, 22 Jan 2013 16:17:46 -0500 (EST) From: Michael Richardson To: roll@ietf.org X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: [Roll] summary of tickets on trickle-mcast X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 21:18:41 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable http://trac.tools.ietf.org/wg/roll/trac/report/8 contains the list of open tickets. There are some threads linked in each ticket. http://trac.tools.ietf.org/wg/roll/trac/ticket/103 trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS http://www.ietf.org/mail-archive/web/roll/current/msg07424.html This ticket has had no significant discussion. Is there an issue here? http://trac.tools.ietf.org/wg/roll/trac/ticket/104 security considerations. We need to have a discussion about what are the implications=20 of this protocol. See next message. http://trac.tools.ietf.org/wg/roll/trac/ticket/105 trickle-mcast: how to determine scope of MPL domain We have several options from Robert Craigie in the ticket system. Alternatives 3 and 4 were discussed, and I think that we preferred option 4 with the multicast option always present. Please post if you disagree. http://trac.tools.ietf.org/wg/roll/trac/ticket/106 trickle-mcast: always use 6in6 encapsulation for non-link-local multicast no clear resolution, but ticket #105 suggests answer. http://trac.tools.ietf.org/wg/roll/trac/ticket/108 trickle-mcast: should there be an explicit version field? suggested answer was YES. http://trac.tools.ietf.org/wg/roll/trac/ticket/107 trickle-mcast: should multiple parameter sets be supported my conclusion: There is has been little discussion about this issue. My inclination is to not include multiple sets at this time.=20 http://trac.tools.ietf.org/wg/roll/trac/ticket/109 trickle-mcast: should all MPL packets be destined to all-MPL-forwarders =20=20 =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUP8B+oqHRg3pndX9AQICnAQAvZOaGuqQnN5Odix2T5n40pKRNoX3zLJN uom9Np7yV25AJ03C3bEUzYadpST4vnUSItAd+AZ4h96YF6UQuPMTPEFZR8w0abS+ ne8boq4h3gaodyAPrrpo0d6Lrz3Vvk9/E/n4Btyf/dJ0YlnnRiZFWEZqKvXWIkVD ZohyRKSn2TM= =pQix -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Tue Jan 22 13:21:13 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53A7421F8992 for ; Tue, 22 Jan 2013 13:21:13 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLY0STvL+4aC for ; Tue, 22 Jan 2013 13:21:12 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD5121F8960 for ; Tue, 22 Jan 2013 13:21:12 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 82F3420168 for ; Tue, 22 Jan 2013 16:26:17 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 4D11063765; Tue, 22 Jan 2013 16:20:18 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 38BEB63761 for ; Tue, 22 Jan 2013 16:20:18 -0500 (EST) From: Michael Richardson to: roll@ietf.org In-Reply-To: <11173.1358889466@sandelman.ca> References: <11173.1358889466@sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] summary of tickets on trickle-mcast X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2013 21:21:13 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable missed one.=20 I think that the question is out of scope. http://trac.tools.ietf.org/wg/roll/trac/ticket/110 trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones=20 There's still the case that multicasts from non-MPL nodes are received by MPL-forwarder-nodes (presumably). Should there be guidelines here? Example: if an application on my MPL-forwarder node joins multicast group FF05::1234, will the application then receive IP multicasts sent with destination FF05::1234, or will it only receive those IP multicasts to FF05::1234 that were delivered encapsulated in an FF0X::MPL packet ? That decision could be out of scope; but on the other hand may lead to different implementers making different choices here.=20 =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUP8CkoqHRg3pndX9AQJvDgP8CN9VyPHQ6mV7NNj0y6ed1f61ThrpncCK mZ68yBjXmbKHcRJMTInXsVAvFO1wWuycpjIhV51LbDeNfabLFHu/CNjZyJX/fsKn lV6Y0Zijn2s55ICBgv7MTNqCjT5+VlmC/QTT3raoYgvSu4lmNutaUpWFVElv9132 CgCwUoUn/Ac= =nvtq -----END PGP SIGNATURE----- --=-=-=-- From abdussalambaryun@gmail.com Tue Jan 22 16:31:05 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B79F721F8542 for ; Tue, 22 Jan 2013 16:31:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id obXr2behr9hX for ; Tue, 22 Jan 2013 16:31:05 -0800 (PST) Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) by ietfa.amsl.com (Postfix) with ESMTP id 49F2A21F8501 for ; Tue, 22 Jan 2013 16:31:05 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id hz10so4395031pad.9 for ; Tue, 22 Jan 2013 16:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=V0ddQMje5w6Ijp2AI2MiSHYzaX/aLZvxNP8X9PD/of8=; b=gsV2muCr5p1WNTC22en4/ooEZmZ2pkzkF036cZFJ2Fn0Fcm+80BGGh/W+PI1YB3zOu JqbZHwLfAh8N2Y6f0jFX8SNK9zMOgFeX3CuWDsPZM/fb4sa9zFjvOQkyEnRJQghqBfy+ k+NkcdyD8XsbJTGUok5QI+mfyNc2Ev9dzfJAyk4BVKjtqofX/L2au5fgOW1Jap+BnkyK Gcx8JjQAa/hYedaxw7I+93D9n43uLJYBeOthOGUH5qC9MhHJ88+9P0acTmLSaVIbIrTG RYbWEeUdpicHD+ycOKmwwtyanWhMKp7/ryJNP2+PwMbpW8BwW7MV+ZyVvF1DQicWIlak d65A== MIME-Version: 1.0 X-Received: by 10.68.234.167 with SMTP id uf7mr44123747pbc.20.1358901065070; Tue, 22 Jan 2013 16:31:05 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 16:31:04 -0800 (PST) In-Reply-To: <50FEE333.5080706@saloits.com> References: <31718.1358865842@sandelman.ca> <29902.1358875303@sandelman.ca> <50FEE333.5080706@saloits.com> Date: Wed, 23 Jan 2013 01:31:04 +0100 Message-ID: From: Abdussalam Baryun To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 00:31:05 -0000 On 1/22/13, Timothy J. Salo wrote: > I suggest that the definition of a sleepy node not include prescriptions > about how networks ought to be designed to accommodate nodes that > sleep. I also suggest that the definition encompass the broadest range > of nodes that sleep. I agree that we make it simple not confusing, define sleeping node NOT sleeping network. Or we can separate definitions Sleepy Node, and Sleepy LLN, and if Sleepy LLN is long then make another separation, I need to sleep, good night :) AB From abdussalambaryun@gmail.com Tue Jan 22 16:36:30 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CC6721F86CC for ; Tue, 22 Jan 2013 16:36:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yyjn3Wv3BMLI for ; Tue, 22 Jan 2013 16:36:29 -0800 (PST) Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id C9DB521F8684 for ; Tue, 22 Jan 2013 16:36:29 -0800 (PST) Received: by mail-da0-f50.google.com with SMTP id h15so3504492dan.9 for ; Tue, 22 Jan 2013 16:36:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=exYbbDSxn2FbBApw72AUWI89Ds1Enb+qXko6C5x85jo=; b=nWXFukAYa+2AhG4fVbuq1Gp4ZbAqK7kja5IV/CfP1B0XBz/Db0wLkv/kv2jqDZbhKN 1X334zil+pYB0fmEeKgIWsJ6xRPTW/J2rTmkYCqUJnUw1hRLx2wlo0AYsuV7kxqsdq04 mVbOToawDrq2AHDYakMEkwgExUoTzHVosW6OssoEzkjPngFwmWIjFZCFiHqovnALdtmR 1Z78A9OsDP/cIRq2b3HelTsbR4vCZY8locJS80eUVyKQ1jyl70jmpe6Co22xZE/qaNNz PklRwhXOWqwcojIo9EPwswZurYiGIZR+Ikf8wxYGi2SbKj/b9/Pzilt7cEnpt1Csjjtk 1RFA== MIME-Version: 1.0 X-Received: by 10.66.80.202 with SMTP id t10mr60755927pax.81.1358901389573; Tue, 22 Jan 2013 16:36:29 -0800 (PST) Received: by 10.68.218.134 with HTTP; Tue, 22 Jan 2013 16:36:29 -0800 (PST) In-Reply-To: <6366.1358887999@sandelman.ca> References: <50FEE333.5080706@saloits.com> <6366.1358887999@sandelman.ca> Date: Wed, 23 Jan 2013 01:36:29 +0100 Message-ID: From: Abdussalam Baryun To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 00:36:30 -0000 +1 AB On 1/22/13, Michael Richardson wrote: > > Please be aware that the definition of sleepy node need not be > pendantically precise. The purpose of the glossary of terms is > mostly so that when discussing LLNs with non-LLN network specialists > that we give them an idea what this could mean, not that we find do > LLN taxonomy. > > > > > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > From abdussalambaryun@gmail.com Wed Jan 23 07:55:01 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 664AE21F86B6 for ; Wed, 23 Jan 2013 07:55:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZxpD2CuCTbF for ; Wed, 23 Jan 2013 07:55:00 -0800 (PST) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id DEC1121F86AF for ; Wed, 23 Jan 2013 07:55:00 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id wy7so4730748pbc.19 for ; Wed, 23 Jan 2013 07:55:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qDPV4yaQ3ODeoRdYLMyvMA39oY1WTo2IQFGT+QQRsZo=; b=GR0FmbzSBVmsZpHEiUH4ahvS3JVLp7DJx16NiuKcTSHt+WulGd3D+5kKJnqrLf6XL+ sR/SrTCGFXN2PQufi9K3gmknHFU2h5QXpbIcueurozfeswybIgbBzXiwY6Qnl26S0IdO w9X7j/c/qetLxv5o5/VZx0w8uq+m3uMnZPUctCwrwniySypb2QQgqhB69OAoNNFSd3LQ WPpVAK8+LVbItA9nMBMKLzeR7yY9WOBETcShGGKkSkEpWZqXnQv1VbzsB8aIdgWBJqSh 9qYHi16AqOoT9XP0M7nJ32DV/woA+qF0kdyT7XAUv/bKIA11bxx2+oO87cgSVCjDB2BA Vojg== MIME-Version: 1.0 X-Received: by 10.66.76.97 with SMTP id j1mr5610771paw.70.1358956500584; Wed, 23 Jan 2013 07:55:00 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 23 Jan 2013 07:55:00 -0800 (PST) In-Reply-To: <11173.1358889466@sandelman.ca> References: <11173.1358889466@sandelman.ca> Date: Wed, 23 Jan 2013 16:55:00 +0100 Message-ID: From: Abdussalam Baryun To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] summary of tickets on trickle-mcast X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 15:55:01 -0000 Hi Michael, and authors of the I-D In your message you mention *we need to have discussion* but I think we need something else. IMO, *We need replies from the authors* The document after its last issue got many comments and tickets but never updated even once, does it mean the authors didn't think that people have difficulty in reading or understanding? IMHO, please update considering why the comments, so you encourage discussions and people to read again, including me :) AB On 1/22/13, Michael Richardson wrote: > > http://trac.tools.ietf.org/wg/roll/trac/report/8 > contains the list of open tickets. There are some threads > linked in each ticket. > > > http://trac.tools.ietf.org/wg/roll/trac/ticket/103 > trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS > http://www.ietf.org/mail-archive/web/roll/current/msg07424.html > > This ticket has had no significant discussion. Is there an issue > here? > > > > http://trac.tools.ietf.org/wg/roll/trac/ticket/104 > security considerations. > We need to have a discussion about what are the implications > of this protocol. See next message. > > http://trac.tools.ietf.org/wg/roll/trac/ticket/105 > trickle-mcast: how to determine scope of MPL domain > We have several options from Robert Craigie in the ticket system. > Alternatives 3 and 4 were discussed, and I think that we preferred > option 4 with the multicast option always present. > Please post if you disagree. > > http://trac.tools.ietf.org/wg/roll/trac/ticket/106 > trickle-mcast: always use 6in6 encapsulation for non-link-local multicast > no clear resolution, but ticket #105 suggests answer. > > > http://trac.tools.ietf.org/wg/roll/trac/ticket/108 > trickle-mcast: should there be an explicit version field? > suggested answer was YES. > > http://trac.tools.ietf.org/wg/roll/trac/ticket/107 > trickle-mcast: should multiple parameter sets be supported > my conclusion: There is has been little discussion about this > issue. My inclination is to not include multiple sets at this > time. > > > http://trac.tools.ietf.org/wg/roll/trac/ticket/109 > trickle-mcast: should all MPL packets be destined to all-MPL-forwarders > > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > From trac+roll@trac.tools.ietf.org Wed Jan 23 08:05:13 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44B4821F8786 for ; Wed, 23 Jan 2013 08:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPBFB9OQg8fY for ; Wed, 23 Jan 2013 08:05:12 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0F321F86E8 for ; Wed, 23 Jan 2013 08:05:11 -0800 (PST) Received: from localhost ([127.0.0.1]:52341 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Ty2oy-0006Ds-OF; Wed, 23 Jan 2013 17:05:04 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, abdussalambaryun@gmail.com X-Trac-Project: roll Date: Wed, 23 Jan 2013 16:05:04 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/110#comment:1 Message-ID: <073.a18a7262ec5a3e9b7421b39d16290292@trac.tools.ietf.org> References: <058.c053ae172b60ad763a419d3caf1dd7ac@trac.tools.ietf.org> X-Trac-Ticket-ID: 110 In-Reply-To: <058.c053ae172b60ad763a419d3caf1dd7ac@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, abdussalambaryun@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20130123160512.7A0F321F86E8@ietfa.amsl.com> Resent-Date: Wed, 23 Jan 2013 08:05:11 -0800 (PST) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: Re: [Roll] [roll] #110: trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Jan 2013 16:05:13 -0000 #110: trickle-mcast: do applications receive all multicast, or just MPL encapsulated ones Comment (by abdussalambaryun@gmail.com): I don't think that non-MPL nodes are able to receive from by MPL- forwarder-nodes as IP multicasts sent with destination, without beeing joind, If I miss the point please reply. This comment Requests a reply from authors of the I-D , thanking you AB -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- mcr@sandelman.ca | mcast@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: trickle- | Version: mcast | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Jan 24 02:30:51 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA05121F8834 for ; Thu, 24 Jan 2013 02:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W-pr+9cEodSL for ; Thu, 24 Jan 2013 02:30:51 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 3200E21F872D for ; Thu, 24 Jan 2013 02:30:50 -0800 (PST) Received: from localhost ([127.0.0.1]:43758 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TyK4z-00038F-6D; Thu, 24 Jan 2013 11:30:45 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: roll Date: Thu, 24 Jan 2013 10:30:45 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/103#comment:1 Message-ID: <073.339f88b2c147aeeb45dae135f541f369@trac.tools.ietf.org> References: <058.7a7e59e1d63de176dad4a13f15227438@trac.tools.ietf.org> X-Trac-Ticket-ID: 103 In-Reply-To: <058.7a7e59e1d63de176dad4a13f15227438@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20130124103051.3200E21F872D@ietfa.amsl.com> Resent-Date: Thu, 24 Jan 2013 02:30:50 -0800 (PST) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: Re: [Roll] [roll] #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 10:30:51 -0000 #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS Comment (by esko.dijk@philips.com): This seems like a useful feature to add. Easy to specify and implement. Allowing PROACTIVE_TIMER_EXPIRATIONS to be zero does require that the parameters configured in MPL forwarders can be different per node. Reason: setting PROACTIVE_TIMER_EXPIRATIONS=0 for all MPL forwarders in an MPL domain is not useful as there are no forwarders anymore. In other words, if we accept this ticket there can't be a requirement that all MPL routers are configured with identical parameters. (This points out an unclarity in the current text: are parameters of section 6 necessarily the same for all MPL forwarders in a domain, or can they differ per MPL forwarder? Do some of the parameters need to be identical in an MPL domain, while other parameters are not?) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- mcr@sandelman.ca | mcast@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: trickle- | Version: mcast | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Jan 24 02:34:09 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D59021F8859 for ; Thu, 24 Jan 2013 02:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMglTebr4Ncl for ; Thu, 24 Jan 2013 02:34:08 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 78F1C21F883C for ; Thu, 24 Jan 2013 02:34:08 -0800 (PST) Received: from localhost ([127.0.0.1]:44121 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TyK8A-0001Kr-Pi; Thu, 24 Jan 2013 11:34:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, esko.dijk@philips.com X-Trac-Project: roll Date: Thu, 24 Jan 2013 10:34:02 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/105#comment:3 Message-ID: <073.a8a80813d355179eff135c847e305937@trac.tools.ietf.org> References: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> X-Trac-Ticket-ID: 105 In-Reply-To: <058.e817419e990e1afb26be9aa25d5cfc21@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, esko.dijk@philips.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20130124103408.78F1C21F883C@ietfa.amsl.com> Resent-Date: Thu, 24 Jan 2013 02:34:08 -0800 (PST) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: Re: [Roll] [roll] #105: trickle-mcast: how to determine scope of MPL domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 10:34:09 -0000 #105: trickle-mcast: how to determine scope of MPL domain Comment (by esko.dijk@philips.com): Based on latest message in the thread http://www.ietf.org/mail-archive/web/roll/current/msg07624.html the proposal is that (3) above will be specified in the draft, and the alternative (4) not. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- mcr@sandelman.ca | mcast@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: trickle- | Version: mcast | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Jan 24 02:47:07 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D02D21F84D5 for ; Thu, 24 Jan 2013 02:47:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O87Qbmm+BwlS for ; Thu, 24 Jan 2013 02:47:07 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E945921F84C5 for ; Thu, 24 Jan 2013 02:47:06 -0800 (PST) Received: from localhost ([127.0.0.1]:44832 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TyKKh-0008Ei-Ag; Thu, 24 Jan 2013 11:46:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, esko.dijk@philips.com X-Trac-Project: roll Date: Thu, 24 Jan 2013 10:46:59 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/107#comment:3 Message-ID: <073.aca65189e5043c888896b18e6ece08ec@trac.tools.ietf.org> References: <058.d8b807f46e7601c2df8bad69d7cb737b@trac.tools.ietf.org> X-Trac-Ticket-ID: 107 In-Reply-To: <058.d8b807f46e7601c2df8bad69d7cb737b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, esko.dijk@philips.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20130124104706.E945921F84C5@ietfa.amsl.com> Resent-Date: Thu, 24 Jan 2013 02:47:06 -0800 (PST) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: Re: [Roll] [roll] #107: trickle-mcast: should multiple parameter sets be supported X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 10:47:07 -0000 #107: trickle-mcast: should multiple parameter sets be supported Comment (by esko.dijk@philips.com): So far there have been 2 supporters in the WG for including the useful feature of (at least) 2 Trickle parameter sets. Indeed, with little discussion following. Perhaps the authors could express their view? (See also Joseph's comments http://www.ietf.org/mail- archive/web/roll/current/msg07505.html) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- mcr@sandelman.ca | mcast@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: trickle- | Version: mcast | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Jan 24 03:02:15 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89BEA21F856D for ; Thu, 24 Jan 2013 03:02:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZuNy4zBNT9U for ; Thu, 24 Jan 2013 03:02:15 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id E80DB21F868F for ; Thu, 24 Jan 2013 03:02:14 -0800 (PST) Received: from localhost ([127.0.0.1]:46139 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1TyKZP-0004k1-AQ; Thu, 24 Jan 2013 12:02:11 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: roll Date: Thu, 24 Jan 2013 11:02:11 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/109#comment:1 Message-ID: <073.270d611090f2473aa1ba6ce611499aac@trac.tools.ietf.org> References: <058.17a4c61a0b0575298f48df9ded41bd6b@trac.tools.ietf.org> X-Trac-Ticket-ID: 109 In-Reply-To: <058.17a4c61a0b0575298f48df9ded41bd6b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20130124110214.E80DB21F868F@ietfa.amsl.com> Resent-Date: Thu, 24 Jan 2013 03:02:14 -0800 (PST) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: Re: [Roll] [roll] #109: trickle-mcast: should all MPL packets be destined to all-MPL-forwarders X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 11:02:15 -0000 #109: trickle-mcast: should all MPL packets be destined to all-MPL-forwarders Comment (by esko.dijk@philips.com): Using an address FF0x::ALL_MPL_FORWARDERS as default (to avoid configuration) seems a good idea. In my understanding, it is good to make this address configurable, which allows some advanced (future?) uses: 1. running multiple MPL domains 'in parallel' (differentiating based on mcast address, where MPL forwarders are always encapsulating packets) 2. using unicast-prefix-based multicast address as the MPL-forwarder multicast address. This was proposed on the list at some point as a fine- grained hierarchical way to control propagation of MPL packets through an MPL domain. (See message http://www.ietf.org/mail- archive/web/roll/current/msg07392.html and related ones in the thread) -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- mcr@sandelman.ca | mcast@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: trickle- | Version: mcast | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From internet-drafts@ietf.org Thu Jan 24 08:09:16 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 625A721F8A42; Thu, 24 Jan 2013 08:09:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.456 X-Spam-Level: X-Spam-Status: No, score=-102.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCcs4HjqZOYF; Thu, 24 Jan 2013 08:09:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE79C21F8A51; Thu, 24 Jan 2013 08:09:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> Date: Thu, 24 Jan 2013 08:09:07 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 16:09:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : Multicast Protocol for Low power and Lossy Networks (MPL) Author(s) : Jonathan W. Hui Richard Kelsey Filename : draft-ietf-roll-trickle-mcast-03.txt Pages : 29 Date : 2013-01-24 Abstract: This document specifies the Multicast Protocol for Low power and Lossy Networks (MPL) that provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL forwarders in an MPL domain. MPL uses the Trickle algorithm to manage message transmissions for both control and data-plane messages. Different Trickle parameter configurations allow MPL to trade between dissemination latency and transmission efficiency. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From johui@cisco.com Thu Jan 24 08:13:38 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED9821F8A68 for ; Thu, 24 Jan 2013 08:13:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L2JF0cOqXuBz for ; Thu, 24 Jan 2013 08:13:37 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 056C221F855D for ; Thu, 24 Jan 2013 08:13:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2668; q=dns/txt; s=iport; t=1359044017; x=1360253617; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=IyPI43u+DHte4oWgNCMWbGks6hYQ+7xb+2p7/eBd/bk=; b=dxckOPwRwQaMC+IiwzYMym0AqsWd9R5U7O8nEhZxSC00P9I/vc+c9KZk R+MnZA8ahb+x1EDdEuw32nFKzlpHWkG5bSo+jkUWazD9zN5VbmwO8OyLs R+ahpY8WdxXhTUo91OvQZJKkiJ4QGVWm8N3vh0gx2FwaXavsnmengbZXh 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFACFcAVGtJV2c/2dsb2JhbABEg3W6UxZzgh4BAQEDAQEBATc0GwIBCCIUECcLJQIEEwgBiAsGBwW+Do0UCYJ9YQOXKI8sgniCJA X-IronPort-AV: E=Sophos;i="4.84,530,1355097600"; d="scan'208";a="167482938" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP; 24 Jan 2013 16:13:36 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0OGDaB9020758 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 24 Jan 2013 16:13:36 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Thu, 24 Jan 2013 10:13:36 -0600 From: "Jonathan Hui (johui)" To: "roll@ietf.org WG" Thread-Topic: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt Thread-Index: AQHN+k3DZ/iaYoyV7EKQpxikzCRBNQ== Date: Thu, 24 Jan 2013 16:13:36 +0000 Message-ID: References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> In-Reply-To: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.9] Content-Type: text/plain; charset="us-ascii" Content-ID: <56F83A44BF513344892255B9BD175270@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 16:13:38 -0000 This update addresses all of the open tickets in the following manner: Ticket 103: MPL Control Messages may be disabled by setting CONTROL_MESSAGE= _TIMER_EXPIRATIONS to zero. Ticket 104: Added security considerations text. Ticket 105: Scope is determined by the IPv6 Destination Address of MPL Data= Packet. Ticket 106: Text added to always use IPv6-in-IPv6 encapsulation when multic= ast destination does not match MPL Domain Address. Ticket 107: Multiple parameter sets are not supported at this time. Ticket 108: Added explicit 1-bit version field. Ticket 109: All MPL packets must be destined to the MPL Domain Address that= identifies the MPL Domain. Ticket 110: Not in scope. If an application subscribes to an address, it s= hould receive all packets destined to that address whether or not they were= received in an MPL Data Packet. -- Jonathan Hui On Jan 24, 2013, at 8:09 AM, wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Routing Over Low power and Lossy network= s Working Group of the IETF. >=20 > Title : Multicast Protocol for Low power and Lossy Networks (M= PL) > Author(s) : Jonathan W. Hui > Richard Kelsey > Filename : draft-ietf-roll-trickle-mcast-03.txt > Pages : 29 > Date : 2013-01-24 >=20 > Abstract: > This document specifies the Multicast Protocol for Low power and > Lossy Networks (MPL) that provides IPv6 multicast forwarding in > constrained networks. MPL avoids the need to construct or maintain > any multicast forwarding topology, disseminating messages to all MPL > forwarders in an MPL domain. MPL uses the Trickle algorithm to > manage message transmissions for both control and data-plane > messages. Different Trickle parameter configurations allow MPL to > trade between dissemination latency and transmission efficiency. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-03 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-03 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Thu Jan 24 10:17:17 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BED721F8445 for ; Thu, 24 Jan 2013 10:17:17 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D6bO5SSMirhN for ; Thu, 24 Jan 2013 10:17:17 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 1917421F844A for ; Thu, 24 Jan 2013 10:17:16 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id B980420168 for ; Thu, 24 Jan 2013 13:22:26 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 62EB563765; Thu, 24 Jan 2013 13:16:19 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4E47F63761 for ; Thu, 24 Jan 2013 13:16:19 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <073.339f88b2c147aeeb45dae135f541f369@trac.tools.ietf.org> References: <058.7a7e59e1d63de176dad4a13f15227438@trac.tools.ietf.org> <073.339f88b2c147aeeb45dae135f541f369@trac.tools.ietf.org> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] [roll] #103: trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:17:17 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "roll" =3D=3D roll issue tracker writ= es: roll> (This points out an unclarity in the current text: are roll> parameters of=20 roll> section 6 necessarily the same for all MPL forwarders in a roll> domain, or can=20 roll> they differ per MPL forwarder? Do some of the parameters need to = be roll> identical in an MPL domain, while other parameters are not?) one of the key thing that ITEF protocol documents need to do, is rather than "prescribe" that all the parameters need to be identical, it needs rather to explain what will happen when they are not, and explain how the protocol recovers, fails safely, and does not melt down. I can not answer your question, as I do not yet understand the parameters well enough. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUQF6c4qHRg3pndX9AQIJXwQApiR5I65Njrh/qu1V0ywaq2iNZ030cqZS v8xHdSo26jbXMQpRHUhca3g5heRNXCTR50Yn/QFu8Vjz/NpUgKMym7bM16wo/76F zDfVwOResyMpk0Pn5aEZhDgPNcQq7fQR52lCRXiC3tHa8giSr45h1q79syfWEtmT xeS/SLqMCCs= =WrHP -----END PGP SIGNATURE----- --=-=-=-- From abdussalambaryun@gmail.com Thu Jan 24 10:58:51 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA9821F84F6 for ; Thu, 24 Jan 2013 10:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d62VQn1ISVvY for ; Thu, 24 Jan 2013 10:58:50 -0800 (PST) Received: from mail-da0-f47.google.com (mail-da0-f47.google.com [209.85.210.47]) by ietfa.amsl.com (Postfix) with ESMTP id 428B921F84F2 for ; Thu, 24 Jan 2013 10:58:50 -0800 (PST) Received: by mail-da0-f47.google.com with SMTP id s35so4380858dak.20 for ; Thu, 24 Jan 2013 10:58:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vc8EkQhmG8jeGtmQSnX2pgw8bfSnVGc77msc1k4CE9A=; b=N8OPVNfwAxCBklBgWDWpgyyPDfD/pX1AN89iEYZp04idFZy0fethfA5qrGgz6QjZX6 ID0YXj9w7z6cAB9okThGb3h0euVkZAqKIt3suarhX/+OLvDgjdTI1FqXJurB9MM3C3wt ehTn0YsKGeZuZ4rk+ReNAqEAtvSIaDK1P0vGUuhicqt7xbEXAngALFyxg59Jrf6/9rQW HfCOkXrqHA4AkXxWXpgDBG1PBhSOZUFcSqq+MN9g3OCiJvNkOSXVcw5yn8roYolMCJTr RDUh4qPuWLkQIdFuqakPTtNSBji94psClzWE3b5WzzaQsBxyMFE2Xp44sEqtwPqE7hTh gRQw== MIME-Version: 1.0 X-Received: by 10.66.80.202 with SMTP id t10mr7033067pax.81.1359053929990; Thu, 24 Jan 2013 10:58:49 -0800 (PST) Received: by 10.68.218.134 with HTTP; Thu, 24 Jan 2013 10:58:49 -0800 (PST) In-Reply-To: References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> Date: Thu, 24 Jan 2013 19:58:49 +0100 Message-ID: From: Abdussalam Baryun To: "Jonathan Hui (johui)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "roll@ietf.org WG" Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Jan 2013 18:58:51 -0000 Hi Jonathan, I thank you and the authors for the update, looking forward to review, AB On 1/24/13, Jonathan Hui (johui) wrote: > > This update addresses all of the open tickets in the following manner: > > Ticket 103: MPL Control Messages may be disabled by setting > CONTROL_MESSAGE_TIMER_EXPIRATIONS to zero. > > Ticket 104: Added security considerations text. > > Ticket 105: Scope is determined by the IPv6 Destination Address of MPL Data > Packet. > > Ticket 106: Text added to always use IPv6-in-IPv6 encapsulation when > multicast destination does not match MPL Domain Address. > > Ticket 107: Multiple parameter sets are not supported at this time. > > Ticket 108: Added explicit 1-bit version field. > > Ticket 109: All MPL packets must be destined to the MPL Domain Address that > identifies the MPL Domain. > > Ticket 110: Not in scope. If an application subscribes to an address, it > should receive all packets destined to that address whether or not they were > received in an MPL Data Packet. > > -- > Jonathan Hui > > On Jan 24, 2013, at 8:09 AM, wrote: > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Routing Over Low power and Lossy networks >> Working Group of the IETF. >> >> Title : Multicast Protocol for Low power and Lossy Networks >> (MPL) >> Author(s) : Jonathan W. Hui >> Richard Kelsey >> Filename : draft-ietf-roll-trickle-mcast-03.txt >> Pages : 29 >> Date : 2013-01-24 >> >> Abstract: >> This document specifies the Multicast Protocol for Low power and >> Lossy Networks (MPL) that provides IPv6 multicast forwarding in >> constrained networks. MPL avoids the need to construct or maintain >> any multicast forwarding topology, disseminating messages to all MPL >> forwarders in an MPL domain. MPL uses the Trickle algorithm to >> manage message transmissions for both control and data-plane >> messages. Different Trickle parameter configurations allow MPL to >> trade between dissemination latency and transmission efficiency. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-03 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-trickle-mcast-03 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From abdussalambaryun@gmail.com Fri Jan 25 14:50:55 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7B2921F88A2 for ; Fri, 25 Jan 2013 14:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZTnX7bpMtQe for ; Fri, 25 Jan 2013 14:50:55 -0800 (PST) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2B46521F888B for ; Fri, 25 Jan 2013 14:50:55 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id ro12so472929pbb.10 for ; Fri, 25 Jan 2013 14:50:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=f9ddOogXMHb6XTbDCiwnGsS9yWxUz4GPMzrp36wMv44=; b=Hl7mxW9WQk8fZKcuf6y9PbZJ5Jlr43GW4rsCtisBHZhQ0reCEDjcnfxP5oGrPXfPTs si7uClw9MLLBoNo7W+OKVmpeDc7Y7Tt1TM8wmnnNzte4R3k2TSfv63EyvAwIwONMGK1V UN4kuMANbcjf3a4nrDBhEMq9JYyBkvnkOnK7UTJOqKBzQlW9vx6aJy/ZhM58RJRf1i4K uK/qwuOSs0/FMjMM/TcOexHzrm6KLphNfw2dGG6wmEZMXmvztc4Mkxucr9jauqQOFjmw ck9I7dSFAsQBXw46FPp8PqI5aV8hUbWmAvrwP927mw9Cr9/oLWBa5wkiu74SsnO0gh+W NEDA== MIME-Version: 1.0 X-Received: by 10.68.227.33 with SMTP id rx1mr18181244pbc.67.1359154254937; Fri, 25 Jan 2013 14:50:54 -0800 (PST) Received: by 10.68.218.134 with HTTP; Fri, 25 Jan 2013 14:50:54 -0800 (PST) Date: Fri, 25 Jan 2013 23:50:54 +0100 Message-ID: From: Abdussalam Baryun To: jonhui@cisco.com, richard.kelsey@silabs.com Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 22:50:55 -0000 Dear I-D Authors, I done a little review so far and need answers to continue, as the ROLL chair asked for some discussion on our WG draft, which I will try to do so far. I see that the draft's applicability statement does not include *shared medium*, but the *trickel algorithm* works for shared medium, which in RFC6206 states that in the abstract. So if this MPL uses trickel do you think it still will work in a non-shared communication medium LLN, Please advise? otherwise I recommend to add the words as in trickel: *lossy shared medium* As in the appplicability statement section 3 AB> Recommend Amend to> This protocol is an IPv6 multicast forwarding protocol for nodes in shared medium within the low-power and lossy network domain. By implementing a controlled dissemination using the Trickle algorithm, this protocol is designed for networks that communicate using low-power and lossy links with widely varying topologies in both the space and time dimensions. AB> question on section 3> I am not sure I understand *the space and time dimensions*, Do you mean that the topology or multicast-nodes is/are changing in space, please give me an example use-case? Regards AB >> On 1/22/13, Michael Richardson wrote: >> >> http://trac.tools.ietf.org/wg/roll/trac/report/8 >> contains the list of open tickets. There are some threads >> linked in each ticket. >> >> >> http://trac.tools.ietf.org/wg/roll/trac/ticket/103 >> trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS >> http://www.ietf.org/mail-archive/web/roll/current/msg07424.html >> >> This ticket has had no significant discussion. Is there an issue >> here? >> >> >> >> http://trac.tools.ietf.org/wg/roll/trac/ticket/104 >> security considerations. >> We need to have a discussion about what are the implications >> of this protocol. See next message. >> >> http://trac.tools.ietf.org/wg/roll/trac/ticket/105 >> trickle-mcast: how to determine scope of MPL domain >> We have several options from Robert Craigie in the ticket system. >> Alternatives 3 and 4 were discussed, and I think that we preferred >> option 4 with the multicast option always present. >> Please post if you disagree. >> >> http://trac.tools.ietf.org/wg/roll/trac/ticket/106 >> trickle-mcast: always use 6in6 encapsulation for non-link-local multicast >> no clear resolution, but ticket #105 suggests answer. >> >> >> http://trac.tools.ietf.org/wg/roll/trac/ticket/108 >> trickle-mcast: should there be an explicit version field? >> suggested answer was YES. >> >> http://trac.tools.ietf.org/wg/roll/trac/ticket/107 >> trickle-mcast: should multiple parameter sets be supported >> my conclusion: There is has been little discussion about this >> issue. My inclination is to not include multiple sets at this >> time. >> >> >> http://trac.tools.ietf.org/wg/roll/trac/ticket/109 >> trickle-mcast: should all MPL packets be destined to all-MPL-forwarders >> >> >> -- >> Michael Richardson , Sandelman Software Works >> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >> >> > From jreddy@ti.com Fri Jan 25 14:52:15 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695D821F88A6 for ; Fri, 25 Jan 2013 14:52:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a2Lj1XKq4VIZ for ; Fri, 25 Jan 2013 14:52:14 -0800 (PST) Received: from comal.ext.ti.com (comal.ext.ti.com [198.47.26.152]) by ietfa.amsl.com (Postfix) with ESMTP id D120C21F888B for ; Fri, 25 Jan 2013 14:52:14 -0800 (PST) Received: from dlelxv30.itg.ti.com ([172.17.2.17]) by comal.ext.ti.com (8.13.7/8.13.7) with ESMTP id r0PMqEXd013034 for ; Fri, 25 Jan 2013 16:52:14 -0600 Received: from DLEE74.ent.ti.com (dlee74.ent.ti.com [157.170.170.8]) by dlelxv30.itg.ti.com (8.13.8/8.13.8) with ESMTP id r0PMqEJ5024128 for ; Fri, 25 Jan 2013 16:52:14 -0600 Received: from DLEE10.ent.ti.com ([fe80::843:a4aa:bf01:3f68]) by DLEE74.ent.ti.com ([fe80::a0f1:125b:e7e3:7ed8%18]) with mapi id 14.01.0323.003; Fri, 25 Jan 2013 16:52:14 -0600 From: "Reddy, Joseph" To: "roll@ietf.org" Thread-Topic: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt Thread-Index: Ac37TkxkFC4BjPcoQgqYukoNiFY0fg== Date: Fri, 25 Jan 2013 22:52:13 +0000 Message-ID: <2AA5AC69E924D149A8D63EB676AF87DB2CB38F33@DLEE10.ent.ti.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [157.170.170.90] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 22:52:15 -0000 Thanks Jonathan and Richard for the updated draft. It looks good and addres= sed all my previous comments. I should also mention that we have been performing interoperability testing= within the ZigBee IP community this week. We have 6 independent implementa= tions of the MPL protocol (running over 802.15.4 radios) and were able to s= uccessfully interop among all of them. We tested MPL protocol with and with= out the tunneling options.=20 -Regards, Joseph ------------------------------ Message: 5 Date: Thu, 24 Jan 2013 08:09:07 -0800 From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt Message-ID: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=3D"utf-8" A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : Multicast Protocol for Low power and Lossy Networks (MPL= ) Author(s) : Jonathan W. Hui Richard Kelsey Filename : draft-ietf-roll-trickle-mcast-03.txt Pages : 29 Date : 2013-01-24 Abstract: This document specifies the Multicast Protocol for Low power and Lossy Networks (MPL) that provides IPv6 multicast forwarding in constrained networks. MPL avoids the need to construct or maintain any multicast forwarding topology, disseminating messages to all MPL forwarders in an MPL domain. MPL uses the Trickle algorithm to manage message transmissions for both control and data-plane messages. Different Trickle parameter configurations allow MPL to trade between dissemination latency and transmission efficiency. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From paduffy@cisco.com Fri Jan 25 14:54:19 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA0E921F88B4 for ; Fri, 25 Jan 2013 14:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yP0ITPYyXgtW for ; Fri, 25 Jan 2013 14:54:19 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 03CF821F88B0 for ; Fri, 25 Jan 2013 14:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2627; q=dns/txt; s=iport; t=1359154459; x=1360364059; h=message-id:date:from:reply-to:mime-version:to:subject: references:in-reply-to:content-transfer-encoding; bh=E/eIMyrYivW0igQTZLYsHq+MyG0FoGsnJy1VoegsTfg=; b=jgZH4ygEOAcHOOJWaWRrTDsL5YyPd5bfB/nY/vguXVJE6eIzAObZdoPb KDM2aY78kgHvAknL+umiRqwYkxYhPHnaiUhBxckfY2RVlMwKX9YmSiHXC u+lMLwYYYhlszG0DDfXPy9jZizg/w05RxD3XBbcgeWCzHw2wXbNg7YvmZ s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FABQMA1GrRDoJ/2dsb2JhbABFg3W6XRZzgh4BAQEEAQEBNTYKEQsRAwECAQkWDwkDAgECARUoCBMGAgEBBQsGh3QBBwW+TI0VgQGDKQOIYY0sgRyET4pdgxU X-IronPort-AV: E=Sophos;i="4.84,541,1355097600"; d="scan'208";a="69652023" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 25 Jan 2013 22:54:18 +0000 Received: from [161.44.66.110] (dhcp-161-44-66-110.cisco.com [161.44.66.110]) by mtv-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0PMsFwN003972 for ; Fri, 25 Jan 2013 22:54:15 GMT Message-ID: <51030D16.5020609@cisco.com> Date: Fri, 25 Jan 2013 17:54:14 -0500 From: Paul Duffy Organization: Cisco Systems User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: roll@ietf.org References: <2AA5AC69E924D149A8D63EB676AF87DB2CB38F33@DLEE10.ent.ti.com> In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CB38F33@DLEE10.ent.ti.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: paduffy@cisco.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, 25 Jan 2013 22:54:19 -0000 This is excellent news Joseph. Thanks for sharing. On 1/25/2013 5:52 PM, Reddy, Joseph wrote: > Thanks Jonathan and Richard for the updated draft. It looks good and addressed all my previous comments. > > I should also mention that we have been performing interoperability testing within the ZigBee IP community this week. We have 6 independent implementations of the MPL protocol (running over 802.15.4 radios) and were able to successfully interop among all of them. We tested MPL protocol with and without the tunneling options. > > > -Regards, Joseph > > ------------------------------ > > Message: 5 > Date: Thu, 24 Jan 2013 08:09:07 -0800 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt > Message-ID: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > Title : Multicast Protocol for Low power and Lossy Networks (MPL) > Author(s) : Jonathan W. Hui > Richard Kelsey > Filename : draft-ietf-roll-trickle-mcast-03.txt > Pages : 29 > Date : 2013-01-24 > > Abstract: > This document specifies the Multicast Protocol for Low power and > Lossy Networks (MPL) that provides IPv6 multicast forwarding in > constrained networks. MPL avoids the need to construct or maintain > any multicast forwarding topology, disseminating messages to all MPL > forwarders in an MPL domain. MPL uses the Trickle algorithm to > manage message transmissions for both control and data-plane > messages. Different Trickle parameter configurations allow MPL to > trade between dissemination latency and transmission efficiency. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-trickle-mcast-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > . > From abdussalambaryun@gmail.com Fri Jan 25 14:58:01 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C262D21F88BD for ; Fri, 25 Jan 2013 14:58:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QIzS+b--aJf1 for ; Fri, 25 Jan 2013 14:58:01 -0800 (PST) Received: from mail-pb0-f41.google.com (mail-pb0-f41.google.com [209.85.160.41]) by ietfa.amsl.com (Postfix) with ESMTP id 36C9C21F88CB for ; Fri, 25 Jan 2013 14:58:01 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id xa7so476430pbc.28 for ; Fri, 25 Jan 2013 14:58:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=oFaoaKHdG4fXjRsA6TB9D7P6gmABYkBr2HkUiXxPMA0=; b=hJZg9FjNLxEbYnf1d8VmdrIhvy/yP1bxsplYw4p072swsfAJNDlUFmpI+lngIzaH0b 8BgUITIizPdpU5lqbE7UJ6kQzXByIvPiCrqxinAB2/0WhGE9/HO7HOVhz0s4hpQAPI3U f76/XFk3WcjblVX2Maw+8xpG9wYFoJO18BW3ADUEnmvMDczDobN6EkVvKVHNHOWzxXo5 hi/Nmb38HC6rYdQhrLs8cTETtcFW4DI1A3JzEXRld7cg/GgOzi6sumoo1wDcP0nmlmFC xnCRBerzIZn82MHhweIaenK8pWB7H+Ms3xWJFz2m4Oc+0A2O1Fh7Z68zse7hyh0tXrqi W94w== MIME-Version: 1.0 X-Received: by 10.66.76.97 with SMTP id j1mr17062429paw.70.1359154680956; Fri, 25 Jan 2013 14:58:00 -0800 (PST) Received: by 10.68.218.134 with HTTP; Fri, 25 Jan 2013 14:58:00 -0800 (PST) In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CB38F33@DLEE10.ent.ti.com> References: <2AA5AC69E924D149A8D63EB676AF87DB2CB38F33@DLEE10.ent.ti.com> Date: Fri, 25 Jan 2013 23:58:00 +0100 Message-ID: From: Abdussalam Baryun To: "Reddy, Joseph" Content-Type: text/plain; charset=ISO-8859-1 Cc: "roll@ietf.org" Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 22:58:01 -0000 Hi Joseph, That is good news, please inform us with the test results, because I don't know what was the test (steps or metrics) and what was the success in what, the interop has a large meaning which I may not understand, please advise, AB On 1/25/13, Reddy, Joseph wrote: > > Thanks Jonathan and Richard for the updated draft. It looks good and > addressed all my previous comments. > > I should also mention that we have been performing interoperability testing > within the ZigBee IP community this week. We have 6 independent > implementations of the MPL protocol (running over 802.15.4 radios) and were > able to successfully interop among all of them. We tested MPL protocol with > and without the tunneling options. > > > -Regards, Joseph > > ------------------------------ > > Message: 5 > Date: Thu, 24 Jan 2013 08:09:07 -0800 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt > Message-ID: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy networks > Working Group of the IETF. > > Title : Multicast Protocol for Low power and Lossy Networks > (MPL) > Author(s) : Jonathan W. Hui > Richard Kelsey > Filename : draft-ietf-roll-trickle-mcast-03.txt > Pages : 29 > Date : 2013-01-24 > > Abstract: > This document specifies the Multicast Protocol for Low power and > Lossy Networks (MPL) that provides IPv6 multicast forwarding in > constrained networks. MPL avoids the need to construct or maintain > any multicast forwarding topology, disseminating messages to all MPL > forwarders in an MPL domain. MPL uses the Trickle algorithm to > manage message transmissions for both control and data-plane > messages. Different Trickle parameter configurations allow MPL to > trade between dissemination latency and transmission efficiency. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-trickle-mcast-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From d.sturek@att.net Fri Jan 25 15:14:38 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16F3221F88AE for ; Fri, 25 Jan 2013 15:14:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id miJ2M7la2AL6 for ; Fri, 25 Jan 2013 15:14:37 -0800 (PST) Received: from nm4.bullet.mail.ne1.yahoo.com (nm4.bullet.mail.ne1.yahoo.com [98.138.90.67]) by ietfa.amsl.com (Postfix) with ESMTP id BECAD21F8445 for ; Fri, 25 Jan 2013 15:14:30 -0800 (PST) Received: from [98.138.226.179] by nm4.bullet.mail.ne1.yahoo.com with NNFMP; 25 Jan 2013 23:14:25 -0000 Received: from [98.138.226.57] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 25 Jan 2013 23:14:25 -0000 Received: from [127.0.0.1] by smtp208.mail.ne1.yahoo.com with NNFMP; 25 Jan 2013 23:14:25 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1359155665; bh=Yl95bxPQkYHUPmd5G+VcIt3pvt7gAFwuhz8AsllsUSA=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Date:Subject:Message-ID:Importance:From:To:Cc:Reply-To:MIME-Version:Content-Type; b=eVHZGh/qi4sMy00xvanzcL4tE68gwSAUPTk9VeLXVncxPnRrzaWchKukLjoV1Lx5wimb5ty6Kfh43A9M9dnL7f/iF2f0+LxFmC006azINbFrtJabQw5kB+Jv8XYzPVHf3es3CFMnvawEvh58yR6nwfLdcPuDmMcWATww8grFFXY= X-Yahoo-Newman-Id: 476344.29549.bm@smtp208.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: _NgbBbgVM1ldlCeOYRM2Pr4.EFHkCXB5arhFQdIR9wsxIDm R2Kd.otqMlWnx_e99Kdb61v87wSVh19Eu7e30t021Qb1_2fUVfc8aKUSCMzS mZBTndrAwGAuRZkvB8I5xvFisLFmlqwl8XV4SMF.ZsMq5t94HedJIhLm_b73 mqVlyzBJAc7EWmrHGty22HlkGRRVHMcpnoodTa3er3f.4VlfAXy6iWoiUFJO J4IgcyplM.sNWlyM6I_m9HIQORBUAiWegtqUnPCe_YMu_fH9uVuziGZRfoBT GEgsj6zN79jcD4ce7l7Ej5.x7TxC2KyCLVvdWCv7wkgi7cp2rpR8BRfSGYFO hQzkK_12JJ9H9JRJD2JxewYru5nYJqsYu9BvxNx8SbGg7kwC.J8.6WNhsMcS XFuJPxR3QgFfStfXdCXl90vzAxKJq2vyeGyepp83rHKndKFXma_A5nwkVLMN 4Kca6dzvRZiob X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [100.138.85.201] (d.sturek@208.54.40.157 with plain) by smtp208.mail.ne1.yahoo.com with SMTP; 25 Jan 2013 15:14:25 -0800 PST Date: Fri, 25 Jan 2013 17:14:18 -0600 Message-ID: Importance: normal From: Don Sturek To: abdussalambaryun@gmail.com, jreddy@ti.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_23172229870020" Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Don Sturek List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 23:14:38 -0000 ----_com.android.email_23172229870020 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgQWJkdWxzYWxhbSwKClVuZm9ydHVuYXRlbHksIHRoZSBaaWdCZWUgQWxsaWFuY2UgaXMgYSBj b21tZXJjaWFsIHN0YW5kYXJkcyBncm91cCBzbyB3ZSBjYW5ub3QgcHJvdmlkZSBjb3BpZXMgb2Yg dGhlIHRlc3QgcGxhbgoKSSBiZWxpZXZlIHdlIGNhbiBzdW1tYXJpemUgdGhlIHRlc3RzIGFuZCBw cm92aWRlIGEgc3VtbWFyaXplZCByZXBvcnQuCgpEb24gU3R1cmVrCgoKRnJvbSBteSBBbmRyb2lk IHBob25lIG9uIFQtTW9iaWxlLiBUaGUgZmlyc3QgbmF0aW9ud2lkZSA0RyBuZXR3b3JrLgoKLS0t LS0tLS0gT3JpZ2luYWwgbWVzc2FnZSAtLS0tLS0tLQpGcm9tOiBBYmR1c3NhbGFtIEJhcnl1biA8 YWJkdXNzYWxhbWJhcnl1bkBnbWFpbC5jb20+IApEYXRlOiAgClRvOiAiUmVkZHksIEpvc2VwaCIg PGpyZWRkeUB0aS5jb20+IApDYzogcm9sbEBpZXRmLm9yZyAKU3ViamVjdDogUmU6IFtSb2xsXSBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLXJvbGwtdHJpY2tsZS1tY2FzdC0wMy50eHQgCiAKSGkgSm9z ZXBoLAoKVGhhdCBpcyBnb29kIG5ld3MsIHBsZWFzZSBpbmZvcm0gdXMgd2l0aCB0aGUgdGVzdCBy ZXN1bHRzLCBiZWNhdXNlIEkKZG9uJ3Qga25vdyB3aGF0IHdhcyB0aGUgdGVzdCAoc3RlcHMgb3Ig bWV0cmljcykgYW5kIHdoYXQgd2FzIHRoZQpzdWNjZXNzIGluIHdoYXQsIHRoZSBpbnRlcm9wIGhh cyBhIGxhcmdlIG1lYW5pbmcgd2hpY2ggSSBtYXkgbm90CnVuZGVyc3RhbmQsIHBsZWFzZSBhZHZp c2UsCgpBQgoKT24gMS8yNS8xMywgUmVkZHksIEpvc2VwaCA8anJlZGR5QHRpLmNvbT4gd3JvdGU6 Cj4KPiBUaGFua3MgSm9uYXRoYW4gYW5kIFJpY2hhcmQgZm9yIHRoZSB1cGRhdGVkIGRyYWZ0LiBJ dCBsb29rcyBnb29kIGFuZAo+IGFkZHJlc3NlZCBhbGwgbXkgcHJldmlvdXMgY29tbWVudHMuCj4K PiBJIHNob3VsZCBhbHNvIG1lbnRpb24gdGhhdCB3ZSBoYXZlIGJlZW4gcGVyZm9ybWluZyBpbnRl cm9wZXJhYmlsaXR5IHRlc3RpbmcKPiB3aXRoaW4gdGhlIFppZ0JlZSBJUCBjb21tdW5pdHkgdGhp cyB3ZWVrLiBXZSBoYXZlIDYgaW5kZXBlbmRlbnQKPiBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIE1Q TCBwcm90b2NvbCAocnVubmluZyBvdmVyIDgwMi4xNS40IHJhZGlvcykgYW5kIHdlcmUKPiBhYmxl IHRvIHN1Y2Nlc3NmdWxseSBpbnRlcm9wIGFtb25nIGFsbCBvZiB0aGVtLiBXZSB0ZXN0ZWQgTVBM IHByb3RvY29sIHdpdGgKPiBhbmQgd2l0aG91dCB0aGUgdHVubmVsaW5nIG9wdGlvbnMuCj4KPgo+ IC1SZWdhcmRzLCBKb3NlcGgKPgo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+Cj4g TWVzc2FnZTogNQo+IERhdGU6IFRodSwgMjQgSmFuIDIwMTMgMDg6MDk6MDcgLTA4MDAKPiBGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcKPiBUbzogaS1kLWFubm91bmNlQGlldGYub3JnCj4g Q2M6IHJvbGxAaWV0Zi5vcmcKPiBTdWJqZWN0OiBbUm9sbF0gSS1EIEFjdGlvbjogZHJhZnQtaWV0 Zi1yb2xsLXRyaWNrbGUtbWNhc3QtMDMudHh0Cj4gTWVzc2FnZS1JRDogPDIwMTMwMTI0MTYwOTA3 LjQ4MjAuOTk5MzAuaWR0cmFja2VyQGlldGZhLmFtc2wuY29tPgo+IENvbnRlbnQtVHlwZTogdGV4 dC9wbGFpbjsgY2hhcnNldD0idXRmLTgiCj4KPgo+IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2 YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cwo+IGRpcmVjdG9yaWVzLgo+ wqAgVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgUm91dGluZyBPdmVyIExvdyBwb3dl ciBhbmQgTG9zc3kgbmV0d29ya3MKPiBXb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLgo+Cj4gVGl0 bGXCoMKgwqDCoMKgwqDCoMKgwqDCoCA6IE11bHRpY2FzdCBQcm90b2NvbCBmb3IgTG93IHBvd2Vy IGFuZCBMb3NzeSBOZXR3b3Jrcwo+IChNUEwpCj4gQXV0aG9yKHMpwqDCoMKgwqDCoMKgIDogSm9u YXRoYW4gVy4gSHVpCj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgIFJpY2hhcmQgS2Vsc2V5Cj4gRmlsZW5hbWXCoMKgwqDCoMKgwqDCoCA6IGRyYWZ0 LWlldGYtcm9sbC10cmlja2xlLW1jYXN0LTAzLnR4dAo+IFBhZ2VzwqDCoMKgwqDCoMKgwqDCoMKg wqAgOiAyOQo+IERhdGXCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIDogMjAxMy0wMS0yNAo+Cj4gQWJz dHJhY3Q6Cj7CoMKgwqAgVGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgdGhlIE11bHRpY2FzdCBQcm90 b2NvbCBmb3IgTG93IHBvd2VyIGFuZAo+wqDCoMKgIExvc3N5IE5ldHdvcmtzIChNUEwpIHRoYXQg cHJvdmlkZXMgSVB2NiBtdWx0aWNhc3QgZm9yd2FyZGluZyBpbgo+wqDCoMKgIGNvbnN0cmFpbmVk IG5ldHdvcmtzLsKgIE1QTCBhdm9pZHMgdGhlIG5lZWQgdG8gY29uc3RydWN0IG9yIG1haW50YWlu Cj7CoMKgwqAgYW55IG11bHRpY2FzdCBmb3J3YXJkaW5nIHRvcG9sb2d5LCBkaXNzZW1pbmF0aW5n IG1lc3NhZ2VzIHRvIGFsbCBNUEwKPsKgwqDCoCBmb3J3YXJkZXJzIGluIGFuIE1QTCBkb21haW4u wqAgTVBMIHVzZXMgdGhlIFRyaWNrbGUgYWxnb3JpdGhtIHRvCj7CoMKgwqAgbWFuYWdlIG1lc3Nh Z2UgdHJhbnNtaXNzaW9ucyBmb3IgYm90aCBjb250cm9sIGFuZCBkYXRhLXBsYW5lCj7CoMKgwqAg bWVzc2FnZXMuwqAgRGlmZmVyZW50IFRyaWNrbGUgcGFyYW1ldGVyIGNvbmZpZ3VyYXRpb25zIGFs bG93IE1QTCB0bwo+wqDCoMKgIHRyYWRlIGJldHdlZW4gZGlzc2VtaW5hdGlvbiBsYXRlbmN5IGFu ZCB0cmFuc21pc3Npb24gZWZmaWNpZW5jeS4KPgo+Cj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6Cj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1yb2xsLXRyaWNrbGUtbWNhc3QKPgo+IFRoZXJlJ3MgYWxzbyBhIGh0 bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Ogo+IGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWlldGYtcm9sbC10cmlja2xlLW1jYXN0LTAzCj4KPiBBIGRpZmYgZnJvbSB0aGUgcHJl dmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6Cj4gaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNk aWZmP3VybDI9ZHJhZnQtaWV0Zi1yb2xsLXRyaWNrbGUtbWNhc3QtMDMKPgo+Cj4gSW50ZXJuZXQt RHJhZnRzIGFyZSBhbHNvIGF2YWlsYWJsZSBieSBhbm9ueW1vdXMgRlRQIGF0Ogo+IGZ0cDovL2Z0 cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvCj4KPgo+Cj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18KPiBSb2xsIG1haWxpbmcgbGlzdAo+IFJvbGxAaWV0 Zi5vcmcKPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwKPgpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwpSb2xsIG1haWxpbmcg bGlzdApSb2xsQGlldGYub3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v cm9sbAo= ----_com.android.email_23172229870020 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5IaSBBYmR1bHNhbGFtLDwv ZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VW5mb3J0dW5hdGVseSwgdGhlIFppZ0JlZSBBbGxpYW5j ZSBpcyBhIGNvbW1lcmNpYWwgc3RhbmRhcmRzIGdyb3VwIHNvIHdlIGNhbm5vdCBwcm92aWRlIGNv cGllcyBvZiB0aGUgdGVzdCBwbGFuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5JIGJlbGlldmUg d2UgY2FuIHN1bW1hcml6ZSB0aGUgdGVzdHMgYW5kIHByb3ZpZGUgYSBzdW1tYXJpemVkIHJlcG9y dC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PkRvbiBTdHVyZWs8L2Rpdj48ZGl2Pjxicj48L2Rp dj48ZGl2Pjxicj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9ImZvbnQtc2l6ZTo3NSU7Y29sb3I6IzU3 NTc1NyI+RnJvbSBteSBBbmRyb2lkIHBob25lIG9uIFQtTW9iaWxlLiBUaGUgZmlyc3QgbmF0aW9u d2lkZSA0RyBuZXR3b3JrLjwvZGl2PjwvZGl2PiA8YnI+PGJyPjxicj4tLS0tLS0tLSBPcmlnaW5h bCBtZXNzYWdlIC0tLS0tLS0tPGJyPkZyb206IEFiZHVzc2FsYW0gQmFyeXVuICZsdDthYmR1c3Nh bGFtYmFyeXVuQGdtYWlsLmNvbSZndDsgPGJyPkRhdGU6ICA8YnI+VG86ICJSZWRkeSwgSm9zZXBo IiAmbHQ7anJlZGR5QHRpLmNvbSZndDsgPGJyPkNjOiByb2xsQGlldGYub3JnIDxicj5TdWJqZWN0 OiBSZTogW1JvbGxdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtcm9sbC10cmlja2xlLW1jYXN0LTAz LnR4dCA8YnI+IDxicj48YnI+SGkgSm9zZXBoLDxicj48YnI+VGhhdCBpcyBnb29kIG5ld3MsIHBs ZWFzZSBpbmZvcm0gdXMgd2l0aCB0aGUgdGVzdCByZXN1bHRzLCBiZWNhdXNlIEk8YnI+ZG9uJ3Qg a25vdyB3aGF0IHdhcyB0aGUgdGVzdCAoc3RlcHMgb3IgbWV0cmljcykgYW5kIHdoYXQgd2FzIHRo ZTxicj5zdWNjZXNzIGluIHdoYXQsIHRoZSBpbnRlcm9wIGhhcyBhIGxhcmdlIG1lYW5pbmcgd2hp Y2ggSSBtYXkgbm90PGJyPnVuZGVyc3RhbmQsIHBsZWFzZSBhZHZpc2UsPGJyPjxicj5BQjxicj48 YnI+T24gMS8yNS8xMywgUmVkZHksIEpvc2VwaCAmbHQ7anJlZGR5QHRpLmNvbSZndDsgd3JvdGU6 PGJyPiZndDs8YnI+Jmd0OyBUaGFua3MgSm9uYXRoYW4gYW5kIFJpY2hhcmQgZm9yIHRoZSB1cGRh dGVkIGRyYWZ0LiBJdCBsb29rcyBnb29kIGFuZDxicj4mZ3Q7IGFkZHJlc3NlZCBhbGwgbXkgcHJl dmlvdXMgY29tbWVudHMuPGJyPiZndDs8YnI+Jmd0OyBJIHNob3VsZCBhbHNvIG1lbnRpb24gdGhh dCB3ZSBoYXZlIGJlZW4gcGVyZm9ybWluZyBpbnRlcm9wZXJhYmlsaXR5IHRlc3Rpbmc8YnI+Jmd0 OyB3aXRoaW4gdGhlIFppZ0JlZSBJUCBjb21tdW5pdHkgdGhpcyB3ZWVrLiBXZSBoYXZlIDYgaW5k ZXBlbmRlbnQ8YnI+Jmd0OyBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIE1QTCBwcm90b2NvbCAocnVu bmluZyBvdmVyIDgwMi4xNS40IHJhZGlvcykgYW5kIHdlcmU8YnI+Jmd0OyBhYmxlIHRvIHN1Y2Nl c3NmdWxseSBpbnRlcm9wIGFtb25nIGFsbCBvZiB0aGVtLiBXZSB0ZXN0ZWQgTVBMIHByb3RvY29s IHdpdGg8YnI+Jmd0OyBhbmQgd2l0aG91dCB0aGUgdHVubmVsaW5nIG9wdGlvbnMuPGJyPiZndDs8 YnI+Jmd0Ozxicj4mZ3Q7IC1SZWdhcmRzLCBKb3NlcGg8YnI+Jmd0Ozxicj4mZ3Q7IC0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4mZ3Q7PGJyPiZndDsgTWVzc2FnZTogNTxicj4mZ3Q7 IERhdGU6IFRodSwgMjQgSmFuIDIwMTMgMDg6MDk6MDcgLTA4MDA8YnI+Jmd0OyBGcm9tOiBpbnRl cm5ldC1kcmFmdHNAaWV0Zi5vcmc8YnI+Jmd0OyBUbzogaS1kLWFubm91bmNlQGlldGYub3JnPGJy PiZndDsgQ2M6IHJvbGxAaWV0Zi5vcmc8YnI+Jmd0OyBTdWJqZWN0OiBbUm9sbF0gSS1EIEFjdGlv bjogZHJhZnQtaWV0Zi1yb2xsLXRyaWNrbGUtbWNhc3QtMDMudHh0PGJyPiZndDsgTWVzc2FnZS1J RDogJmx0OzIwMTMwMTI0MTYwOTA3LjQ4MjAuOTk5MzAuaWR0cmFja2VyQGlldGZhLmFtc2wuY29t Jmd0Ozxicj4mZ3Q7IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXRmLTgiPGJy PiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IEEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWlsYWJsZSBm cm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0czxicj4mZ3Q7IGRpcmVjdG9yaWVzLjxicj4m Z3Q7Jm5ic3A7IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFJvdXRpbmcgT3ZlciBM b3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzPGJyPiZndDsgV29ya2luZyBHcm91cCBvZiB0aGUg SUVURi48YnI+Jmd0Ozxicj4mZ3Q7IAlUaXRsZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IE11bHRpY2FzdCBQcm90b2NvbCBmb3Ig TG93IHBvd2VyIGFuZCBMb3NzeSBOZXR3b3Jrczxicj4mZ3Q7IChNUEwpPGJyPiZndDsgCUF1dGhv cihzKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IEpvbmF0aGFuIFcuIEh1 aTxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFJpY2hh cmQgS2Vsc2V5PGJyPiZndDsgCUZpbGVuYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDogZHJhZnQtaWV0Zi1yb2xsLXRyaWNrbGUtbWNhc3QtMDMudHh0PGJyPiZn dDsgCVBhZ2VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDogMjk8YnI+Jmd0OyAJRGF0ZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IDIwMTMtMDEtMjQ8YnI+ Jmd0Ozxicj4mZ3Q7IEFic3RyYWN0Ojxicj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgZG9j dW1lbnQgc3BlY2lmaWVzIHRoZSBNdWx0aWNhc3QgUHJvdG9jb2wgZm9yIExvdyBwb3dlciBhbmQ8 YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBMb3NzeSBOZXR3b3JrcyAoTVBMKSB0aGF0IHByb3Zp ZGVzIElQdjYgbXVsdGljYXN0IGZvcndhcmRpbmcgaW48YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNw OyBjb25zdHJhaW5lZCBuZXR3b3Jrcy4mbmJzcDsgTVBMIGF2b2lkcyB0aGUgbmVlZCB0byBjb25z dHJ1Y3Qgb3IgbWFpbnRhaW48YnI+Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBhbnkgbXVsdGljYXN0 IGZvcndhcmRpbmcgdG9wb2xvZ3ksIGRpc3NlbWluYXRpbmcgbWVzc2FnZXMgdG8gYWxsIE1QTDxi cj4mZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGZvcndhcmRlcnMgaW4gYW4gTVBMIGRvbWFpbi4mbmJz cDsgTVBMIHVzZXMgdGhlIFRyaWNrbGUgYWxnb3JpdGhtIHRvPGJyPiZndDsmbmJzcDsmbmJzcDsm bmJzcDsgbWFuYWdlIG1lc3NhZ2UgdHJhbnNtaXNzaW9ucyBmb3IgYm90aCBjb250cm9sIGFuZCBk YXRhLXBsYW5lPGJyPiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgbWVzc2FnZXMuJm5ic3A7IERpZmZl cmVudCBUcmlja2xlIHBhcmFtZXRlciBjb25maWd1cmF0aW9ucyBhbGxvdyBNUEwgdG88YnI+Jmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyB0cmFkZSBiZXR3ZWVuIGRpc3NlbWluYXRpb24gbGF0ZW5jeSBh bmQgdHJhbnNtaXNzaW9uIGVmZmljaWVuY3kuPGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IFRoZSBJ RVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOjxicj4mZ3Q7IGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcm9sbC10cmlja2xlLW1j YXN0PGJyPiZndDs8YnI+Jmd0OyBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9uIGF2YWls YWJsZSBhdDo8YnI+Jmd0OyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJv bGwtdHJpY2tsZS1tY2FzdC0wMzxicj4mZ3Q7PGJyPiZndDsgQSBkaWZmIGZyb20gdGhlIHByZXZp b3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj4mZ3Q7IGh0dHA6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcm9sbC10cmlja2xlLW1jYXN0LTAzPGJyPiZndDs8YnI+ Jmd0Ozxicj4mZ3Q7IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnlt b3VzIEZUUCBhdDo8YnI+Jmd0OyBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLzxi cj4mZ3Q7PGJyPiZndDs8YnI+Jmd0Ozxicj4mZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPiZndDsgUm9sbCBtYWlsaW5nIGxpc3Q8YnI+Jmd0OyBS b2xsQGlldGYub3JnPGJyPiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9yb2xsPGJyPiZndDs8YnI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+Um9sbCBtYWlsaW5nIGxpc3Q8YnI+Um9sbEBpZXRmLm9yZzxicj5odHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGw8YnI+PC9ib2R5Pg== ----_com.android.email_23172229870020-- From d.sturek@att.net Fri Jan 25 15:19:24 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A75C21F88BF for ; Fri, 25 Jan 2013 15:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GJM+y05S1a8r for ; Fri, 25 Jan 2013 15:19:23 -0800 (PST) Received: from nm21-vm5.bullet.mail.gq1.yahoo.com (nm21-vm5.bullet.mail.gq1.yahoo.com [98.136.217.52]) by ietfa.amsl.com (Postfix) with ESMTP id 47AE521F88B6 for ; Fri, 25 Jan 2013 15:19:23 -0800 (PST) Received: from [98.137.12.61] by nm21.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jan 2013 23:19:22 -0000 Received: from [98.136.185.47] by tm6.bullet.mail.gq1.yahoo.com with NNFMP; 25 Jan 2013 23:19:22 -0000 Received: from [127.0.0.1] by smtp108.mail.gq1.yahoo.com with NNFMP; 25 Jan 2013 23:19:22 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1359155962; bh=6Xzgild2nQ6beuvEEMvtGnzobHSb2459GGKhb/e4IRw=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:Date:Subject:Message-ID:Importance:From:To:Reply-To:MIME-Version:Content-Type; b=OfI5DFdUHVdqFNvY8LoIckdOxKR4ayPI87hCRK+pRYBd2LvLGd8XSrZskjcVL/UPpEEDT/RjmrBDfW88JkEvLwEzFD6PIPJ9GH3LImPzYdUbLhnO4VJakgN+X4xYqVFKh0GdC+8clVrnnUKfsCrUVV4hAwkU9I1uWQ4GTeqKKHU= X-Yahoo-Newman-Id: 937407.35044.bm@smtp108.mail.gq1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: aCqH6_QVM1nod8462urwzVvjDRxzC.OLgaqMhvYyWIp.Gzw W2pdQIuYQueOaqxWQgI2Q80cVY63_VKncVcXhO4vtX0nKohKriLmBAuoTmo0 dEYzinihl3RechUE2g3zrZRIFWpnFVh6HoS.rSLlsphMGd6ouab44wpuAaYe h2vkezTV5wuHCrmGUzj5DB7pFw8rTtG4VvUBYbj1.w1rPtHcXhKPG6HQfBuB EUjP6bO2dJ0FjUy8JvwvaErdU.v0nZwRB8ZNuLytI6bzLdjJwwTgF3nmgag5 NAkI_855SIRSm_BoeDGBclkfozc2N.KYo_r_5k652TZMCxsw4RdkWEDSD0AF UiXm50Kf8BeJZehx1MWTyCAIiqDIG591zIR7nBgbjfyihwhA.m_ZnKQ7F1xJ xeRZk_2MrhUsWKvzzN3BjVLQoVc7e7lYSPTKWQLj3D_YAbpWvMDAa_BOOkGq bGXdBgWW9asMG X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [100.138.85.201] (d.sturek@208.54.40.157 with plain) by smtp108.mail.gq1.yahoo.com with SMTP; 25 Jan 2013 15:19:22 -0800 PST Date: Fri, 25 Jan 2013 17:19:16 -0600 Message-ID: Importance: normal From: Don Sturek To: jreddy@ti.com, roll@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="--_com.android.email_26148757551730" Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Don Sturek List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Jan 2013 23:19:24 -0000 ----_com.android.email_26148757551730 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 RGVhciBST0xMIFdHIHRlYW0sCgpXZSAodGhlIFppZ0JlZSBJUCBkZXZlbG9wZXJzKSBjYW4gcmVw b3J0IHN1Y2Vzc2Z1bGwgaW50ZXJvcCB1c2luZyB0aGUgbmV3bHkgcmV2aXNlZCBUcmlja2xlIE11 bHRpY2FzdCBkcmFmdC4gwqBXZSBhbHNvIGJlbGlldmUgdGhpcyBkcmFmdCBhZGRyZXNzZXMgdGhl IG9wZW4gdGlja2V0cyBmb3IgdGhlIGhvbWUgYXV0b21hdGlvbiB1c2UgY2FzZXMuCgpUaGFua3Mg dG8gdGhlIFJPTEwgVHJpY2xlIE11bHRpY2FzdCBhdXRob3JzIGZvciB0aGUgdGltZWx5IHVwZGF0 ZSBvZiB0aGlzIGRyYWZ0LgoKRG9uIFN0dXJlawoKCkZyb20gbXkgQW5kcm9pZCBwaG9uZSBvbiBU LU1vYmlsZS4gVGhlIGZpcnN0IG5hdGlvbndpZGUgNEcgbmV0d29yay4KCi0tLS0tLS0tIE9yaWdp bmFsIG1lc3NhZ2UgLS0tLS0tLS0KRnJvbTogIlJlZGR5LCBKb3NlcGgiIDxqcmVkZHlAdGkuY29t PiAKRGF0ZTogIApUbzogcm9sbEBpZXRmLm9yZyAKU3ViamVjdDogW1JvbGxdICBJLUQgQWN0aW9u OiBkcmFmdC1pZXRmLXJvbGwtdHJpY2tsZS1tY2FzdC0wMy50eHQgCiAKClRoYW5rcyBKb25hdGhh biBhbmQgUmljaGFyZCBmb3IgdGhlIHVwZGF0ZWQgZHJhZnQuIEl0IGxvb2tzIGdvb2QgYW5kIGFk ZHJlc3NlZCBhbGwgbXkgcHJldmlvdXMgY29tbWVudHMuCgpJIHNob3VsZCBhbHNvIG1lbnRpb24g dGhhdCB3ZSBoYXZlIGJlZW4gcGVyZm9ybWluZyBpbnRlcm9wZXJhYmlsaXR5IHRlc3Rpbmcgd2l0 aGluIHRoZSBaaWdCZWUgSVAgY29tbXVuaXR5IHRoaXMgd2Vlay4gV2UgaGF2ZSA2IGluZGVwZW5k ZW50IGltcGxlbWVudGF0aW9ucyBvZiB0aGUgTVBMIHByb3RvY29sIChydW5uaW5nIG92ZXIgODAy LjE1LjQgcmFkaW9zKSBhbmQgd2VyZSBhYmxlIHRvIHN1Y2Nlc3NmdWxseSBpbnRlcm9wIGFtb25n IGFsbCBvZiB0aGVtLiBXZSB0ZXN0ZWQgTVBMIHByb3RvY29sIHdpdGggYW5kIHdpdGhvdXQgdGhl IHR1bm5lbGluZyBvcHRpb25zLiAKCgotUmVnYXJkcywgSm9zZXBoCgotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0KCk1lc3NhZ2U6IDUKRGF0ZTogVGh1LCAyNCBKYW4gMjAxMyAwODowOTow NyAtMDgwMApGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcKVG86IGktZC1hbm5vdW5jZUBp ZXRmLm9yZwpDYzogcm9sbEBpZXRmLm9yZwpTdWJqZWN0OiBbUm9sbF0gSS1EIEFjdGlvbjogZHJh ZnQtaWV0Zi1yb2xsLXRyaWNrbGUtbWNhc3QtMDMudHh0Ck1lc3NhZ2UtSUQ6IDwyMDEzMDEyNDE2 MDkwNy40ODIwLjk5OTMwLmlkdHJhY2tlckBpZXRmYS5hbXNsLmNvbT4KQ29udGVudC1UeXBlOiB0 ZXh0L3BsYWluOyBjaGFyc2V0PSJ1dGYtOCIKCgpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuClRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExv c3N5IG5ldHdvcmtzIFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuCgpUaXRsZcKgwqDCoMKgwqDC oMKgwqDCoMKgIDogTXVsdGljYXN0IFByb3RvY29sIGZvciBMb3cgcG93ZXIgYW5kIExvc3N5IE5l dHdvcmtzIChNUEwpCkF1dGhvcihzKcKgwqDCoMKgwqDCoCA6IEpvbmF0aGFuIFcuIEh1aQrCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBSaWNoYXJkIEtl bHNleQpGaWxlbmFtZcKgwqDCoMKgwqDCoMKgIDogZHJhZnQtaWV0Zi1yb2xsLXRyaWNrbGUtbWNh c3QtMDMudHh0ClBhZ2VzwqDCoMKgwqDCoMKgwqDCoMKgwqAgOiAyOQpEYXRlwqDCoMKgwqDCoMKg wqDCoMKgwqDCoCA6IDIwMTMtMDEtMjQKCkFic3RyYWN0OgrCoMKgIFRoaXMgZG9jdW1lbnQgc3Bl Y2lmaWVzIHRoZSBNdWx0aWNhc3QgUHJvdG9jb2wgZm9yIExvdyBwb3dlciBhbmQKwqDCoCBMb3Nz eSBOZXR3b3JrcyAoTVBMKSB0aGF0IHByb3ZpZGVzIElQdjYgbXVsdGljYXN0IGZvcndhcmRpbmcg aW4KwqDCoCBjb25zdHJhaW5lZCBuZXR3b3Jrcy7CoCBNUEwgYXZvaWRzIHRoZSBuZWVkIHRvIGNv bnN0cnVjdCBvciBtYWludGFpbgrCoMKgIGFueSBtdWx0aWNhc3QgZm9yd2FyZGluZyB0b3BvbG9n eSwgZGlzc2VtaW5hdGluZyBtZXNzYWdlcyB0byBhbGwgTVBMCsKgwqAgZm9yd2FyZGVycyBpbiBh biBNUEwgZG9tYWluLsKgIE1QTCB1c2VzIHRoZSBUcmlja2xlIGFsZ29yaXRobSB0bwrCoMKgIG1h bmFnZSBtZXNzYWdlIHRyYW5zbWlzc2lvbnMgZm9yIGJvdGggY29udHJvbCBhbmQgZGF0YS1wbGFu ZQrCoMKgIG1lc3NhZ2VzLsKgIERpZmZlcmVudCBUcmlja2xlIHBhcmFtZXRlciBjb25maWd1cmF0 aW9ucyBhbGxvdyBNUEwgdG8KwqDCoCB0cmFkZSBiZXR3ZWVuIGRpc3NlbWluYXRpb24gbGF0ZW5j eSBhbmQgdHJhbnNtaXNzaW9uIGVmZmljaWVuY3kuCgoKVGhlIElFVEYgZGF0YXRyYWNrZXIgc3Rh dHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWlldGYtcm9sbC10cmlja2xlLW1jYXN0CgpUaGVyZSdzIGFsc28gYSBodG1saXpl ZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoKaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1yb2xsLXRyaWNrbGUtbWNhc3QtMDMKCkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJz aW9uIGlzIGF2YWlsYWJsZSBhdDoKaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJh ZnQtaWV0Zi1yb2xsLXRyaWNrbGUtbWNhc3QtMDMKCgpJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28g YXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6CmZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvCgoKCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fClJvbGwgbWFpbGluZyBsaXN0ClJvbGxAaWV0Zi5vcmcKaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9yb2xsCg== ----_com.android.email_26148757551730 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9VVRGLTgiPjwvaGVhZD48Ym9keSA+PGRpdj5EZWFyIFJPTEwgV0cgdGVh bSw8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PldlICh0aGUgWmlnQmVlIElQIGRldmVsb3BlcnMp IGNhbiByZXBvcnQgc3VjZXNzZnVsbCBpbnRlcm9wIHVzaW5nIHRoZSBuZXdseSByZXZpc2VkIFRy aWNrbGUgTXVsdGljYXN0IGRyYWZ0LiAmbmJzcDtXZSBhbHNvIGJlbGlldmUgdGhpcyBkcmFmdCBh ZGRyZXNzZXMgdGhlIG9wZW4gdGlja2V0cyBmb3IgdGhlIGhvbWUgYXV0b21hdGlvbiB1c2UgY2Fz ZXMuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5UaGFua3MgdG8gdGhlIFJPTEwgVHJpY2xlIE11 bHRpY2FzdCBhdXRob3JzIGZvciB0aGUgdGltZWx5IHVwZGF0ZSBvZiB0aGlzIGRyYWZ0LjwvZGl2 PjxkaXY+PGJyPjwvZGl2PjxkaXY+RG9uIFN0dXJlazwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+ PGJyPjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0iZm9udC1zaXplOjc1JTtjb2xvcjojNTc1NzU3Ij5G cm9tIG15IEFuZHJvaWQgcGhvbmUgb24gVC1Nb2JpbGUuIFRoZSBmaXJzdCBuYXRpb253aWRlIDRH IG5ldHdvcmsuPC9kaXY+PC9kaXY+IDxicj48YnI+PGJyPi0tLS0tLS0tIE9yaWdpbmFsIG1lc3Nh Z2UgLS0tLS0tLS08YnI+RnJvbTogIlJlZGR5LCBKb3NlcGgiICZsdDtqcmVkZHlAdGkuY29tJmd0 OyA8YnI+RGF0ZTogIDxicj5Ubzogcm9sbEBpZXRmLm9yZyA8YnI+U3ViamVjdDogW1JvbGxdICBJ LUQgQWN0aW9uOiBkcmFmdC1pZXRmLXJvbGwtdHJpY2tsZS1tY2FzdC0wMy50eHQgPGJyPiA8YnI+ PGJyPjxicj5UaGFua3MgSm9uYXRoYW4gYW5kIFJpY2hhcmQgZm9yIHRoZSB1cGRhdGVkIGRyYWZ0 LiBJdCBsb29rcyBnb29kIGFuZCBhZGRyZXNzZWQgYWxsIG15IHByZXZpb3VzIGNvbW1lbnRzLjxi cj48YnI+SSBzaG91bGQgYWxzbyBtZW50aW9uIHRoYXQgd2UgaGF2ZSBiZWVuIHBlcmZvcm1pbmcg aW50ZXJvcGVyYWJpbGl0eSB0ZXN0aW5nIHdpdGhpbiB0aGUgWmlnQmVlIElQIGNvbW11bml0eSB0 aGlzIHdlZWsuIFdlIGhhdmUgNiBpbmRlcGVuZGVudCBpbXBsZW1lbnRhdGlvbnMgb2YgdGhlIE1Q TCBwcm90b2NvbCAocnVubmluZyBvdmVyIDgwMi4xNS40IHJhZGlvcykgYW5kIHdlcmUgYWJsZSB0 byBzdWNjZXNzZnVsbHkgaW50ZXJvcCBhbW9uZyBhbGwgb2YgdGhlbS4gV2UgdGVzdGVkIE1QTCBw cm90b2NvbCB3aXRoIGFuZCB3aXRob3V0IHRoZSB0dW5uZWxpbmcgb3B0aW9ucy4gPGJyPjxicj48 YnI+LVJlZ2FyZHMsIEpvc2VwaDxicj48YnI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t PGJyPjxicj5NZXNzYWdlOiA1PGJyPkRhdGU6IFRodSwgMjQgSmFuIDIwMTMgMDg6MDk6MDcgLTA4 MDA8YnI+RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPGJyPlRvOiBpLWQtYW5ub3VuY2VA aWV0Zi5vcmc8YnI+Q2M6IHJvbGxAaWV0Zi5vcmc8YnI+U3ViamVjdDogW1JvbGxdIEktRCBBY3Rp b246IGRyYWZ0LWlldGYtcm9sbC10cmlja2xlLW1jYXN0LTAzLnR4dDxicj5NZXNzYWdlLUlEOiAm bHQ7MjAxMzAxMjQxNjA5MDcuNDgyMC45OTkzMC5pZHRyYWNrZXJAaWV0ZmEuYW1zbC5jb20mZ3Q7 PGJyPkNvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXRmLTgiPGJyPjxicj48YnI+ QSBOZXcgSW50ZXJuZXQtRHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJu ZXQtRHJhZnRzIGRpcmVjdG9yaWVzLjxicj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0 aGUgUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgV29ya2luZyBHcm91 cCBvZiB0aGUgSUVURi48YnI+PGJyPglUaXRsZSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6IE11bHRpY2FzdCBQcm90b2NvbCBmb3Ig TG93IHBvd2VyIGFuZCBMb3NzeSBOZXR3b3JrcyAoTVBMKTxicj4JQXV0aG9yKHMpJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogSm9uYXRoYW4gVy4gSHVpPGJyPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSaWNoYXJkIEtlbHNleTxicj4JRmlsZW5hbWUm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBkcmFmdC1pZXRmLXJv bGwtdHJpY2tsZS1tY2FzdC0wMy50eHQ8YnI+CVBhZ2VzJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDogMjk8YnI+CURhdGUmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgOiAyMDEzLTAxLTI0PGJyPjxicj5BYnN0cmFjdDo8YnI+Jm5ic3A7Jm5ic3A7IFRoaXMgZG9j dW1lbnQgc3BlY2lmaWVzIHRoZSBNdWx0aWNhc3QgUHJvdG9jb2wgZm9yIExvdyBwb3dlciBhbmQ8 YnI+Jm5ic3A7Jm5ic3A7IExvc3N5IE5ldHdvcmtzIChNUEwpIHRoYXQgcHJvdmlkZXMgSVB2NiBt dWx0aWNhc3QgZm9yd2FyZGluZyBpbjxicj4mbmJzcDsmbmJzcDsgY29uc3RyYWluZWQgbmV0d29y a3MuJm5ic3A7IE1QTCBhdm9pZHMgdGhlIG5lZWQgdG8gY29uc3RydWN0IG9yIG1haW50YWluPGJy PiZuYnNwOyZuYnNwOyBhbnkgbXVsdGljYXN0IGZvcndhcmRpbmcgdG9wb2xvZ3ksIGRpc3NlbWlu YXRpbmcgbWVzc2FnZXMgdG8gYWxsIE1QTDxicj4mbmJzcDsmbmJzcDsgZm9yd2FyZGVycyBpbiBh biBNUEwgZG9tYWluLiZuYnNwOyBNUEwgdXNlcyB0aGUgVHJpY2tsZSBhbGdvcml0aG0gdG88YnI+ Jm5ic3A7Jm5ic3A7IG1hbmFnZSBtZXNzYWdlIHRyYW5zbWlzc2lvbnMgZm9yIGJvdGggY29udHJv bCBhbmQgZGF0YS1wbGFuZTxicj4mbmJzcDsmbmJzcDsgbWVzc2FnZXMuJm5ic3A7IERpZmZlcmVu dCBUcmlja2xlIHBhcmFtZXRlciBjb25maWd1cmF0aW9ucyBhbGxvdyBNUEwgdG88YnI+Jm5ic3A7 Jm5ic3A7IHRyYWRlIGJldHdlZW4gZGlzc2VtaW5hdGlvbiBsYXRlbmN5IGFuZCB0cmFuc21pc3Np b24gZWZmaWNpZW5jeS48YnI+PGJyPjxicj5UaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFn ZSBmb3IgdGhpcyBkcmFmdCBpczo8YnI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtaWV0Zi1yb2xsLXRyaWNrbGUtbWNhc3Q8YnI+PGJyPlRoZXJlJ3MgYWxzbyBhIGh0bWxp emVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Ojxicj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLXJvbGwtdHJpY2tsZS1tY2FzdC0wMzxicj48YnI+QSBkaWZmIGZyb20gdGhlIHBy ZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Ojxicj5odHRwOi8vd3d3LmlldGYub3JnL3Jm Y2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJvbGwtdHJpY2tsZS1tY2FzdC0wMzxicj48YnI+PGJyPklu dGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDo8YnI+ ZnRwOi8vZnRwLmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy88YnI+PGJyPjxicj48YnI+X19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+Um9sbCBtYWlsaW5n IGxpc3Q8YnI+Um9sbEBpZXRmLm9yZzxicj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3JvbGw8YnI+PC9ib2R5Pg== ----_com.android.email_26148757551730-- From abdussalambaryun@gmail.com Fri Jan 25 17:05:04 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F17521F84F1 for ; Fri, 25 Jan 2013 17:05:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nUNsIZNAcJVB for ; Fri, 25 Jan 2013 17:05:03 -0800 (PST) Received: from mail-da0-f42.google.com (mail-da0-f42.google.com [209.85.210.42]) by ietfa.amsl.com (Postfix) with ESMTP id A3B8621F84D8 for ; Fri, 25 Jan 2013 17:05:03 -0800 (PST) Received: by mail-da0-f42.google.com with SMTP id z17so418024dal.15 for ; Fri, 25 Jan 2013 17:05:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=hWTDRCJ/r/ghrST6N7Bf0u9YFw3Syk6/qjg1nuFtf+M=; b=jIoI7qqZVOe9dM6BTxYdtCELMeKVOiaBcLMBpmisspOf/cy62M0wSc8vSfHUmevJ2z QiED6YDWbyj3UDhI1Zo5W9jTIR8foTkjuz68uUhcJBLMBpFsFgbHJFkjFmqZmlUFzF+6 P3Fxoe18tY/DdynfBAUPUjjL/X7TV7ORLNtC23RO6m7Jb6mlDl+FUtgg6LCzT9ZzGbY/ F4EnrSksMEXbUGweLfAKm3WJThp+lTRaa/LFfkNR6ZUNi2ODjLAjSqtPcQvjN7FaXg/L rH1PTeBtbI0Vxj7Od0wuf7AI2l4XV+kLhv1jsSvlTFltpvSJUfF1egWKPCWWj+ExY3bG UH0w== MIME-Version: 1.0 X-Received: by 10.66.79.168 with SMTP id k8mr17735592pax.22.1359162303462; Fri, 25 Jan 2013 17:05:03 -0800 (PST) Received: by 10.68.218.134 with HTTP; Fri, 25 Jan 2013 17:05:03 -0800 (PST) In-Reply-To: References: Date: Sat, 26 Jan 2013 02:05:03 +0100 Message-ID: From: Abdussalam Baryun To: Don Sturek Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org, jreddy@ti.com Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 01:05:04 -0000 Hi Don, A summary is good. I think the test/result summary or answer to the questions will help, or even better an I-D submitted. comments in line; On 1/26/13, Don Sturek wrote: > Hi Abdulsalam, > > Unfortunately, the ZigBee Alliance is a commercial standards group so we > cannot provide copies of the test plan I don't request to know every thing, just when this organisation uses an I-D specification it will be benefit to WG to know the test+method+results otherwise it will be just notification of external-events > > I believe we can summarize the tests and provide a summarized report. No problem. Usually I did not start the discussion just reflecting. As this is a discussion list of ROLL, and I received a notification of an event in this list, made me starting discussing, and want to continue if the thread poster still likes to continue. A summary will make a very big difference, thanks. Waiting for the summary :) AB From abdussalambaryun@gmail.com Sat Jan 26 04:15:38 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D559C21F84CC for ; Sat, 26 Jan 2013 04:15:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8W98sHQb+sjk for ; Sat, 26 Jan 2013 04:15:38 -0800 (PST) Received: from mail-pa0-f42.google.com (mail-pa0-f42.google.com [209.85.220.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4F69E21F8769 for ; Sat, 26 Jan 2013 04:15:38 -0800 (PST) Received: by mail-pa0-f42.google.com with SMTP id rl6so731090pac.1 for ; Sat, 26 Jan 2013 04:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=vCCn9lo5+ulS8kblNxTBuqJhZsLLJZdbLpvFoVcogbU=; b=BdObZodjRTbeDS78N4QQ9FqlTqZgf/5c3HBpmZbSauOZpfN/4y4N7PWMI1s/JtT1oo 7x4X4tnL3NCpobdXKTLZhDDd4drNul3W1gSzwJhkn00bPkbrfLAMq5JrcqUD12s50g3O RC+nlkwfO22Jyzbtu7xGdm9fcSiRwWuCvZvGZG9iVH8K5Co8DAfiJqAdRVQA4IJhI3ME rLV12k679/ZnQPdWGo8KxlZsJ+bLkGJsnmdsFm0TfyH/1Mt62Vp8MkiBUqGcWg/QRRuE 3tjZaGwb0GYSgNrKLpvsOBsC77RPZzAOzTyEpRoEY2UQe6Mk75Bb4XoIsny8R4bR3/RA Eecg== MIME-Version: 1.0 X-Received: by 10.68.136.132 with SMTP id qa4mr21610896pbb.166.1359202538059; Sat, 26 Jan 2013 04:15:38 -0800 (PST) Received: by 10.68.218.134 with HTTP; Sat, 26 Jan 2013 04:15:37 -0800 (PST) In-Reply-To: <20130122143937.17324.59444.idtracker@ietfa.amsl.com> References: <20130122143937.17324.59444.idtracker@ietfa.amsl.com> Date: Sat, 26 Jan 2013 13:15:37 +0100 Message-ID: From: Abdussalam Baryun To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-richardson-roll-applicability-template-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 12:15:38 -0000 Hi Michael, I want to discuss some things in this draft-01 if ok. I see that the draft is empty of explaination. When it was presented first draft-00, I thought the templet is about including the main issues and information in all applicability cases in this one template but now I find out that it is just sections titles, does this mean that this draft is like a guide or structure of the applicability drafts in future. Please advise, AB On 1/22/13, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Routing Over Low power and Lossy networks > Working Group of the IETF. > > Title : ROLL Applicability Statement Template > Author(s) : Michael C. Richardson > Filename : draft-richardson-roll-applicability-template-01.txt > Pages : 15 > Date : 2013-01-22 > > Abstract: > This document is a template applicability statement for the Routing > over Low-power and Lossy Networks (ROLL) WG. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-richardson-roll-applicability-template > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-richardson-roll-applicability-template-01 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-richardson-roll-applicability-template-01 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From abdussalambaryun@gmail.com Sat Jan 26 07:09:23 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1B2C21F8605 for ; Sat, 26 Jan 2013 07:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YshAvgMLkFDZ for ; Sat, 26 Jan 2013 07:09:23 -0800 (PST) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by ietfa.amsl.com (Postfix) with ESMTP id 1CD8221F85DB for ; Sat, 26 Jan 2013 07:09:23 -0800 (PST) Received: by mail-da0-f54.google.com with SMTP id n2so592118dad.13 for ; Sat, 26 Jan 2013 07:09:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EyzgZyc0T/C7GUHZaDkU/puWxebHyVmV32dBpXoiDqM=; b=WHxL72VFZf83Hp5z9k0m3DDZcK5yntcPxrgMXSeqhzun4RTh5PtE6hr0hpkXusvq7/ Lk7uQIb+gI+hNoFUVD+hkq5/N/6D7Wkm98HTmlKw8gvKyfpMu8ipbymYQ2bqHiqRTtN7 6tF70E2lBbwF3WoeEuZl2FyraTRaiOQXOPSNs+bctPHdkhgdrniYzpR1YdxtbaX/o7Zg k8GDHhQNfAIwSd84BcxcY0UUd/anwzRQo9tcd3IPEuZ1l4880IfgITYcMBZRi+Grt8z6 hJDCL3/gQ3VQAiT3zs01yci1pyTFyVu/4PzYDkRjBj5TkzCAdOQV5kHeBUVR8oR19N3R /fZA== MIME-Version: 1.0 X-Received: by 10.68.136.132 with SMTP id qa4mr22694689pbb.166.1359212962934; Sat, 26 Jan 2013 07:09:22 -0800 (PST) Received: by 10.68.218.134 with HTTP; Sat, 26 Jan 2013 07:09:22 -0800 (PST) In-Reply-To: References: Date: Sat, 26 Jan 2013 16:09:22 +0100 Message-ID: From: Abdussalam Baryun To: jonhui@cisco.com, richard.kelsey@silabs.com Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 15:09:23 -0000 I understand that all the MPL messages are Trickel messages, AB On 1/25/13, Abdussalam Baryun wrote: > Dear I-D Authors, > > I done a little review so far and need answers to continue, as the > ROLL chair asked for some discussion on our WG draft, which I will try > to do so far. > > I see that the draft's applicability statement does not include > *shared medium*, but the *trickel algorithm* works for shared medium, > which in RFC6206 states that in the abstract. So if this MPL uses > trickel do you think it still will work in a non-shared communication > medium LLN, Please advise? > > otherwise I recommend to add the words as in trickel: *lossy shared medium* > As in the appplicability statement section 3 > > AB> Recommend Amend to> > This protocol is an IPv6 multicast forwarding protocol for nodes in > shared medium within the low-power and lossy network domain. By > implementing a controlled dissemination using the Trickle algorithm, > this protocol is designed for networks that > communicate using low-power and lossy links with widely varying > topologies in both the space and time dimensions. > > AB> question on section 3> I am not sure I understand *the space and > time dimensions*, Do you mean that the topology or multicast-nodes > is/are changing in space, please give me an example use-case? > > Regards > > AB > >>> On 1/22/13, Michael Richardson wrote: >>> >>> http://trac.tools.ietf.org/wg/roll/trac/report/8 >>> contains the list of open tickets. There are some threads >>> linked in each ticket. >>> >>> >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/103 >>> trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS >>> http://www.ietf.org/mail-archive/web/roll/current/msg07424.html >>> >>> This ticket has had no significant discussion. Is there an issue >>> here? >>> >>> >>> >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/104 >>> security considerations. >>> We need to have a discussion about what are the implications >>> of this protocol. See next message. >>> >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/105 >>> trickle-mcast: how to determine scope of MPL domain >>> We have several options from Robert Craigie in the ticket system. >>> Alternatives 3 and 4 were discussed, and I think that we preferred >>> option 4 with the multicast option always present. >>> Please post if you disagree. >>> >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/106 >>> trickle-mcast: always use 6in6 encapsulation for non-link-local >>> multicast >>> no clear resolution, but ticket #105 suggests answer. >>> >>> >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/108 >>> trickle-mcast: should there be an explicit version field? >>> suggested answer was YES. >>> >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/107 >>> trickle-mcast: should multiple parameter sets be supported >>> my conclusion: There is has been little discussion about this >>> issue. My inclination is to not include multiple sets at this >>> time. >>> >>> >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/109 >>> trickle-mcast: should all MPL packets be destined to all-MPL-forwarders >>> >>> >>> -- >>> Michael Richardson , Sandelman Software Works >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>> >>> >> > From trac+roll@trac.tools.ietf.org Sat Jan 26 08:43:21 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1266321F8859 for ; Sat, 26 Jan 2013 08:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nW8lRfp7nLm2 for ; Sat, 26 Jan 2013 08:43:20 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 7A70121F882B for ; Sat, 26 Jan 2013 08:43:20 -0800 (PST) Received: from localhost ([127.0.0.1]:43600 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1Tz8qd-0001zz-5H; Sat, 26 Jan 2013 17:43:19 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: abdussalambaryun@gmail.com X-Trac-Project: roll Date: Sat, 26 Jan 2013 16:43:19 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/roll/trac/ticket/111 Message-ID: <068.d297e97474c3aa6d3b0200f33881db3c@trac.tools.ietf.org> X-Trac-Ticket-ID: 111 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: abdussalambaryun@gmail.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Cc: roll@ietf.org Subject: [Roll] [roll] #111: MPL relation with RPL is not clear X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 16:43:21 -0000 #111: MPL relation with RPL is not clear I want to understand/see an example or clarification of the relation between RPL and MPL protocols, or how can a RPL router use the MPL. How does the MPL help in reducing energy consumption in forwarding and/or routing. Please advise, AB -- ----------------------------------------+---------------------------------- Reporter: abdussalambaryun@gmail.com | Owner: Abdussalam Baryun Type: enhancement | Status: new Priority: major | Milestone: Component: trickle-mcast | Version: Severity: Active WG Document | Keywords: Multicast, RPL, | Trickle ----------------------------------------+---------------------------------- Ticket URL: roll From adrian@olddog.co.uk Sat Jan 26 08:49:37 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A209021F8873 for ; Sat, 26 Jan 2013 08:49:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id te6mdsp0v+VL for ; Sat, 26 Jan 2013 08:49:36 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id AD41421F8820 for ; Sat, 26 Jan 2013 08:49:35 -0800 (PST) Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0QGnYRY019993 for ; Sat, 26 Jan 2013 16:49:34 GMT Received: from 950129200 (089144192150.atnat0001.highway.a1.net [89.144.192.150]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r0QGnW4c019987 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 26 Jan 2013 16:49:33 GMT From: "Adrian Farrel" To: References: <20130125201316.22967.26907.idtracker@ietfa.amsl.com> In-Reply-To: <20130125201316.22967.26907.idtracker@ietfa.amsl.com> Date: Sat, 26 Jan 2013 16:49:32 -0000 Message-ID: <003701cdfbe5$1ea7ac00$5bf70400$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQDv8k1AUEYxKhX3NlIftVpDAFH/JZoX5Txg Content-Language: en-gb Subject: [Roll] FW: New Non-WG Mailing List: 6tsch -- Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: adrian@olddog.co.uk List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 16:49:37 -0000 Hi,=20 Please be aware of this new mailing list. You now know as much about it as I do :-) Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of IETF Secretariat > Sent: 25 January 2013 20:13 > To: IETF Announcement List > Cc: watteyne@eecs.berkeley.edu; pascal.thubert@gmail.com; = 6tsch@ietf.org > Subject: New Non-WG Mailing List: 6tsch -- Discuss link layer model = for > Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts = on RPL and > 6LoWPAN such as resource allocation >=20 >=20 > A new IETF non-working group email list has been created. >=20 > List address: 6tsch@ietf.org > Archive: = http://www.ietf.org/mail-archive/web/6tsch/current/maillist.html > To subscribe: https://www.ietf.org/mailman/listinfo/6tsch >=20 > Purpose: This list is for discussions relating to the development, = clarification, and > implementation of IPv6 access and meshing over deterministic = (scheduled) MAC > with specific interest in IEEE 802.15.4e TSCH. Focus is on issues = related with time > slots awareness at L3, time slots allocation and distribution, and the = eventual mix > of centralized and distributed operation for routing and resource = allocation. The > list should facilitate exchanges between opensource implementers, = share on the > applicability of the technology and address the gaps in existing IETF = specs from > RPL and 6LoWPAN. This list may steer work at the IETF, as well as IEC = and ISA. One > of the goals for the group, should we create one, would be to put = together an > IETF straw man binding existing standards (RPL, 6LoWPAN, PANA, > ForCES/OpenFlow, diffserv) over 802.15.4e. >=20 > For additional information, please contact the list administrators. From abdussalambaryun@gmail.com Sat Jan 26 08:58:18 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6523721F8859 for ; Sat, 26 Jan 2013 08:58:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.587 X-Spam-Level: X-Spam-Status: No, score=-3.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0+jtvwgIuytN for ; Sat, 26 Jan 2013 08:58:17 -0800 (PST) Received: from mail-da0-f46.google.com (mail-da0-f46.google.com [209.85.210.46]) by ietfa.amsl.com (Postfix) with ESMTP id A6E4221F882B for ; Sat, 26 Jan 2013 08:58:17 -0800 (PST) Received: by mail-da0-f46.google.com with SMTP id p5so614027dak.19 for ; Sat, 26 Jan 2013 08:58:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=Nux/Lhg3rb6GaMlAvIhrjTnIvDtguW9y6KCk8T7yHSE=; b=v9ntuDr2OQnT01qUbgmALs+PsI6mFCpcpcwnPUHYqQGUIgREqIl9kIbgwxNXTyQjf7 zBLLHAg4RGrhypGCCIfboRa/zITKzWy4lKcT/roy7rtaGFP1tY+PuVmDWP0hII5PUQfP QoEmVCOVXr+RrtpTWm4W/t945my9CXhjNDp4or4MbhIwUaDpqCdA9rQwntFasX/sp2ux TzkmA2PHotNkYeGsQTWGkrjFYyEpydI2GGKp5yVl8nAgw3M7l3vtZQUpLdKAbCdYjkFq Hd8yhwgrFkkjmw7nAF1GYZX5V006imBPcDCNNVGUD/em7PCgnYEU2iosuvY7aR0NvKcO jorA== MIME-Version: 1.0 X-Received: by 10.68.232.195 with SMTP id tq3mr23829301pbc.70.1359219497341; Sat, 26 Jan 2013 08:58:17 -0800 (PST) Received: by 10.68.218.134 with HTTP; Sat, 26 Jan 2013 08:58:17 -0800 (PST) In-Reply-To: References: Date: Sat, 26 Jan 2013 17:58:17 +0100 Message-ID: From: Abdussalam Baryun To: jonhui@cisco.com, richard.kelsey@silabs.com Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 16:58:18 -0000 The draft does not clarify how the MPL forwarding knows its neighbors, or the MPL neighbor is not defined in the doc, please advise, AB On 1/25/13, Abdussalam Baryun wrote: > Dear I-D Authors, > > I done a little review so far and need answers to continue, as the > ROLL chair asked for some discussion on our WG draft, which I will try > to do so far. > > I see that the draft's applicability statement does not include > *shared medium*, but the *trickel algorithm* works for shared medium, > which in RFC6206 states that in the abstract. So if this MPL uses > trickel do you think it still will work in a non-shared communication > medium LLN, Please advise? > > otherwise I recommend to add the words as in trickel: *lossy shared medium* > As in the appplicability statement section 3 > > AB> Recommend Amend to> > This protocol is an IPv6 multicast forwarding protocol for nodes in > shared medium within the low-power and lossy network domain. By > implementing a controlled dissemination using the Trickle algorithm, > this protocol is designed for networks that > communicate using low-power and lossy links with widely varying > topologies in both the space and time dimensions. > > AB> question on section 3> I am not sure I understand *the space and > time dimensions*, Do you mean that the topology or multicast-nodes > is/are changing in space, please give me an example use-case? > > Regards > > AB > >>> On 1/22/13, Michael Richardson wrote: >>> >>> http://trac.tools.ietf.org/wg/roll/trac/report/8 >>> contains the list of open tickets. There are some threads >>> linked in each ticket. >>> >>> >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/103 >>> trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS >>> http://www.ietf.org/mail-archive/web/roll/current/msg07424.html >>> >>> This ticket has had no significant discussion. Is there an issue >>> here? >>> >>> >>> >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/104 >>> security considerations. >>> We need to have a discussion about what are the implications >>> of this protocol. See next message. >>> >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/105 >>> trickle-mcast: how to determine scope of MPL domain >>> We have several options from Robert Craigie in the ticket system. >>> Alternatives 3 and 4 were discussed, and I think that we preferred >>> option 4 with the multicast option always present. >>> Please post if you disagree. >>> >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/106 >>> trickle-mcast: always use 6in6 encapsulation for non-link-local >>> multicast >>> no clear resolution, but ticket #105 suggests answer. >>> >>> >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/108 >>> trickle-mcast: should there be an explicit version field? >>> suggested answer was YES. >>> >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/107 >>> trickle-mcast: should multiple parameter sets be supported >>> my conclusion: There is has been little discussion about this >>> issue. My inclination is to not include multiple sets at this >>> time. >>> >>> >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/109 >>> trickle-mcast: should all MPL packets be destined to all-MPL-forwarders >>> >>> >>> -- >>> Michael Richardson , Sandelman Software Works >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>> >>> >> > From mcr@sandelman.ca Sun Jan 27 12:37:56 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA29921F85BB for ; Sun, 27 Jan 2013 12:37:56 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ElhkfEXG2atp for ; Sun, 27 Jan 2013 12:37:56 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED3321F8455 for ; Sun, 27 Jan 2013 12:37:56 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id CF1C92016D for ; Sun, 27 Jan 2013 15:43:16 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 2E4A263765; Sun, 27 Jan 2013 15:36:58 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 21E2263761 for ; Sun, 27 Jan 2013 15:36:58 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <003701cdfbe5$1ea7ac00$5bf70400$@olddog.co.uk> References: <20130125201316.22967.26907.idtracker@ietfa.amsl.com> <003701cdfbe5$1ea7ac00$5bf70400$@olddog.co.uk> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Subject: Re: [Roll] FW: New Non-WG Mailing List: 6tsch -- Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 27 Jan 2013 20:37:56 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Adrian" =3D=3D Adrian Farrel writes: Adrian> Please be aware of this new mailing list. Adrian> You now know as much about it as I do :-) >> Purpose: This list is for discussions relating to the >> development, clarification, and implementation of IPv6 access and >> meshing over deterministic (scheduled) MAC with specific interest >> in IEEE 802.15.4e TSCH. Focus is on issues related with time >> slots awareness at L3, time slots allocation and distribution, >> and the eventual mix of centralized and distributed operation for >> routing and resource allocation. The list should facilitate >> exchanges between opensource implementers, share on the >> applicability of the technology and address the gaps in existing >> IETF specs from RPL and 6LoWPAN. This list may steer work at the >> IETF, as well as IEC and ISA. One of the goals for the group, >> should we create one, would be to put together an IETF straw man >> binding existing standards (RPL, 6LoWPAN, PANA, ForCES/OpenFlow, >> diffserv) over 802.15.4e. We had a presentation in Atlanta that I think related to this: okay, so this perhaps relates in part to: http://tools.ietf.org/agenda/85/slides/slides-85-roll-4.pdf and http://datatracker.ietf.org/doc/draft-wei-roll-scheduling-routing/ =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUQWP6oqHRg3pndX9AQLKXwP9Ep3O3tZ38F5cfvQzCCdAmJhMVFBotxhM TnOcPMZGPD8e/FO2mMLpxfCtgF8Tf5MDIhEHowCCXXr8jKWg1jf95kj9NqZxwowD yG5kyB1mTa9oCl2mU0htaPbrNMYhjKhm7d+c/nYYy12/sDh1Anq5ijscpCCMMRjL Q+QWv6GWRUs= =yARy -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Sun Jan 27 12:44:23 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F24CE21F86FA for ; Sun, 27 Jan 2013 12:44:22 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vjd9UDUBd8Hw for ; Sun, 27 Jan 2013 12:44:22 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id 3758A21F86F6 for ; Sun, 27 Jan 2013 12:44:22 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id F3AD52016D; Sun, 27 Jan 2013 15:49:44 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 5658363765; Sun, 27 Jan 2013 15:43:26 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 429EC63761; Sun, 27 Jan 2013 15:43:26 -0500 (EST) From: Michael Richardson To: Abdussalam Baryun In-Reply-To: References: <20130122143937.17324.59444.idtracker@ietfa.amsl.com> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-richardson-roll-applicability-template-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Jan 2013 20:44:23 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Abdussalam" =3D=3D Abdussalam Baryun wr= ites: Abdussalam> I want to discuss some things in this draft-01 if ok. I Abdussalam> see that the draft is empty of explaination. When it was Abdussalam> presented first draft-00, I thought the templet is about Abdussalam> including the main issues and information in all Abdussalam> applicability cases in this one template but now I find Abdussalam> out that it is just sections titles, does this mean that Abdussalam> this draft is like a guide or structure of the Abdussalam> applicability drafts in future. Please advise, That's exactly what it is: a template. =2D-=20 Michael Richardson , Sandelman Software Works=20 IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUQWRboqHRg3pndX9AQIUpAQAjXT4jgoezw6nTHLQmB6kKyiQJvUniTTv fFUs2rYNGFCvhI0MrFbS/OFUgkYdgKBA37L9MdPULoy7sR1ubnX89SsgIiYXNVET o+ceZZJVC3a3/BqkKgtCyFJFFPnqsu5MboUqlb5SSU5RvtV1hxdG7arjyQngKzqF NsL/KN4TWfI= =dCBG -----END PGP SIGNATURE----- --=-=-=-- From abdussalambaryun@gmail.com Mon Jan 28 01:47:22 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E39E21F8206 for ; Mon, 28 Jan 2013 01:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.588 X-Spam-Level: X-Spam-Status: No, score=-3.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ySzK2hkZEVJH for ; Mon, 28 Jan 2013 01:47:22 -0800 (PST) Received: from mail-pb0-f46.google.com (mail-pb0-f46.google.com [209.85.160.46]) by ietfa.amsl.com (Postfix) with ESMTP id F0B1621F8203 for ; Mon, 28 Jan 2013 01:47:21 -0800 (PST) Received: by mail-pb0-f46.google.com with SMTP id mc17so725537pbc.33 for ; Mon, 28 Jan 2013 01:47:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=qJwlked8ZkAlxyXZIAl22XNMWw2AAVa3T3LGChIuL3M=; b=snuaaCpO07fiUKloP222GeXAgsZRcEpFCIw5S02Xa9YVMRcAxbt+dVk8F/CklVeBop dWedEQ5dt5GP7G1IGNqN+EXiXdUWGtiAAB7FgsNGjQnArlvyX/uux0aDi4eEpkQazYIC RNxQriqc04a6K5op4R3sMKWJ6g7Ri8t0OBhTPCJ95qySvbxuIVPXzJRNiU9kkKnueDRg IrDKOqjoEjSeTTAWj7lP09yFaIYiRwaAtK3v77CdZs1VU4cIkN8KQ3MYBkXpOsthGTrh rdq/bwWE/91o+wVu1vJnZoGAECYQ03Mp+0s7LY1GfY9fE0fnrHBIrGulLz7mwSgf9Vvu UKww== MIME-Version: 1.0 X-Received: by 10.68.222.196 with SMTP id qo4mr35840766pbc.140.1359366441485; Mon, 28 Jan 2013 01:47:21 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 28 Jan 2013 01:47:21 -0800 (PST) In-Reply-To: <26881.1359319406@sandelman.ca> References: <20130122143937.17324.59444.idtracker@ietfa.amsl.com> <26881.1359319406@sandelman.ca> Date: Mon, 28 Jan 2013 10:47:21 +0100 Message-ID: From: Abdussalam Baryun To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-richardson-roll-applicability-template-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 09:47:22 -0000 > That's exactly what it is: a template. I got that answer before in last meeting, but didn't understand :) How this template is recommended to be used in ROLL, will it be a rule of writing applicability paragraphs or just informational for better performance? Is this template recommended for only all the applicability drafts, or is general which may include all the WG drafts (included in their applicability section)? AB On 1/27/13, Michael Richardson wrote: > >>>>>> "Abdussalam" == Abdussalam Baryun >>>>>> writes: > Abdussalam> I want to discuss some things in this draft-01 if ok. I > Abdussalam> see that the draft is empty of explaination. When it was > Abdussalam> presented first draft-00, I thought the templet is about > Abdussalam> including the main issues and information in all > Abdussalam> applicability cases in this one template but now I find > Abdussalam> out that it is just sections titles, does this mean that > Abdussalam> this draft is like a guide or structure of the > Abdussalam> applicability drafts in future. Please advise, > > That's exactly what it is: a template. > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > From stokcons@xs4all.nl Mon Jan 28 03:43:27 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC41221F85FE for ; Mon, 28 Jan 2013 03:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.154 X-Spam-Level: X-Spam-Status: No, score=-0.154 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fnw4n-5hI5BQ for ; Mon, 28 Jan 2013 03:43:27 -0800 (PST) Received: from smtp-vbr6.xs4all.nl (smtp-vbr6.xs4all.nl [194.109.24.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2023C21F879A for ; Mon, 28 Jan 2013 03:43:26 -0800 (PST) Received: from roundcube.xs4all.nl (roundcube11.xs4all.net [194.109.20.209]) by smtp-vbr6.xs4all.nl (8.13.8/8.13.8) with ESMTP id r0SBhPDY033120 for ; Mon, 28 Jan 2013 12:43:25 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-228-183.w92-145.abo.wanadoo.fr ([92.145.51.183]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 28 Jan 2013 12:43:25 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 28 Jan 2013 12:43:25 +0100 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> Message-ID: X-Sender: stokcons@xs4all.nl (3EKjPevhuSDKaO3iAP3hI509mPCYSr6G) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: consultancy@vanderstok.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, 28 Jan 2013 11:43:28 -0000 Hi Jonathan and Richard, many thanks for the updated draft. It has enormously improved. In particular I appreciate the way MPL domain is defined and implemented. After a first reading, I do have some questions about the draft. Possibly I misinterpret the text. If I understand correctly a node can be member of several MPL domains and subscribe to as many MPL Domain addresses. Consequently a node can be seed to messages to more than one MPL domain. This implies that a node can receive messages for different MPL domains coming from the same seed? If that is possible (at page 6, sec 4.1) the seed set records and the buffered message records should record information about received MPL data messages received from an MPL seed << for a given MPL-domain. >>. within << xxx >> my addition. section 8 page 17. an MPL forwarder MUST participate in an MPL domain identified by the ALL_MPL_FORWARDERS multicast address with scope value 3 (subnet local) For each MPL domain Address that an MPL interface subscribes to, the MPL interface MUST also subscribe to the same MPL domain address with a scope vaule of 2 (link-local) This implies? << an MPL forwarder MUST participate in an MPL domain identified by the ALL_MPL_FORWARDERS multicast address with scope value 2 (link local)>> page 19 sec 10.1 first bullit: ..... be valid within the MPL Domain (what does that mean?) I thought this could be removed given the text below. when the source address is in the AddressList of an MPL Interface corresponding << substitute with subscribed>> to the MPL ...... section 10.2, page 20, first bullit This document does not define any external "events" Remove of replace document by section, because 11.2 does. section 10.3 page 21 last two bullits discuss Control messages and timers should these not be data messages and their timers? section 11.3 as earlier, should this not be per domain? looking forward to your reaction, peter Jonathan Hui (johui) schreef op 2013-01-24 17:13: > This update addresses all of the open tickets in the following manner: > > Ticket 103: MPL Control Messages may be disabled by setting > CONTROL_MESSAGE_TIMER_EXPIRATIONS to zero. > > Ticket 104: Added security considerations text. > > Ticket 105: Scope is determined by the IPv6 Destination Address of > MPL Data Packet. > > Ticket 106: Text added to always use IPv6-in-IPv6 encapsulation when > multicast destination does not match MPL Domain Address. > > Ticket 107: Multiple parameter sets are not supported at this time. > > Ticket 108: Added explicit 1-bit version field. > > Ticket 109: All MPL packets must be destined to the MPL Domain > Address that identifies the MPL Domain. > > Ticket 110: Not in scope. If an application subscribes to an > address, it should receive all packets destined to that address > whether or not they were received in an MPL Data Packet. > > -- > Jonathan Hui From mcr@sandelman.ca Mon Jan 28 06:55:58 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8689D21F89DA for ; Mon, 28 Jan 2013 06:55:58 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MNOkoY7B4Qta for ; Mon, 28 Jan 2013 06:55:58 -0800 (PST) Received: from tuna.sandelman.ca (unknown [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) by ietfa.amsl.com (Postfix) with ESMTP id DCAA821F8A68 for ; Mon, 28 Jan 2013 06:55:57 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 51AED2016D; Mon, 28 Jan 2013 10:01:23 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id A5BD563765; Mon, 28 Jan 2013 09:55:01 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 94BD6636B6; Mon, 28 Jan 2013 09:55:01 -0500 (EST) From: Michael Richardson To: Abdussalam Baryun In-Reply-To: References: <20130122143937.17324.59444.idtracker@ietfa.amsl.com> <26881.1359319406@sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Cc: roll@ietf.org Subject: Re: [Roll] I-D Action: draft-richardson-roll-applicability-template-01.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 14:55:58 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Abdussalam" =3D=3D Abdussalam Baryun wr= ites: >> That's exactly what it is: a template. Abdussalam> How this template is recommended to be used in ROLL, Abdussalam> will it be a rule of writing applicability paragraphs or Abdussalam> just informational for better performance? People writing applicability statements use this to start their document. Abdussalam> Is this template recommended for only all the Abdussalam> applicability drafts, or is general which may include Abdussalam> all the WG drafts (included in their applicability Abdussalam> section)? No, just applicability documents for applying RFC6550 to use FOO. =2D-=20 ] Never tell me the odds! | ipv6 mesh network= s [=20 ] Michael Richardson, Sandelman Software Works | network architect= [=20 ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [=20 =09 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUQaRRYqHRg3pndX9AQIQlwP+NbsUXB6HXM9eM20RGKc5OFQkNSykSbyJ iK58NU/0/MHdvD6SbmHZ8Fg3utLWhYx6+kavw5T3ZNQWc+4ec4A5WzdayfwVodhl VPRXB8NrFP/B1FFJue8yPbqerKWHkzlPBcwFTE/Rd5rbDgKRVcuwkCHK9q7TJQYD RjXCmkmp9SM= =XsBm -----END PGP SIGNATURE----- --=-=-=-- From johui@cisco.com Mon Jan 28 07:47:35 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBB5B21F8472 for ; Mon, 28 Jan 2013 07:47:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kWJ3I27Q2e5F for ; Mon, 28 Jan 2013 07:47:35 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 3600221F8455 for ; Mon, 28 Jan 2013 07:47:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3455; q=dns/txt; s=iport; t=1359388055; x=1360597655; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YLYv7AyZmq0Ava28dNsV30bYT5NHFh8rQFgntKN2crw=; b=bmgcGk0CrlbmwVgASY8qLzn11f+Cdqs+wpuEcnmVa13HO2Oe6X9zjzQk 9BIpkVStsccazaW0kQXdxy33FOQvH0/JFYyzTGjvKGRGvf6oTkDPqLbdG 59P5/olzbdBDiOA9ygTiveHdP5tQCfxgy0WrllpJg8pbuDgtVTTHUcTVF s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANWcBlGtJXHA/2dsb2JhbABEvlkWc4IeAQEBAwF5BQsCAQgiAiIyJQIEDgUIiAMGv2yQRGEDplWCd4Ik X-IronPort-AV: E=Sophos;i="4.84,551,1355097600"; d="scan'208";a="169273221" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 28 Jan 2013 15:47:34 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0SFlYY6023410 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 15:47:34 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 09:47:34 -0600 From: "Jonathan Hui (johui)" To: "" Thread-Topic: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt Thread-Index: AQHN+k3DZ/iaYoyV7EKQpxikzCRBNQ== Date: Mon, 28 Jan 2013 15:47:33 +0000 Message-ID: References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.2] Content-Type: text/plain; charset="Windows-1252" Content-ID: <20EDAEFC5C99EF4FBACE847832111833@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 15:47:36 -0000 Hi Peter, Thanks for your review. See below: On Jan 28, 2013, at 3:43 AM, peter van der Stok wrote: > many thanks for the updated draft. It has enormously improved. > In particular I appreciate the way MPL domain is defined and implemented. >=20 > After a first reading, I do have some questions about the draft. Possibly= I misinterpret the text. >=20 > If I understand correctly a node can be member of several MPL domains and= subscribe to as many MPL Domain addresses. > Consequently a node can be seed to messages to more than one MPL domain. > This implies that a node can receive messages for different MPL domains c= oming from the same seed? Correct. > If that is possible (at page 6, sec 4.1) the seed set records and the buf= fered message records should record information about received MPL data mes= sages received from an MPL seed << for a given MPL-domain. >>. within << = xxx >> my addition. That is the intent, as Section 9 states: Each MPL Seed maintains a sequence number for each MPL Domain that it serves. I'll be sure to make this more clear in the next revision. > section 8 page 17. >=20 > an MPL forwarder MUST participate in an MPL domain identified by the ALL_= MPL_FORWARDERS multicast address with scope value 3 (subnet local) > For each MPL domain Address that an MPL interface subscribes to, the MPL = interface MUST also subscribe to the same MPL domain address with a scope v= aule of 2 (link-local) >=20 > This implies? > << an MPL forwarder MUST participate in an MPL domain identified by the A= LL_MPL_FORWARDERS multicast address with scope value 2 (link local)>> Correct. The intent here is to make the use of ALL_MPL_FORWARDERS the defa= ult behavior, but not required if you want to use something else. Maybe we= need to have more careful usage of "By default" and "MUST". > page 19 sec 10.1 > first bullit: ..... be valid within the MPL Domain (what does that mean?)= I thought this could be removed given the text below. The Source Address needs to be valid within the scope zone of the MPL Domai= n, otherwise responses to the message (e.g. ICMP errors) cannot be returned= . > when the source address is in the AddressList of an MPL Interface corresp= onding << substitute with subscribed>> to the MPL ...=85 The referenced text is addressing the case when IP-in-IP encapsulation is n= ot needed. The first bullet is intended cover the cases with and without e= ncapsulation. > section 10.2, page 20, first bullit >=20 > This document does not define any external "events" > Remove of replace document by section, because 11.2 does. Section 10.2 specifies Trickle timer rules for MPL Data Messages while Sect= ion 11.2 specifies Trickle timer rules for MPL Control Messages. The forme= r does not define any external events while the latter does. > section 10.3 page 21 > last two bullits discuss Control messages and timers should these not be = data messages and their timers? The rules on page 21 define the interaction between MPL Data Messages and M= PL Control Messages. In particular, these rules define when to start the M= PL Control Message Trickle timer upon receiving an MPL Data Message. > section 11.3 > as earlier, should this not be per domain? Correct. As mentioned above, I will make this more clear in the next revis= ion. -- Jonathan Hui From johui@cisco.com Mon Jan 28 07:51:17 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC04821F87C4 for ; Mon, 28 Jan 2013 07:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TG9PUb2B+wD9 for ; Mon, 28 Jan 2013 07:51:16 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 5257E21F850E for ; Mon, 28 Jan 2013 07:51:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3668; q=dns/txt; s=iport; t=1359388276; x=1360597876; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YRfZnWUgiHddzEj3Lb12YvlImHhhu3x16FLpc7HyOKo=; b=g2EZn41+eLD/n13MRoncOFdoH2Fs1EENNUCGeQADNGVRXXFDzx/xjabu sy1LNLAi/unQGv7NeztLMl5Nm8mpv2q0sSaO81b52tpCNNObxNZqUU74p xBjQWGlN2W8zTMQXueCczbYL08rvLyeNlX6YUvvSFXAuxjnWqX7tSlSX4 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EANWcBlGtJXG+/2dsb2JhbABEvlkWc4IeAQEBAwFwCQULAgEIGAokIRElAgQOBQgBh3YDCQYMtX4NiVWMEIEKAQmDIGEDiCyMC4JyihqFEoJ3gW81 X-IronPort-AV: E=Sophos;i="4.84,551,1355097600"; d="scan'208";a="166239189" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 28 Jan 2013 15:51:15 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0SFpFDe001233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 15:51:15 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 09:51:15 -0600 From: "Jonathan Hui (johui)" To: Abdussalam Baryun Thread-Topic: Discussion/Comments For draft-ietf-roll-trickle-mcast-03 Thread-Index: AQHN/W9NT2fXxKK2sEKFqr+pjlBCPw== Date: Mon, 28 Jan 2013 15:51:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.2] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "richard.kelsey@silabs.com" , roll Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 15:51:17 -0000 While RFC 6206 is particularly concerned about communication over shared me= dia, Trickle is not specific to communication over shared media. -- Jonathan Hui On Jan 25, 2013, at 2:50 PM, Abdussalam Baryun = wrote: > Dear I-D Authors, >=20 > I done a little review so far and need answers to continue, as the > ROLL chair asked for some discussion on our WG draft, which I will try > to do so far. >=20 > I see that the draft's applicability statement does not include > *shared medium*, but the *trickel algorithm* works for shared medium, > which in RFC6206 states that in the abstract. So if this MPL uses > trickel do you think it still will work in a non-shared communication > medium LLN, Please advise? >=20 > otherwise I recommend to add the words as in trickel: *lossy shared mediu= m* > As in the appplicability statement section 3 >=20 > AB> Recommend Amend to> > This protocol is an IPv6 multicast forwarding protocol for nodes in > shared medium within the low-power and lossy network domain. By > implementing a controlled dissemination using the Trickle algorithm, > this protocol is designed for networks that > communicate using low-power and lossy links with widely varying > topologies in both the space and time dimensions. >=20 > AB> question on section 3> I am not sure I understand *the space and > time dimensions*, Do you mean that the topology or multicast-nodes > is/are changing in space, please give me an example use-case? >=20 > Regards >=20 > AB >=20 >>> On 1/22/13, Michael Richardson wrote: >>>=20 >>> http://trac.tools.ietf.org/wg/roll/trac/report/8 >>> contains the list of open tickets. There are some threads >>> linked in each ticket. >>>=20 >>>=20 >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/103 >>> trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS >>> http://www.ietf.org/mail-archive/web/roll/current/msg07424.html >>>=20 >>> This ticket has had no significant discussion. Is there an issue >>> here? >>>=20 >>>=20 >>>=20 >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/104 >>> security considerations. >>> We need to have a discussion about what are the implications >>> of this protocol. See next message. >>>=20 >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/105 >>> trickle-mcast: how to determine scope of MPL domain >>> We have several options from Robert Craigie in the ticket system. >>> Alternatives 3 and 4 were discussed, and I think that we preferred >>> option 4 with the multicast option always present. >>> Please post if you disagree. >>>=20 >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/106 >>> trickle-mcast: always use 6in6 encapsulation for non-link-local multica= st >>> no clear resolution, but ticket #105 suggests answer. >>>=20 >>>=20 >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/108 >>> trickle-mcast: should there be an explicit version field? >>> suggested answer was YES. >>>=20 >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/107 >>> trickle-mcast: should multiple parameter sets be supported >>> my conclusion: There is has been little discussion about this >>> issue. My inclination is to not include multiple sets at this >>> time. >>>=20 >>>=20 >>> http://trac.tools.ietf.org/wg/roll/trac/ticket/109 >>> trickle-mcast: should all MPL packets be destined to all-MPL-forwarders >>>=20 >>>=20 >>> -- >>> Michael Richardson , Sandelman Software Works >>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>>=20 >>>=20 >>=20 From johui@cisco.com Mon Jan 28 07:52:01 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA86721F87C4 for ; Mon, 28 Jan 2013 07:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxXUIT8LBnQ3 for ; Mon, 28 Jan 2013 07:52:01 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 1101B21F87D3 for ; Mon, 28 Jan 2013 07:52:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3910; q=dns/txt; s=iport; t=1359388321; x=1360597921; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=R0Hzvi8kRXf76jDOQd12FhkMv1Gip3oZ0vkenylHwFo=; b=JxCtHNh2MkJ62Di9Nd3Q6FyUg7brN4UDiwvkldYB4yI5Z3SZ20hbd7qj gV0I1DhWY/GS/xLUIOAO6PaHrLiGB4pg079It6rQZgv88G6Szqy7c8PuR YMvnEsSXR1rdp8ksQqaFmTItL91z9drBO8XG/1VMZ4PHPd6fWCBrZ+f/J Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABGeBlGtJV2Z/2dsb2JhbABEvlkWc4IeAQEBAwFwCQULAgEIGAokIRElAgQOBQgBh3YDCQYMtgQNiVWMEIEKAQmDIGEDiCyMC4JyihqFEoJ3gW81 X-IronPort-AV: E=Sophos;i="4.84,551,1355097600"; d="scan'208";a="169235396" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 28 Jan 2013 15:52:00 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0SFq0B6010104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 15:52:00 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 09:52:00 -0600 From: "Jonathan Hui (johui)" To: Abdussalam Baryun Thread-Topic: Discussion/Comments For draft-ietf-roll-trickle-mcast-03 Thread-Index: AQHN/W9oT2fXxKK2sEKFqr+pjlBCPw== Date: Mon, 28 Jan 2013 15:51:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.2] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "richard.kelsey@silabs.com Kelsey" , roll WG Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 15:52:01 -0000 Trickle does not utilize any knowledge of neighboring nodes. -- Jonathan Hui On Jan 26, 2013, at 8:58 AM, Abdussalam Baryun = wrote: > The draft does not clarify how the MPL forwarding knows its neighbors, > or the MPL neighbor is not defined in the doc, please advise, >=20 > AB >=20 > On 1/25/13, Abdussalam Baryun wrote: >> Dear I-D Authors, >>=20 >> I done a little review so far and need answers to continue, as the >> ROLL chair asked for some discussion on our WG draft, which I will try >> to do so far. >>=20 >> I see that the draft's applicability statement does not include >> *shared medium*, but the *trickel algorithm* works for shared medium, >> which in RFC6206 states that in the abstract. So if this MPL uses >> trickel do you think it still will work in a non-shared communication >> medium LLN, Please advise? >>=20 >> otherwise I recommend to add the words as in trickel: *lossy shared medi= um* >> As in the appplicability statement section 3 >>=20 >> AB> Recommend Amend to> >> This protocol is an IPv6 multicast forwarding protocol for nodes in >> shared medium within the low-power and lossy network domain. By >> implementing a controlled dissemination using the Trickle algorithm, >> this protocol is designed for networks that >> communicate using low-power and lossy links with widely varying >> topologies in both the space and time dimensions. >>=20 >> AB> question on section 3> I am not sure I understand *the space and >> time dimensions*, Do you mean that the topology or multicast-nodes >> is/are changing in space, please give me an example use-case? >>=20 >> Regards >>=20 >> AB >>=20 >>>> On 1/22/13, Michael Richardson wrote: >>>>=20 >>>> http://trac.tools.ietf.org/wg/roll/trac/report/8 >>>> contains the list of open tickets. There are some threads >>>> linked in each ticket. >>>>=20 >>>>=20 >>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/103 >>>> trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS >>>> http://www.ietf.org/mail-archive/web/roll/current/msg07424.html >>>>=20 >>>> This ticket has had no significant discussion. Is there an issue >>>> here? >>>>=20 >>>>=20 >>>>=20 >>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/104 >>>> security considerations. >>>> We need to have a discussion about what are the implications >>>> of this protocol. See next message. >>>>=20 >>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/105 >>>> trickle-mcast: how to determine scope of MPL domain >>>> We have several options from Robert Craigie in the ticket system. >>>> Alternatives 3 and 4 were discussed, and I think that we preferred >>>> option 4 with the multicast option always present. >>>> Please post if you disagree. >>>>=20 >>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/106 >>>> trickle-mcast: always use 6in6 encapsulation for non-link-local >>>> multicast >>>> no clear resolution, but ticket #105 suggests answer. >>>>=20 >>>>=20 >>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/108 >>>> trickle-mcast: should there be an explicit version field? >>>> suggested answer was YES. >>>>=20 >>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/107 >>>> trickle-mcast: should multiple parameter sets be supported >>>> my conclusion: There is has been little discussion about this >>>> issue. My inclination is to not include multiple sets at this >>>> time. >>>>=20 >>>>=20 >>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/109 >>>> trickle-mcast: should all MPL packets be destined to all-MPL-forwarder= s >>>>=20 >>>>=20 >>>> -- >>>> Michael Richardson , Sandelman Software Works >>>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>>>=20 >>>>=20 >>>=20 >>=20 From abdussalambaryun@gmail.com Mon Jan 28 08:21:48 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBC9E21F88B9 for ; Mon, 28 Jan 2013 08:21:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wGhk81F7umoM for ; Mon, 28 Jan 2013 08:21:48 -0800 (PST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1E621F8930 for ; Mon, 28 Jan 2013 08:21:47 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id kp14so1607463pab.33 for ; Mon, 28 Jan 2013 08:21:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=122TKCW6b541mwfJUaCFNTUmdpnIvpxQ4E74ChbQwSM=; b=BpctsVPEf2K9GY7nc+VVuntYBKnPKSQYKtKhBmA42i471AbqXRL3YWwEkFxhy/1LAS k+WUXhPHQrB1C0wqWgEVoZZ8fKEFhQOeU6KA1pALF006zfXp4L/0SHfsr4SMVkk3sOD5 8pgfFvyWEIMCqRJU2lPb8hiIYmVmAfCt4qfyXnBKm9DU1Q2RlRGil4+vwVdCStA1EJ+e Ll0SgLvf5cIMSajrBsSDDQIzC5mSjnxMR0mG29YDZ26ciT3rGBj1QfzF4R3iQ+onu9LZ FhVQlZEsmMa5wLa6qIlzfGLkKClY/BovyqcqQtEjEaC63XS8Hdn8oWz7DSMnKkxIbefb 8ExQ== MIME-Version: 1.0 X-Received: by 10.68.222.196 with SMTP id qo4mr38562986pbc.140.1359390100835; Mon, 28 Jan 2013 08:21:40 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 28 Jan 2013 08:21:40 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Jan 2013 17:21:40 +0100 Message-ID: From: Abdussalam Baryun To: "Jonathan Hui (johui)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "richard.kelsey@silabs.com" , roll Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:21:49 -0000 Hi Jonathan so do you mean the MPL is for both shared and non shared mediums, and using Trickel for the mulicast purpose AB On 1/28/13, Jonathan Hui (johui) wrote: > > While RFC 6206 is particularly concerned about communication over shared > media, Trickle is not specific to communication over shared media. > > -- > Jonathan Hui > > On Jan 25, 2013, at 2:50 PM, Abdussalam Baryun > wrote: > >> Dear I-D Authors, >> >> I done a little review so far and need answers to continue, as the >> ROLL chair asked for some discussion on our WG draft, which I will try >> to do so far. >> >> I see that the draft's applicability statement does not include >> *shared medium*, but the *trickel algorithm* works for shared medium, >> which in RFC6206 states that in the abstract. So if this MPL uses >> trickel do you think it still will work in a non-shared communication >> medium LLN, Please advise? >> >> otherwise I recommend to add the words as in trickel: *lossy shared >> medium* >> As in the appplicability statement section 3 >> >> AB> Recommend Amend to> >> This protocol is an IPv6 multicast forwarding protocol for nodes in >> shared medium within the low-power and lossy network domain. By >> implementing a controlled dissemination using the Trickle algorithm, >> this protocol is designed for networks that >> communicate using low-power and lossy links with widely varying >> topologies in both the space and time dimensions. >> >> AB> question on section 3> I am not sure I understand *the space and >> time dimensions*, Do you mean that the topology or multicast-nodes >> is/are changing in space, please give me an example use-case? >> >> Regards >> >> AB >> >>>> On 1/22/13, Michael Richardson wrote: >>>> >>>> http://trac.tools.ietf.org/wg/roll/trac/report/8 >>>> contains the list of open tickets. There are some threads >>>> linked in each ticket. >>>> >>>> >>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/103 >>>> trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS >>>> http://www.ietf.org/mail-archive/web/roll/current/msg07424.html >>>> >>>> This ticket has had no significant discussion. Is there an issue >>>> here? >>>> >>>> >>>> >>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/104 >>>> security considerations. >>>> We need to have a discussion about what are the implications >>>> of this protocol. See next message. >>>> >>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/105 >>>> trickle-mcast: how to determine scope of MPL domain >>>> We have several options from Robert Craigie in the ticket system. >>>> Alternatives 3 and 4 were discussed, and I think that we preferred >>>> option 4 with the multicast option always present. >>>> Please post if you disagree. >>>> >>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/106 >>>> trickle-mcast: always use 6in6 encapsulation for non-link-local >>>> multicast >>>> no clear resolution, but ticket #105 suggests answer. >>>> >>>> >>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/108 >>>> trickle-mcast: should there be an explicit version field? >>>> suggested answer was YES. >>>> >>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/107 >>>> trickle-mcast: should multiple parameter sets be supported >>>> my conclusion: There is has been little discussion about this >>>> issue. My inclination is to not include multiple sets at this >>>> time. >>>> >>>> >>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/109 >>>> trickle-mcast: should all MPL packets be destined to all-MPL-forwarders >>>> >>>> >>>> -- >>>> Michael Richardson , Sandelman Software Works >>>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>>> >>>> >>> > > From abdussalambaryun@gmail.com Mon Jan 28 08:24:09 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1010921F8717 for ; Mon, 28 Jan 2013 08:24:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uRc44LPuXziH for ; Mon, 28 Jan 2013 08:24:08 -0800 (PST) Received: from mail-da0-f50.google.com (mail-da0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id 6416321F8573 for ; Mon, 28 Jan 2013 08:24:08 -0800 (PST) Received: by mail-da0-f50.google.com with SMTP id h15so1318127dan.37 for ; Mon, 28 Jan 2013 08:24:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=iTK5Qhjv3gG29C+auv+we77WHHqSA7Hxc5P8e0vyhw4=; b=OJju8YpDV7gztxGi9wb8ZIy7KCsIaUm+c+5nW89GhkhV5yNiSAlRVbdvOW0mYgIm3F iDLPr6CBRQvbywrHSnqsbWhan51UG2JSn497nIJell1i8b9Q5gDwZ9U6x0LS1Fsq9WVp IeJPbS435JlFqwB0b/UCA17oEokINwrttNPJ3SbeklJ7GEtabQHprUZcO30/OgFP7ykx WRKdGczmP4WswwZIOkjEDapwzZTJ8bwTYT9dWStBeo0C6hW1NMxS3nGyGIc8q2cvhV5c 9y/KSEQiydXtR0Tj+3u6gtEu7K3aK1eGFw1KmnqH/x0K4e/ts7cMp7a3J+oAiikGjWZd YlDg== MIME-Version: 1.0 X-Received: by 10.68.227.33 with SMTP id rx1mr39406334pbc.67.1359390248071; Mon, 28 Jan 2013 08:24:08 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 28 Jan 2013 08:24:07 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Jan 2013 17:24:07 +0100 Message-ID: From: Abdussalam Baryun To: "Jonathan Hui (johui)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "richard.kelsey@silabs.com Kelsey" , roll WG Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:24:09 -0000 Hi Jonathan, Why MPL forwarder have no knowledge of neighbors, then how does it forward to other forwarders, AB On 1/28/13, Jonathan Hui (johui) wrote: > > Trickle does not utilize any knowledge of neighboring nodes. > > -- > Jonathan Hui > > On Jan 26, 2013, at 8:58 AM, Abdussalam Baryun > wrote: > >> The draft does not clarify how the MPL forwarding knows its neighbors, >> or the MPL neighbor is not defined in the doc, please advise, >> >> AB >> >> On 1/25/13, Abdussalam Baryun wrote: >>> Dear I-D Authors, >>> >>> I done a little review so far and need answers to continue, as the >>> ROLL chair asked for some discussion on our WG draft, which I will try >>> to do so far. >>> >>> I see that the draft's applicability statement does not include >>> *shared medium*, but the *trickel algorithm* works for shared medium, >>> which in RFC6206 states that in the abstract. So if this MPL uses >>> trickel do you think it still will work in a non-shared communication >>> medium LLN, Please advise? >>> >>> otherwise I recommend to add the words as in trickel: *lossy shared >>> medium* >>> As in the appplicability statement section 3 >>> >>> AB> Recommend Amend to> >>> This protocol is an IPv6 multicast forwarding protocol for nodes in >>> shared medium within the low-power and lossy network domain. By >>> implementing a controlled dissemination using the Trickle algorithm, >>> this protocol is designed for networks that >>> communicate using low-power and lossy links with widely varying >>> topologies in both the space and time dimensions. >>> >>> AB> question on section 3> I am not sure I understand *the space and >>> time dimensions*, Do you mean that the topology or multicast-nodes >>> is/are changing in space, please give me an example use-case? >>> >>> Regards >>> >>> AB >>> >>>>> On 1/22/13, Michael Richardson wrote: >>>>> >>>>> http://trac.tools.ietf.org/wg/roll/trac/report/8 >>>>> contains the list of open tickets. There are some threads >>>>> linked in each ticket. >>>>> >>>>> >>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/103 >>>>> trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS >>>>> http://www.ietf.org/mail-archive/web/roll/current/msg07424.html >>>>> >>>>> This ticket has had no significant discussion. Is there an issue >>>>> here? >>>>> >>>>> >>>>> >>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/104 >>>>> security considerations. >>>>> We need to have a discussion about what are the implications >>>>> of this protocol. See next message. >>>>> >>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/105 >>>>> trickle-mcast: how to determine scope of MPL domain >>>>> We have several options from Robert Craigie in the ticket system. >>>>> Alternatives 3 and 4 were discussed, and I think that we preferred >>>>> option 4 with the multicast option always present. >>>>> Please post if you disagree. >>>>> >>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/106 >>>>> trickle-mcast: always use 6in6 encapsulation for non-link-local >>>>> multicast >>>>> no clear resolution, but ticket #105 suggests answer. >>>>> >>>>> >>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/108 >>>>> trickle-mcast: should there be an explicit version field? >>>>> suggested answer was YES. >>>>> >>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/107 >>>>> trickle-mcast: should multiple parameter sets be supported >>>>> my conclusion: There is has been little discussion about this >>>>> issue. My inclination is to not include multiple sets at this >>>>> time. >>>>> >>>>> >>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/109 >>>>> trickle-mcast: should all MPL packets be destined to >>>>> all-MPL-forwarders >>>>> >>>>> >>>>> -- >>>>> Michael Richardson , Sandelman Software Works >>>>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >>>>> >>>>> >>>> >>> > > From johui@cisco.com Mon Jan 28 08:33:47 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0677121F87D3 for ; Mon, 28 Jan 2013 08:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c6mwbalO2Kpc for ; Mon, 28 Jan 2013 08:33:45 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 9885121F87C4 for ; Mon, 28 Jan 2013 08:33:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4402; q=dns/txt; s=iport; t=1359390825; x=1360600425; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=HvO427saq8hA042BF7OYU0dkuPPEG956Iyn0JrrPuKs=; b=h+H1MIGvEliDGagl/i545mtPQoSL4bpoWXlxjsBlyCe456gWieGYwz3Y 0X7unvCRCB/vcgO0WPU++frHn4K+LoDFcXHa1CdX/sSffPbWWIWWO5bjo 1fxMaqbbrEubCPaqhs271LOH7K08dYzGeAY0E1YIh+robFRoWlsWB4XWe Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EACenBlGtJXG8/2dsb2JhbABEvlMWc4IeAQEBAwFwCQULAgEIGAokIRElAgQOBQgBh3YDCQYMthENiVWMEIEEBgEJgyBhA4gsjAuCcooahRKCd4FmCRce X-IronPort-AV: E=Sophos;i="4.84,551,1355097600"; d="scan'208";a="169299416" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 28 Jan 2013 16:33:45 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0SGXjXA023675 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 16:33:45 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 10:33:44 -0600 From: "Jonathan Hui (johui)" To: Abdussalam Baryun Thread-Topic: Discussion/Comments For draft-ietf-roll-trickle-mcast-03 Thread-Index: AQHN/W9NT2fXxKK2sEKFqr+pjlBCPw== Date: Mon, 28 Jan 2013 16:33:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.2] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "richard.kelsey@silabs.com Kelsey" , roll WG Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:33:47 -0000 MPL targets LLNs (as the L in MPL indicates). Today's LLNs typically commu= nicate over shared media, but I don't see any reason why LLNs (and MPL) sho= uld be limited to shared media. -- Jonathan Hui On Jan 28, 2013, at 8:21 AM, Abdussalam Baryun = wrote: > Hi Jonathan >=20 > so do you mean the MPL is for both shared and non shared mediums, and > using Trickel for the mulicast purpose >=20 > AB >=20 > On 1/28/13, Jonathan Hui (johui) wrote: >>=20 >> While RFC 6206 is particularly concerned about communication over shared >> media, Trickle is not specific to communication over shared media. >>=20 >> -- >> Jonathan Hui >>=20 >> On Jan 25, 2013, at 2:50 PM, Abdussalam Baryun >> wrote: >>=20 >>> Dear I-D Authors, >>>=20 >>> I done a little review so far and need answers to continue, as the >>> ROLL chair asked for some discussion on our WG draft, which I will try >>> to do so far. >>>=20 >>> I see that the draft's applicability statement does not include >>> *shared medium*, but the *trickel algorithm* works for shared medium, >>> which in RFC6206 states that in the abstract. So if this MPL uses >>> trickel do you think it still will work in a non-shared communication >>> medium LLN, Please advise? >>>=20 >>> otherwise I recommend to add the words as in trickel: *lossy shared >>> medium* >>> As in the appplicability statement section 3 >>>=20 >>> AB> Recommend Amend to> >>> This protocol is an IPv6 multicast forwarding protocol for nodes in >>> shared medium within the low-power and lossy network domain. By >>> implementing a controlled dissemination using the Trickle algorithm, >>> this protocol is designed for networks that >>> communicate using low-power and lossy links with widely varying >>> topologies in both the space and time dimensions. >>>=20 >>> AB> question on section 3> I am not sure I understand *the space and >>> time dimensions*, Do you mean that the topology or multicast-nodes >>> is/are changing in space, please give me an example use-case? >>>=20 >>> Regards >>>=20 >>> AB >>>=20 >>>>> On 1/22/13, Michael Richardson wrote: >>>>>=20 >>>>> http://trac.tools.ietf.org/wg/roll/trac/report/8 >>>>> contains the list of open tickets. There are some threads >>>>> linked in each ticket. >>>>>=20 >>>>>=20 >>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/103 >>>>> trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS >>>>> http://www.ietf.org/mail-archive/web/roll/current/msg07424.html >>>>>=20 >>>>> This ticket has had no significant discussion. Is there an issue >>>>> here? >>>>>=20 >>>>>=20 >>>>>=20 >>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/104 >>>>> security considerations. >>>>> We need to have a discussion about what are the implications >>>>> of this protocol. See next message. >>>>>=20 >>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/105 >>>>> trickle-mcast: how to determine scope of MPL domain >>>>> We have several options from Robert Craigie in the ticket system. >>>>> Alternatives 3 and 4 were discussed, and I think that we preferred >>>>> option 4 with the multicast option always present. >>>>> Please post if you disagree. >>>>>=20 >>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/106 >>>>> trickle-mcast: always use 6in6 encapsulation for non-link-local >>>>> multicast >>>>> no clear resolution, but ticket #105 suggests answer. >>>>>=20 >>>>>=20 >>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/108 >>>>> trickle-mcast: should there be an explicit version field? >>>>> suggested answer was YES. >>>>>=20 >>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/107 >>>>> trickle-mcast: should multiple parameter sets be supported >>>>> my conclusion: There is has been little discussion about this >>>>> issue. My inclination is to not include multiple sets at this >>>>> time. >>>>>=20 >>>>>=20 >>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/109 >>>>> trickle-mcast: should all MPL packets be destined to all-MPL-forwarde= rs >>>>>=20 >>>>>=20 >>>>> -- >>>>> Michael Richardson , Sandelman Software Works >>>>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter= / >>>>>=20 >>>>>=20 >>>>=20 >>=20 >>=20 From johui@cisco.com Mon Jan 28 08:34:45 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 429BC21F87D3 for ; Mon, 28 Jan 2013 08:34:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akm71a+1Y+sc for ; Mon, 28 Jan 2013 08:34:44 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 690F521F87C4 for ; Mon, 28 Jan 2013 08:34:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4481; q=dns/txt; s=iport; t=1359390878; x=1360600478; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=IqAQWzo0fQlx7HwX85rjjlapzaGBejO/ZRrEmTtD0m0=; b=WQFi9Sxc6+actnXXpTawEBUZSSA+GVexL91j1r7As/TlwBhdma0YUeab cibY3eYCmY9lnEnhKfjbLgkzdBcZCmpClNxMDDDFQ0aFgf/CotJdeMYcF cYzX6f3goKPwzl4kvC/s+DmbfuRwCVh+fRikmkXmTJCiLrVdXipoyMHYO Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABCoBlGtJV2c/2dsb2JhbABEvlMWc4IeAQEBAwFwCQULAgEIGAokIRElAgQOBQgBh3YDCQYMthINiVWMEIEKAQmDIGEDiCyMC4JyihqFEoJ3gW81 X-IronPort-AV: E=Sophos;i="4.84,551,1355097600"; d="scan'208";a="169265166" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-5.cisco.com with ESMTP; 28 Jan 2013 16:34:38 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r0SGYbU3029151 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 16:34:37 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 10:34:36 -0600 From: "Jonathan Hui (johui)" To: Abdussalam Baryun Thread-Topic: Discussion/Comments For draft-ietf-roll-trickle-mcast-03 Thread-Index: AQHN/W9oT2fXxKK2sEKFqr+pjlBCPw== Date: Mon, 28 Jan 2013 16:34:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.2] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "richard.kelsey@silabs.com Kelsey" , roll WG Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:34:45 -0000 MPL uses multicast. -- Jonathan Hui On Jan 28, 2013, at 8:24 AM, Abdussalam Baryun = wrote: > Hi Jonathan, >=20 > Why MPL forwarder have no knowledge of neighbors, then how does it > forward to other forwarders, >=20 > AB >=20 > On 1/28/13, Jonathan Hui (johui) wrote: >>=20 >> Trickle does not utilize any knowledge of neighboring nodes. >>=20 >> -- >> Jonathan Hui >>=20 >> On Jan 26, 2013, at 8:58 AM, Abdussalam Baryun >> wrote: >>=20 >>> The draft does not clarify how the MPL forwarding knows its neighbors, >>> or the MPL neighbor is not defined in the doc, please advise, >>>=20 >>> AB >>>=20 >>> On 1/25/13, Abdussalam Baryun wrote: >>>> Dear I-D Authors, >>>>=20 >>>> I done a little review so far and need answers to continue, as the >>>> ROLL chair asked for some discussion on our WG draft, which I will try >>>> to do so far. >>>>=20 >>>> I see that the draft's applicability statement does not include >>>> *shared medium*, but the *trickel algorithm* works for shared medium, >>>> which in RFC6206 states that in the abstract. So if this MPL uses >>>> trickel do you think it still will work in a non-shared communication >>>> medium LLN, Please advise? >>>>=20 >>>> otherwise I recommend to add the words as in trickel: *lossy shared >>>> medium* >>>> As in the appplicability statement section 3 >>>>=20 >>>> AB> Recommend Amend to> >>>> This protocol is an IPv6 multicast forwarding protocol for nodes in >>>> shared medium within the low-power and lossy network domain. By >>>> implementing a controlled dissemination using the Trickle algorithm, >>>> this protocol is designed for networks that >>>> communicate using low-power and lossy links with widely varying >>>> topologies in both the space and time dimensions. >>>>=20 >>>> AB> question on section 3> I am not sure I understand *the space and >>>> time dimensions*, Do you mean that the topology or multicast-nodes >>>> is/are changing in space, please give me an example use-case? >>>>=20 >>>> Regards >>>>=20 >>>> AB >>>>=20 >>>>>> On 1/22/13, Michael Richardson wrote: >>>>>>=20 >>>>>> http://trac.tools.ietf.org/wg/roll/trac/report/8 >>>>>> contains the list of open tickets. There are some threads >>>>>> linked in each ticket. >>>>>>=20 >>>>>>=20 >>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/103 >>>>>> trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATION= S >>>>>> http://www.ietf.org/mail-archive/web/roll/current/msg07424.html >>>>>>=20 >>>>>> This ticket has had no significant discussion. Is there an issue >>>>>> here? >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/104 >>>>>> security considerations. >>>>>> We need to have a discussion about what are the implications >>>>>> of this protocol. See next message. >>>>>>=20 >>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/105 >>>>>> trickle-mcast: how to determine scope of MPL domain >>>>>> We have several options from Robert Craigie in the ticket system. >>>>>> Alternatives 3 and 4 were discussed, and I think that we preferred >>>>>> option 4 with the multicast option always present. >>>>>> Please post if you disagree. >>>>>>=20 >>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/106 >>>>>> trickle-mcast: always use 6in6 encapsulation for non-link-local >>>>>> multicast >>>>>> no clear resolution, but ticket #105 suggests answer. >>>>>>=20 >>>>>>=20 >>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/108 >>>>>> trickle-mcast: should there be an explicit version field? >>>>>> suggested answer was YES. >>>>>>=20 >>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/107 >>>>>> trickle-mcast: should multiple parameter sets be supported >>>>>> my conclusion: There is has been little discussion about this >>>>>> issue. My inclination is to not include multiple sets at this >>>>>> time. >>>>>>=20 >>>>>>=20 >>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/109 >>>>>> trickle-mcast: should all MPL packets be destined to >>>>>> all-MPL-forwarders >>>>>>=20 >>>>>>=20 >>>>>> -- >>>>>> Michael Richardson , Sandelman Software Works >>>>>> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charte= r/ >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>=20 >>=20 From abdussalambaryun@gmail.com Mon Jan 28 08:38:33 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A17621F8915 for ; Mon, 28 Jan 2013 08:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7JinbmpHvIx for ; Mon, 28 Jan 2013 08:38:32 -0800 (PST) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB6B21F8901 for ; Mon, 28 Jan 2013 08:38:32 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id fb10so1625712pad.30 for ; Mon, 28 Jan 2013 08:38:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ZFa5W56Cff+Iv1vpe/Ikpktoo1wCXKrOPOSVKSQlMn4=; b=RMpNtF0Mjs4JpNzRHHq3sgOMmYFdxW2SlgwZkCQGVI2ilhJQx7IBAo13e767O5AgCW se/Ko2acY0zgQXR9U0VQTvPc7rFyaOxPzqi4HgAwzLxLM0U8VzJ8+6MUH70FCV9xlzLw ABFYofp+CmBUmgF/Q4iP+1aiysCr3TI839QA/sLU8xF/IygghoGElHyZkT27m4V/sQtY 9So6F/S6XIZUjtLAwnxbPb1BkRwGMXf3UlFV4/396DOi67dZgDTpt5yJGrNsSaGehMpz 8YnTPX9lg1GR7Voy5zBc/KINYjwnzXs4agOqeewRkSwjAqp6Hw50QtibauCPtSE5dW5F b0Hw== MIME-Version: 1.0 X-Received: by 10.68.222.196 with SMTP id qo4mr38686673pbc.140.1359391112055; Mon, 28 Jan 2013 08:38:32 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 28 Jan 2013 08:38:31 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Jan 2013 17:38:31 +0100 Message-ID: From: Abdussalam Baryun To: "Jonathan Hui (johui)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "richard.kelsey@silabs.com Kelsey" , roll WG Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:38:33 -0000 I don't mean to mix between the network and protocol. This MPL does it use both work for shared medium and non-shared medium. Does its forwarding functions can work for both or not, this is my concerns not concerned about the LLNs? AB On 1/28/13, Jonathan Hui (johui) wrote: > > MPL targets LLNs (as the L in MPL indicates). Today's LLNs typically > communicate over shared media, but I don't see any reason why LLNs (and MPL) > should be limited to shared media. > > -- > Jonathan Hui > > On Jan 28, 2013, at 8:21 AM, Abdussalam Baryun > wrote: > >> Hi Jonathan >> >> so do you mean the MPL is for both shared and non shared mediums, and >> using Trickel for the mulicast purpose >> >> AB >> >> On 1/28/13, Jonathan Hui (johui) wrote: >>> >>> While RFC 6206 is particularly concerned about communication over shared >>> media, Trickle is not specific to communication over shared media. >>> >>> -- >>> Jonathan Hui >>> >>> On Jan 25, 2013, at 2:50 PM, Abdussalam Baryun >>> >>> wrote: >>> >>>> Dear I-D Authors, >>>> >>>> I done a little review so far and need answers to continue, as the >>>> ROLL chair asked for some discussion on our WG draft, which I will try >>>> to do so far. >>>> >>>> I see that the draft's applicability statement does not include >>>> *shared medium*, but the *trickel algorithm* works for shared medium, >>>> which in RFC6206 states that in the abstract. So if this MPL uses >>>> trickel do you think it still will work in a non-shared communication >>>> medium LLN, Please advise? >>>> >>>> otherwise I recommend to add the words as in trickel: *lossy shared >>>> medium* >>>> As in the appplicability statement section 3 >>>> >>>> AB> Recommend Amend to> >>>> This protocol is an IPv6 multicast forwarding protocol for nodes in >>>> shared medium within the low-power and lossy network domain. By >>>> implementing a controlled dissemination using the Trickle algorithm, >>>> this protocol is designed for networks that >>>> communicate using low-power and lossy links with widely varying >>>> topologies in both the space and time dimensions. >>>> >>>> AB> question on section 3> I am not sure I understand *the space and >>>> time dimensions*, Do you mean that the topology or multicast-nodes >>>> is/are changing in space, please give me an example use-case? >>>> >>>> Regards >>>> >>>> AB >>>> >>>>>> On 1/22/13, Michael Richardson wrote: >>>>>> >>>>>> http://trac.tools.ietf.org/wg/roll/trac/report/8 >>>>>> contains the list of open tickets. There are some threads >>>>>> linked in each ticket. >>>>>> >>>>>> >>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/103 >>>>>> trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIONS >>>>>> http://www.ietf.org/mail-archive/web/roll/current/msg07424.html >>>>>> >>>>>> This ticket has had no significant discussion. Is there an issue >>>>>> here? >>>>>> >>>>>> >>>>>> >>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/104 >>>>>> security considerations. >>>>>> We need to have a discussion about what are the implications >>>>>> of this protocol. See next message. >>>>>> >>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/105 >>>>>> trickle-mcast: how to determine scope of MPL domain >>>>>> We have several options from Robert Craigie in the ticket system. >>>>>> Alternatives 3 and 4 were discussed, and I think that we preferred >>>>>> option 4 with the multicast option always present. >>>>>> Please post if you disagree. >>>>>> >>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/106 >>>>>> trickle-mcast: always use 6in6 encapsulation for non-link-local >>>>>> multicast >>>>>> no clear resolution, but ticket #105 suggests answer. >>>>>> >>>>>> >>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/108 >>>>>> trickle-mcast: should there be an explicit version field? >>>>>> suggested answer was YES. >>>>>> >>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/107 >>>>>> trickle-mcast: should multiple parameter sets be supported >>>>>> my conclusion: There is has been little discussion about this >>>>>> issue. My inclination is to not include multiple sets at this >>>>>> time. >>>>>> >>>>>> >>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/109 >>>>>> trickle-mcast: should all MPL packets be destined to >>>>>> all-MPL-forwarders >>>>>> >>>>>> >>>>>> -- >>>>>> Michael Richardson , Sandelman Software Works >>>>>> IETF ROLL WG co-chair. >>>>>> http://datatracker.ietf.org/wg/roll/charter/ >>>>>> >>>>>> >>>>> >>> >>> > > From abdussalambaryun@gmail.com Mon Jan 28 08:45:34 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E18E21F89B9 for ; Mon, 28 Jan 2013 08:45:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pBdxRXZVeFev for ; Mon, 28 Jan 2013 08:45:34 -0800 (PST) Received: from mail-pb0-f47.google.com (mail-pb0-f47.google.com [209.85.160.47]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA7221F891D for ; Mon, 28 Jan 2013 08:45:34 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id rp8so807017pbb.34 for ; Mon, 28 Jan 2013 08:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=kXAl7lyX3vsdkAM48TY/3sfl6fm9dyy/mKI+Ekpv6Dg=; b=pXoGzZ0rvsYwcuel8hVKdOH3pkKZLYzmHnfkm2PzQZwX662aEMUlsEUuiHmf2DPxFT PibAf8/FEd0akjR1eDutEobV61VYi/qmEfzwFc1hMnI5UYQOfjnNucetzLtD/Jv37XJ1 7uc9DxCjjcSI4DxeGWdDNkjzCGm3ILrA3uqn/2HigtyZrGSjPF02e0HLmoIajAJ76Aji /zrQEdQbvohdudZFVwJHpdiJ6MwhKNUoM+5YfpKnDxiI/HzwTJjJg7CCIEThYskFpSrB luTJyQrIq2X6iQmukULH0xqe64T0DikopwqvvAcFKs8JJHWrWS9TvH0t79ywrokgBL8T qvAg== MIME-Version: 1.0 X-Received: by 10.68.136.132 with SMTP id qa4mr38430184pbb.166.1359391533930; Mon, 28 Jan 2013 08:45:33 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 28 Jan 2013 08:45:33 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Jan 2013 17:45:33 +0100 Message-ID: From: Abdussalam Baryun To: "Jonathan Hui (johui)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "richard.kelsey@silabs.com Kelsey" , roll WG Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:45:34 -0000 On 1/28/13, Jonathan Hui (johui) wrote: > > MPL uses multicast. Do you mean; MPL uses IP multicast? I understand that the MPL is already the multicast protocol for our network, I thought that MPL does not need to use IP multicast. I may misunderstood, please advise, AB From johui@cisco.com Mon Jan 28 08:46:52 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E85221F891D for ; Mon, 28 Jan 2013 08:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 53vwTt8xeCE6 for ; Mon, 28 Jan 2013 08:46:50 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB3F21F88B9 for ; Mon, 28 Jan 2013 08:46:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5322; q=dns/txt; s=iport; t=1359391610; x=1360601210; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UKeQBftfmT1PzfbXhQNXvbPI6sNLKhEAQOMB7dS4Dos=; b=exXmyusg0tFrkuHpkLaEOUZktVtWr2rT9hqxX7gKyANSJqTb1HUDrxct q2AZXEDLfvt8E0mDmGXgBdgR7gnEFj5LY4F/xZ+fBY9Euy7pDTgr/+as4 heImWK+4LJxCx92GOAdJEn46Va/4/6tmtGZK/VQ87Xepn88UfKB/kFPV+ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFADerBlGtJV2a/2dsb2JhbABEvlQWc4IeAQEBAwEBAQE3NAIJBQsCAQgYChQQIQYLJQIEDgUIAYd2AwkGDLYZDYlVjBCBBAYBCYMgYQOUN4JyihqFEoJ3gWYJFx4 X-IronPort-AV: E=Sophos;i="4.84,553,1355097600"; d="scan'208";a="169273184" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-5.cisco.com with ESMTP; 28 Jan 2013 16:46:50 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0SGkoa6031968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 16:46:50 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 10:46:49 -0600 From: "Jonathan Hui (johui)" To: Abdussalam Baryun Thread-Topic: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 Thread-Index: AQHN/W9NT2fXxKK2sEKFqr+pjlBCPw== Date: Mon, 28 Jan 2013 16:46:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.2] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "richard.kelsey@silabs.com Kelsey" , roll WG Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:46:52 -0000 Yes, MPL will work for both shared and non-shared media. -- Jonathan Hui On Jan 28, 2013, at 8:38 AM, Abdussalam Baryun = wrote: > I don't mean to mix between the network and protocol. This MPL does it > use both work for shared medium and non-shared medium. Does its > forwarding functions can work for both or not, this is my concerns not > concerned about the LLNs? >=20 > AB >=20 > On 1/28/13, Jonathan Hui (johui) wrote: >>=20 >> MPL targets LLNs (as the L in MPL indicates). Today's LLNs typically >> communicate over shared media, but I don't see any reason why LLNs (and = MPL) >> should be limited to shared media. >>=20 >> -- >> Jonathan Hui >>=20 >> On Jan 28, 2013, at 8:21 AM, Abdussalam Baryun >> wrote: >>=20 >>> Hi Jonathan >>>=20 >>> so do you mean the MPL is for both shared and non shared mediums, and >>> using Trickel for the mulicast purpose >>>=20 >>> AB >>>=20 >>> On 1/28/13, Jonathan Hui (johui) wrote: >>>>=20 >>>> While RFC 6206 is particularly concerned about communication over shar= ed >>>> media, Trickle is not specific to communication over shared media. >>>>=20 >>>> -- >>>> Jonathan Hui >>>>=20 >>>> On Jan 25, 2013, at 2:50 PM, Abdussalam Baryun >>>> >>>> wrote: >>>>=20 >>>>> Dear I-D Authors, >>>>>=20 >>>>> I done a little review so far and need answers to continue, as the >>>>> ROLL chair asked for some discussion on our WG draft, which I will tr= y >>>>> to do so far. >>>>>=20 >>>>> I see that the draft's applicability statement does not include >>>>> *shared medium*, but the *trickel algorithm* works for shared medium, >>>>> which in RFC6206 states that in the abstract. So if this MPL uses >>>>> trickel do you think it still will work in a non-shared communication >>>>> medium LLN, Please advise? >>>>>=20 >>>>> otherwise I recommend to add the words as in trickel: *lossy shared >>>>> medium* >>>>> As in the appplicability statement section 3 >>>>>=20 >>>>> AB> Recommend Amend to> >>>>> This protocol is an IPv6 multicast forwarding protocol for nodes in >>>>> shared medium within the low-power and lossy network domain. By >>>>> implementing a controlled dissemination using the Trickle algorithm, >>>>> this protocol is designed for networks that >>>>> communicate using low-power and lossy links with widely varying >>>>> topologies in both the space and time dimensions. >>>>>=20 >>>>> AB> question on section 3> I am not sure I understand *the space and >>>>> time dimensions*, Do you mean that the topology or multicast-nodes >>>>> is/are changing in space, please give me an example use-case? >>>>>=20 >>>>> Regards >>>>>=20 >>>>> AB >>>>>=20 >>>>>>> On 1/22/13, Michael Richardson wrote: >>>>>>>=20 >>>>>>> http://trac.tools.ietf.org/wg/roll/trac/report/8 >>>>>>> contains the list of open tickets. There are some threads >>>>>>> linked in each ticket. >>>>>>>=20 >>>>>>>=20 >>>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/103 >>>>>>> trickle-mcast: suppress ICMP messages for PROACTIVE_TIMER_EXPIRATIO= NS >>>>>>> http://www.ietf.org/mail-archive/web/roll/current/msg07424.html >>>>>>>=20 >>>>>>> This ticket has had no significant discussion. Is there an issue >>>>>>> here? >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/104 >>>>>>> security considerations. >>>>>>> We need to have a discussion about what are the implications >>>>>>> of this protocol. See next message. >>>>>>>=20 >>>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/105 >>>>>>> trickle-mcast: how to determine scope of MPL domain >>>>>>> We have several options from Robert Craigie in the ticket system. >>>>>>> Alternatives 3 and 4 were discussed, and I think that we preferred >>>>>>> option 4 with the multicast option always present. >>>>>>> Please post if you disagree. >>>>>>>=20 >>>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/106 >>>>>>> trickle-mcast: always use 6in6 encapsulation for non-link-local >>>>>>> multicast >>>>>>> no clear resolution, but ticket #105 suggests answer. >>>>>>>=20 >>>>>>>=20 >>>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/108 >>>>>>> trickle-mcast: should there be an explicit version field? >>>>>>> suggested answer was YES. >>>>>>>=20 >>>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/107 >>>>>>> trickle-mcast: should multiple parameter sets be supported >>>>>>> my conclusion: There is has been little discussion about this >>>>>>> issue. My inclination is to not include multiple sets at this >>>>>>> time. >>>>>>>=20 >>>>>>>=20 >>>>>>> http://trac.tools.ietf.org/wg/roll/trac/ticket/109 >>>>>>> trickle-mcast: should all MPL packets be destined to >>>>>>> all-MPL-forwarders >>>>>>>=20 >>>>>>>=20 >>>>>>> -- >>>>>>> Michael Richardson , Sandelman Software Work= s >>>>>>> IETF ROLL WG co-chair. >>>>>>> http://datatracker.ietf.org/wg/roll/charter/ >>>>>>>=20 >>>>>>>=20 >>>>>>=20 >>>>=20 >>>>=20 >>=20 >>=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From johui@cisco.com Mon Jan 28 08:48:29 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6201821F88B9 for ; Mon, 28 Jan 2013 08:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8+dm7vZeijxH for ; Mon, 28 Jan 2013 08:48:28 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id B820B21F87FA for ; Mon, 28 Jan 2013 08:48:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=690; q=dns/txt; s=iport; t=1359391708; x=1360601308; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Zyhn61fR/jOK36OOF1ncqStPeRtj7pZbRZW4qCFHFDs=; b=Qht+VNN4mrWoX+Zm5FjLM12mJlW4tULYzPb0I3LWqjb9jHlbKlvF+5ym R61TFmUQdY77b1iQ6+JNg3odMXULhEQxwa9HKNPtnofO0/qGD7NbJibPT kgQ3OFZtKBko2QUQptnW5dgqKwtK8tnUAkvdHySHs29F7F8qdcXw6+V6W 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMFALapBlGtJV2Y/2dsb2JhbABEhX+4VBZzgh4BAQEDAQEBATc0CwULAgEIGAoUECEGCyUCBA4FCId3AwkGDLYYDYlRBIwQhDRhA5Q3jQyFEoJ3giQ X-IronPort-AV: E=Sophos;i="4.84,553,1355097600"; d="scan'208";a="169316975" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 28 Jan 2013 16:48:28 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0SGmSiC010254 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 16:48:28 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 10:48:28 -0600 From: "Jonathan Hui (johui)" To: Abdussalam Baryun Thread-Topic: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 Thread-Index: AQHN/W9oT2fXxKK2sEKFqr+pjlBCP5hfV32AgAAA0IA= Date: Mon, 28 Jan 2013 16:48:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.2] Content-Type: text/plain; charset="us-ascii" Content-ID: <23F730E3AF4C374EAEC00BC7A3A502B0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "richard.kelsey@silabs.com Kelsey" , roll WG Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:48:29 -0000 MPL forwards IPv6 multicast messages using IPv6 multicast messages (hence t= he IPv6-in-IPv6 encapsulation). -- Jonathan Hui On Jan 28, 2013, at 8:45 AM, Abdussalam Baryun wrote: > On 1/28/13, Jonathan Hui (johui) wrote: >>=20 >> MPL uses multicast. >=20 > Do you mean; MPL uses IP multicast? >=20 > I understand that the MPL is already the multicast protocol for our > network, I thought that MPL does not need to use IP multicast. I may > misunderstood, please advise, >=20 > AB > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abdussalambaryun@gmail.com Mon Jan 28 08:53:49 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28E9C21F87E0 for ; Mon, 28 Jan 2013 08:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5FWMJjwuilZF for ; Mon, 28 Jan 2013 08:53:48 -0800 (PST) Received: from mail-pa0-f43.google.com (mail-pa0-f43.google.com [209.85.220.43]) by ietfa.amsl.com (Postfix) with ESMTP id 6CC7921F87C3 for ; Mon, 28 Jan 2013 08:53:47 -0800 (PST) Received: by mail-pa0-f43.google.com with SMTP id fb10so1627583pad.16 for ; Mon, 28 Jan 2013 08:53:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=GCGcXdhtEr3VQ3cTVrPfaQ9R9J0SHdBqSSv34rrPtJY=; b=K+iaHwt3oswtIgyzXcZoiJptjcmOFKcTXpUE4VUi7SLCzRWd7jB4mD5ZsZ9O9THqFu gHmtf20qnONQ4T6gckKpmQbNOFaImfpLcouN6ljb5/z/5nydyyerqZyhrbRxKKxx9BvB hD2QYU5qdc8hH7F8iAmGykEZ3uK66SbF3eu55eUNkU5yhGcwL3JrMFWn3tVwzn90nkP0 izUfY8xWJaJc8/zBoarQtwggtHFiUkqNy4mEgLK6RmiutOT3ZZ7IIMuvhaVJXuuj2MON MuVerGvv+MzQN8UlDQ6jkS/ly6coVa3ekXZFxtr7Fq7GNjmO1+Q6zxkRd2k4CsLH4kOu oKKQ== MIME-Version: 1.0 X-Received: by 10.66.78.100 with SMTP id a4mr37624308pax.4.1359392027594; Mon, 28 Jan 2013 08:53:47 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 28 Jan 2013 08:53:47 -0800 (PST) In-Reply-To: <80DCB95E-3AD9-4467-BFB1-F960232DB59B@gmail.com> References: <80DCB95E-3AD9-4467-BFB1-F960232DB59B@gmail.com> Date: Mon, 28 Jan 2013 17:53:47 +0100 Message-ID: From: Abdussalam Baryun To: Jonathan Hui Content-Type: text/plain; charset=ISO-8859-1 Cc: "richard.kelsey@silabs.com Kelsey" , roll WG Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:53:49 -0000 Hi Jonathan, So if MPL works in both, then I am confused, because Trickel RFC6206 that this I-D depends on works only for shared communication mediums. Does this I-D depend on the RFC6206 or it is not the only algorithm that MPL uses. AB On 1/28/13, Jonathan Hui wrote: > > Yes, MPL will work for both shared and non-shared media. > > -- > Jonathan Hui > From johui@cisco.com Mon Jan 28 08:59:56 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C5AB21F89AE for ; Mon, 28 Jan 2013 08:59:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t7A+uswU3CmY for ; Mon, 28 Jan 2013 08:59:55 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7B88421F8550 for ; Mon, 28 Jan 2013 08:59:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=860; q=dns/txt; s=iport; t=1359392395; x=1360601995; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=QpAfwX7aqOnpp7rFRRHqZnCCvOTufAUaCKnrl7sX3Aw=; b=U/9CWo5S4nsetVTbSUh1oJVg1duKjtR4hYPEsTVamL4pBmY57vUDl/fH owe7zIvXD6Upn9UjNMx8cVfsmSJEc18xxFEkRqDWeTnFBN102ayaLpSeZ h9vwhIBPEqQFZOFmxov386usqP9quz2Kj9jj4pD3RZBPHe4GFS1fJpFQS 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqMFAPGtBlGtJV2Z/2dsb2JhbABEhX+4VRZzgh4BAQEDAQEBATc0CwULAgEIGAoUECEGCyUCBA4FCId3AwkGDLYcDYlRBIwQhDRhA5Q3jQyFEoJ3giQ X-IronPort-AV: E=Sophos;i="4.84,553,1355097600"; d="scan'208";a="169324681" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 28 Jan 2013 16:59:55 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0SGxsh8029116 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 16:59:54 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 10:59:54 -0600 From: "Jonathan Hui (johui)" To: Abdussalam Baryun Thread-Topic: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 Thread-Index: AQHN/W9NT2fXxKK2sEKFqr+pjlBCPw== Date: Mon, 28 Jan 2013 16:59:53 +0000 Message-ID: References: <80DCB95E-3AD9-4467-BFB1-F960232DB59B@gmail.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.2] Content-Type: text/plain; charset="us-ascii" Content-ID: <6E64C5CEA3306D45A6EC470CB6B93C1B@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "richard.kelsey@silabs.com Kelsey" , roll WG Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 16:59:56 -0000 Again, while Trickle targets operation over shared media, Trickle can work = over non-shared media. RFC 6206 does not have any text that restricts Tric= kle to shared media. -- Jonathan Hui On Jan 28, 2013, at 8:53 AM, Abdussalam Baryun = wrote: > Hi Jonathan, >=20 > So if MPL works in both, then I am confused, because Trickel RFC6206 > that this I-D depends on works only for shared communication mediums. > Does this I-D depend on the RFC6206 or it is not the only algorithm > that MPL uses. >=20 > AB >=20 > On 1/28/13, Jonathan Hui wrote: >>=20 >> Yes, MPL will work for both shared and non-shared media. >>=20 >> -- >> Jonathan Hui >>=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abdussalambaryun@gmail.com Mon Jan 28 09:01:20 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39B9121F8A4F for ; Mon, 28 Jan 2013 09:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1Sqc3ScLwjyq for ; Mon, 28 Jan 2013 09:01:19 -0800 (PST) Received: from mail-pb0-f51.google.com (mail-pb0-f51.google.com [209.85.160.51]) by ietfa.amsl.com (Postfix) with ESMTP id C109121F89E9 for ; Mon, 28 Jan 2013 09:01:19 -0800 (PST) Received: by mail-pb0-f51.google.com with SMTP id un15so601380pbc.24 for ; Mon, 28 Jan 2013 09:01:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aoLeYoqjGfZujRTEFiVaORTKoZaIbC/qahZimRTjoSk=; b=bC+fp6N+esC/cj55oMGNnjtrOqt57Rub0O4EAOevyOJFd9bV+1Uv9EPypsGa6j47b6 4cFO54SIBrV1b7mUth7WFXx+arp+OuMHSzpy/+WSIXCOTeVG6jfeEQJvwZviJwQwJInF y6LdRPU9ukg7YcO7bd/XMBqcSpSE3KugxSwYvaybcXLn+2vy1dDWci6JcAxt9CDP2gwr SvP3ud3tw/evgNsdP8d9J9ww57LS4Yu/j1TBmwQELgZ19kgvXfIRIRNaZy70+8xdWLNk U1gwf/nfITurwz4ZzmCi1ppUpxxHhD4CMzoqcdOp+2xPFlOHFDO/36MtH6cPCIs63amt MvNQ== MIME-Version: 1.0 X-Received: by 10.68.232.195 with SMTP id tq3mr39136149pbc.70.1359392479520; Mon, 28 Jan 2013 09:01:19 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 28 Jan 2013 09:01:19 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Jan 2013 18:01:19 +0100 Message-ID: From: Abdussalam Baryun To: "Jonathan Hui (johui)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "richard.kelsey@silabs.com Kelsey" , roll WG Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 17:01:20 -0000 On 1/28/13, Jonathan Hui (johui) wrote: > > MPL forwards IPv6 multicast messages using IPv6 multicast messages (hence > the IPv6-in-IPv6 encapsulation). > So I understand from your reply that MPL uses always IPv6 multicast encapsulation for its data. I thought before it was only outside the MPL domains, that it will use IP-in-IP AB From johui@cisco.com Mon Jan 28 09:06:40 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA38D21F8A77 for ; Mon, 28 Jan 2013 09:06:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WjW2NRVag6t for ; Mon, 28 Jan 2013 09:06:40 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 302C321F8A74 for ; Mon, 28 Jan 2013 09:06:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1012; q=dns/txt; s=iport; t=1359392800; x=1360602400; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=ttMZhoexJtcKlO3furyb235yhjZAvNSXE8q6Sz9G+bU=; b=dCpotJYrlnMeoyJ06psvpYT8Fj5cEHR9F3NqWXleHaEDCybXekYifLoS crYKY1/4pGD+ZUVymX/UixNioW0GcxGBTEkEMvzoGJWarquh92H/bwG/+ bCwjk/u/Mr0uIZddR5difvjWoowg0ZkXX3nAYi9LEBIJg0eeFDxckjc9k o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAFyvBlGtJV2Y/2dsb2JhbABEvlQWc4IeAQEBAwEBAQE3NAsFCwIBCBgKFBAhBgslAgQOBQiHdwMJBgy2Gg2JUQSMEIQ0YQOUN40MhRKCd4Ik X-IronPort-AV: E=Sophos;i="4.84,553,1355097600"; d="scan'208";a="169291232" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-7.cisco.com with ESMTP; 28 Jan 2013 17:06:39 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0SH6d7N005355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 17:06:39 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 11:06:39 -0600 From: "Jonathan Hui (johui)" To: Abdussalam Baryun Thread-Topic: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 Thread-Index: AQHN/W9oT2fXxKK2sEKFqr+pjlBCPw== Date: Mon, 28 Jan 2013 17:06:38 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.2] Content-Type: text/plain; charset="us-ascii" Content-ID: <88B9D3CDED6BAD46A951B903F7369A74@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "richard.kelsey@silabs.com Kelsey" , roll WG Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 17:06:41 -0000 IPv6-in-IPv6 encapsulation is not required if the IPv6 Destination Address = is the MPL Domain Address. But whether or not encapsulation is used, Section 10.1 specifies: The IPv6 Destination Address MUST be set to the MPL Domain Address corresponding to the MPL Domain. And as Section 2 specifies, the MPL Domain Address is a multicast address. -- Jonathan Hui On Jan 28, 2013, at 9:01 AM, Abdussalam Baryun = wrote: > On 1/28/13, Jonathan Hui (johui) wrote: >>=20 >> MPL forwards IPv6 multicast messages using IPv6 multicast messages (henc= e >> the IPv6-in-IPv6 encapsulation). >>=20 >=20 > So I understand from your reply that MPL uses always IPv6 multicast > encapsulation for its data. I thought before it was only outside the > MPL domains, that it will use IP-in-IP >=20 > AB > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abdussalambaryun@gmail.com Mon Jan 28 09:11:20 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4DF521F87E0 for ; Mon, 28 Jan 2013 09:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.589 X-Spam-Level: X-Spam-Status: No, score=-3.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CYkrca07Uyix for ; Mon, 28 Jan 2013 09:11:20 -0800 (PST) Received: from mail-pb0-f45.google.com (mail-pb0-f45.google.com [209.85.160.45]) by ietfa.amsl.com (Postfix) with ESMTP id 56F0021F8480 for ; Mon, 28 Jan 2013 09:11:20 -0800 (PST) Received: by mail-pb0-f45.google.com with SMTP id rq13so1587986pbb.32 for ; Mon, 28 Jan 2013 09:11:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=TqG69uJr+cqcpxEJzIJU5CcAOd3IbJearNdADgeVAHQ=; b=Hkx9QRNutRO/lNCysg1LU7Y8IVl3dSJfs+uSG6EkQ+96FO3ce08Wq0B5wJVrQtB0WM utC18FFK2e7jrN3VQy1ESQaA3z1P51h3YV5+bMWGkIKZCewaZNXH7g19Uy8Fs33nlXM+ BZFGFLi/I6R/NeRIIVAPRsfdPOONZ+4e2NlRt4EVWep7adwdti5XrwSEvt7aoCnACIke cpt0pbjROcqEm9Kh+ewyL3W7ooQiZdRVquX7QsKefzrVKWCRXdaw4KgRLuiJ/emsWQgA f5W9sFh7tBvaH0J6Oatuyjru2SAtzeozJYwGm5hlDA5iNr0FKkboJNNj1g0u3xzjLVtz 0ojg== MIME-Version: 1.0 X-Received: by 10.66.72.226 with SMTP id g2mr37294883pav.67.1359393080109; Mon, 28 Jan 2013 09:11:20 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 28 Jan 2013 09:11:20 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Jan 2013 18:11:20 +0100 Message-ID: From: Abdussalam Baryun To: "Jonathan Hui (johui)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "richard.kelsey@silabs.com Kelsey" , roll WG Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 17:11:20 -0000 Ok so my understanding before was correct. Therefore, inside the MPL domain there is no need for IP multicast, just MPL multicast using its forwarders, is this correct? AB On 1/28/13, Jonathan Hui (johui) wrote: > > IPv6-in-IPv6 encapsulation is not required if the IPv6 Destination Address > is the MPL Domain Address. > > But whether or not encapsulation is used, Section 10.1 specifies: > > The IPv6 Destination Address MUST be set to the MPL Domain Address > corresponding to the MPL Domain. > > And as Section 2 specifies, the MPL Domain Address is a multicast address. > > -- > Jonathan Hui > > On Jan 28, 2013, at 9:01 AM, Abdussalam Baryun > wrote: > >> On 1/28/13, Jonathan Hui (johui) wrote: >>> >>> MPL forwards IPv6 multicast messages using IPv6 multicast messages >>> (hence >>> the IPv6-in-IPv6 encapsulation). >>> >> >> So I understand from your reply that MPL uses always IPv6 multicast >> encapsulation for its data. I thought before it was only outside the >> MPL domains, that it will use IP-in-IP >> >> AB >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > From johui@cisco.com Mon Jan 28 09:14:39 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C0F21F87FE for ; Mon, 28 Jan 2013 09:14:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CN3K+ibxQHhb for ; Mon, 28 Jan 2013 09:14:35 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8C9A821F862E for ; Mon, 28 Jan 2013 09:14:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1784; q=dns/txt; s=iport; t=1359393275; x=1360602875; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YUKesJZcmK2p/gexISwTorOwbO19KvwQWdTo7Jc6UDo=; b=hjOSQY/n75BXkbuy7UPtgor08+BRgtqABB+aiczhXfAxdiNhRpFE5DUZ L3i8okotRh2GfnPUgPEE/WI6aVxem+RQDc+Nee3hUP85b7g/xr+a2tyJM LV6UtelWTlzDKHXoYhr01QEr7fSy3BThmte/FKf5RnBQgLjQBZscC0U8q E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAK2xBlGtJXG8/2dsb2JhbABEvlQWc4IeAQEBAwEBAQE3NAsFCwIBCBgKFBAhBgslAgQOBQiHdwMJBgy2IQ2JUQSMEIQ0YQOUN40MhRKCd4Ik X-IronPort-AV: E=Sophos;i="4.84,553,1355097600"; d="scan'208";a="169272327" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 28 Jan 2013 17:14:35 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id r0SHEZvu005244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 28 Jan 2013 17:14:35 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Mon, 28 Jan 2013 11:14:34 -0600 From: "Jonathan Hui (johui)" To: Abdussalam Baryun Thread-Topic: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 Thread-Index: AQHN/W9oT2fXxKK2sEKFqr+pjlBCPw== Date: Mon, 28 Jan 2013 17:14:34 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [128.107.155.2] Content-Type: text/plain; charset="us-ascii" Content-ID: <9C6E32A74781684A86AA38A30184F47E@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "richard.kelsey@silabs.com Kelsey" , roll WG Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 17:14:40 -0000 Correct. An MPL Forwarder forwards a message to its next hop using link-la= yer multicast (which many LLN technologies map to link-layer broadcast). -- Jonathan Hui On Jan 28, 2013, at 9:11 AM, Abdussalam Baryun = wrote: > Ok so my understanding before was correct. Therefore, inside the MPL > domain there is no need for IP multicast, just MPL multicast using its > forwarders, is this correct? >=20 > AB >=20 > On 1/28/13, Jonathan Hui (johui) wrote: >>=20 >> IPv6-in-IPv6 encapsulation is not required if the IPv6 Destination Addre= ss >> is the MPL Domain Address. >>=20 >> But whether or not encapsulation is used, Section 10.1 specifies: >>=20 >> The IPv6 Destination Address MUST be set to the MPL Domain Address >> corresponding to the MPL Domain. >>=20 >> And as Section 2 specifies, the MPL Domain Address is a multicast addres= s. >>=20 >> -- >> Jonathan Hui >>=20 >> On Jan 28, 2013, at 9:01 AM, Abdussalam Baryun >> wrote: >>=20 >>> On 1/28/13, Jonathan Hui (johui) wrote: >>>>=20 >>>> MPL forwards IPv6 multicast messages using IPv6 multicast messages >>>> (hence >>>> the IPv6-in-IPv6 encapsulation). >>>>=20 >>>=20 >>> So I understand from your reply that MPL uses always IPv6 multicast >>> encapsulation for its data. I thought before it was only outside the >>> MPL domains, that it will use IP-in-IP >>>=20 >>> AB >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>=20 >>=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From abdussalambaryun@gmail.com Mon Jan 28 10:48:26 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C23321F8717 for ; Mon, 28 Jan 2013 10:48:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lECPV2YQrXMP for ; Mon, 28 Jan 2013 10:48:25 -0800 (PST) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id CB62D21F86FF for ; Mon, 28 Jan 2013 10:48:25 -0800 (PST) Received: by mail-pa0-f51.google.com with SMTP id fb11so1687849pad.24 for ; Mon, 28 Jan 2013 10:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=4xvClj1jRg4l/X+/OWGoG8Hmf7QQZ/gpLE6MDgSES9Y=; b=LqQGWiym78ExUBesOjLJV9bgOEJqWtcu67qdvaTed8WXxRMCAP5xv2acAb3VkV9l+w kx1QNI8UCXzzfGRMh2galShDoHjY8T24Ku2lIvSWbGPIsp314nFZv+YMK7CK2QrSnyG6 TdrvLkZ7zyDPnH3zU3TGaEYCbJ1RzcQ1K4DoaFR2njP3U4Ti5yzTDX4t0fY26Gnye8xV wFLnUthpSP3DS4rVSEb+HX8MSTayb0SrcfGnjcDX6xLHhZWfgcLcm0JYr9KYZdq5MfH8 oq7hLmeU2JXNkd+5uI82H8JvXCkDEs4kn4KX6/7tpTX2iv4aKYyzkqmddPnoXMofrWZZ U7TQ== MIME-Version: 1.0 X-Received: by 10.68.232.195 with SMTP id tq3mr39867861pbc.70.1359398905545; Mon, 28 Jan 2013 10:48:25 -0800 (PST) Received: by 10.68.218.134 with HTTP; Mon, 28 Jan 2013 10:48:25 -0800 (PST) In-Reply-To: References: Date: Mon, 28 Jan 2013 19:48:25 +0100 Message-ID: From: Abdussalam Baryun To: "Jonathan Hui (johui)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "richard.kelsey@silabs.com Kelsey" , roll WG Subject: Re: [Roll] Discussion/Comments For draft-ietf-roll-trickle-mcast-03 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jan 2013 18:48:26 -0000 On 1/28/13, Jonathan Hui (johui) wrote: > > Correct. An MPL Forwarder forwards a message to its next hop using > link-layer multicast (which many LLN technologies map to link-layer > broadcast). > I understand from reply and previous one, as MPLhas no knowledge of neighbors, so that MPL is not multicasting by itself within the domain, it is broadcasting, but because using Trickel not always all nodes in the domain receive the message, therefore, MPL is multicasting. Overall, now I think I got to read the draft again, to prepare my review, thanks alot for your help, AB > -- > Jonathan Hui > > On Jan 28, 2013, at 9:11 AM, Abdussalam Baryun > wrote: > >> Ok so my understanding before was correct. Therefore, inside the MPL >> domain there is no need for IP multicast, just MPL multicast using its >> forwarders, is this correct? >> >> AB >> >> On 1/28/13, Jonathan Hui (johui) wrote: >>> >>> IPv6-in-IPv6 encapsulation is not required if the IPv6 Destination >>> Address >>> is the MPL Domain Address. >>> >>> But whether or not encapsulation is used, Section 10.1 specifies: >>> >>> The IPv6 Destination Address MUST be set to the MPL Domain Address >>> corresponding to the MPL Domain. >>> >>> And as Section 2 specifies, the MPL Domain Address is a multicast >>> address. >>> >>> -- >>> Jonathan Hui >>> >>> On Jan 28, 2013, at 9:01 AM, Abdussalam Baryun >>> >>> wrote: >>> >>>> On 1/28/13, Jonathan Hui (johui) wrote: >>>>> >>>>> MPL forwards IPv6 multicast messages using IPv6 multicast messages >>>>> (hence >>>>> the IPv6-in-IPv6 encapsulation). >>>>> >>>> >>>> So I understand from your reply that MPL uses always IPv6 multicast >>>> encapsulation for its data. I thought before it was only outside the >>>> MPL domains, that it will use IP-in-IP >>>> >>>> AB >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>> >>> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll > > From dat@exegin.com Tue Jan 29 11:03:32 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C26421F87CD for ; Tue, 29 Jan 2013 11:03:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id irt6+Ar2hBfQ for ; Tue, 29 Jan 2013 11:03:31 -0800 (PST) Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id C3D1421F87A4 for ; Tue, 29 Jan 2013 11:03:30 -0800 (PST) Received: by mail-ee0-f50.google.com with SMTP id e51so431551eek.23 for ; Tue, 29 Jan 2013 11:03:29 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=C0CjIyfPNf+6xqDsQeulEKHkbL6z8Zs0AbjHN8Q51Po=; b=VfIvLehYAzV4QWrDAchS9TxgwrIfZFJQNH9kfX8f+GCidgXH1YPRF757DQAFUd7YrP 74Y7ajOqLUGngU9Ob0lPmh4p2UTLaqkP1ALsQDGNPcxSoQjNBWqvdAOGHJWmpl3u7dpG gDOZbdbBdWL5/L8g3UVxu4vRpV4ljUzF4YoLu/76wdm1oZhn0iUrvKUJp3AJvXFp+jgi fmCaA02Ph0s6JgXphMpFn6UYcCf++7HJYcVn7tVwhA13UF91ZDGxOXgT+VC/LGPcgzDn hup8JPnMOkCdwFbOlMwgRjP+16vl128KZPsQdbUDroobYpAaCS37YuN5e/dJDK1RTo7u 1oGA== X-Received: by 10.14.224.137 with SMTP id x9mr6208234eep.11.1359486209690; Tue, 29 Jan 2013 11:03:29 -0800 (PST) Received: from [10.1.0.149] (static-94-72-198-70.karoo.KCOM.COM. [94.72.198.70]) by mx.google.com with ESMTPS id t4sm21374634eel.0.2013.01.29.11.01.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Jan 2013 11:03:28 -0800 (PST) Message-ID: <51081BB1.8060708@exegin.com> Date: Tue, 29 Jan 2013 18:57:53 +0000 From: Dario Tedeschi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 MIME-Version: 1.0 To: roll@ietf.org References: <2AA5AC69E924D149A8D63EB676AF87DB2CB38F33@DLEE10.ent.ti.com> In-Reply-To: <2AA5AC69E924D149A8D63EB676AF87DB2CB38F33@DLEE10.ent.ti.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQnRAkx5ZFYNNsnXu34vSyqSajPntrvOTv7+pLzrNBqq6bvil150q0My6z4++1BtBwHpG8Xb Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jan 2013 19:03:32 -0000 Thank you Jonathan. The draft satisfies all my previous concerns. - Dario On 13-01-25 10:52 PM, Reddy, Joseph wrote: > Thanks Jonathan and Richard for the updated draft. It looks good and addressed all my previous comments. > > I should also mention that we have been performing interoperability testing within the ZigBee IP community this week. We have 6 independent implementations of the MPL protocol (running over 802.15.4 radios) and were able to successfully interop among all of them. We tested MPL protocol with and without the tunneling options. > > > -Regards, Joseph > > ------------------------------ > > Message: 5 > Date: Thu, 24 Jan 2013 08:09:07 -0800 > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt > Message-ID: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> > Content-Type: text/plain; charset="utf-8" > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. > > Title : Multicast Protocol for Low power and Lossy Networks (MPL) > Author(s) : Jonathan W. Hui > Richard Kelsey > Filename : draft-ietf-roll-trickle-mcast-03.txt > Pages : 29 > Date : 2013-01-24 > > Abstract: > This document specifies the Multicast Protocol for Low power and > Lossy Networks (MPL) that provides IPv6 multicast forwarding in > constrained networks. MPL avoids the need to construct or maintain > any multicast forwarding topology, disseminating messages to all MPL > forwarders in an MPL domain. MPL uses the Trickle algorithm to > manage message transmissions for both control and data-plane > messages. Different Trickle parameter configurations allow MPL to > trade between dissemination latency and transmission efficiency. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-trickle-mcast-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From robert.cragie@gmail.com Tue Jan 29 11:29:16 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9C221F84C9 for ; Tue, 29 Jan 2013 11:29:16 -0800 (PST) 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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, SARE_HTML_USL_OBFU=1.666] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hdBRQqdO1iYQ for ; Tue, 29 Jan 2013 11:29:15 -0800 (PST) Received: from mail-ee0-f42.google.com (mail-ee0-f42.google.com [74.125.83.42]) by ietfa.amsl.com (Postfix) with ESMTP id 1EE0021F84C2 for ; Tue, 29 Jan 2013 11:29:14 -0800 (PST) Received: by mail-ee0-f42.google.com with SMTP id b47so423735eek.1 for ; Tue, 29 Jan 2013 11:29:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=Uc3yKIRn5ossi/+xavwMbffi0n8XU0XERE06fJmtpf4=; b=nxP9cnlr+UGanScyZHuOOvsoNJE4DQaNvTI4rW8egRs7wy1QTopkY1P/53i9W29Ujw XFMbTU0hxmJWYnrVcmcFqTwH0pNaKAUu8arkg8bvo+i+6rhxxtptx0GQ3ISvuSJWz0fb MN8z2ARKQISmoIilNqt+q3OmPnj0vHo7CJL2ShRd3/KR5Mbk/MkYFUcduIab0gMzOOIs I4didX4L06//gzLDtmpGqn7OgRgxibi78rs5b0SWW3TPYUhscxT8iFe/Ya0wDPNqgJtM OoZIqGItXU5agMNMKR6FvL5GeEGfKdzcx6UeEGEeIaZsqR+2R7yuJYjNhwT2LDxyYxtD F5vA== MIME-Version: 1.0 X-Received: by 10.14.175.70 with SMTP id y46mr6283303eel.6.1359487754219; Tue, 29 Jan 2013 11:29:14 -0800 (PST) Sender: robert.cragie@gmail.com Received: by 10.14.1.197 with HTTP; Tue, 29 Jan 2013 11:29:14 -0800 (PST) In-Reply-To: <51081BB1.8060708@exegin.com> References: <2AA5AC69E924D149A8D63EB676AF87DB2CB38F33@DLEE10.ent.ti.com> <51081BB1.8060708@exegin.com> Date: Tue, 29 Jan 2013 19:29:14 +0000 X-Google-Sender-Auth: OfJbCq8CIO7J9XSYk8SqdkZwt5g Message-ID: From: Robert Cragie To: roll@ietf.org Content-Type: multipart/alternative; boundary=047d7b5dbe20aab1f504d47268a7 Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 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, 29 Jan 2013 19:29:16 -0000 --047d7b5dbe20aab1f504d47268a7 Content-Type: text/plain; charset=ISO-8859-1 I would also like to thank Jonathan and say that the draft satisfies all my previous comments as well Robert On Tue, Jan 29, 2013 at 6:57 PM, Dario Tedeschi wrote: > Thank you Jonathan. The draft satisfies all my previous concerns. > > - Dario > > > On 13-01-25 10:52 PM, Reddy, Joseph wrote: > >> Thanks Jonathan and Richard for the updated draft. It looks good and >> addressed all my previous comments. >> >> I should also mention that we have been performing interoperability >> testing within the ZigBee IP community this week. We have 6 independent >> implementations of the MPL protocol (running over 802.15.4 radios) and were >> able to successfully interop among all of them. We tested MPL protocol with >> and without the tunneling options. >> >> >> -Regards, Joseph >> >> ------------------------------ >> >> Message: 5 >> Date: Thu, 24 Jan 2013 08:09:07 -0800 >> From: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> Cc: roll@ietf.org >> Subject: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-**03.txt >> Message-ID: <20130124160907.4820.99930.**idtracker@ietfa.amsl.com<20130124160907.4820.99930.idtracker@ietfa.amsl.com> >> > >> Content-Type: text/plain; charset="utf-8" >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Routing Over Low power and Lossy >> networks Working Group of the IETF. >> >> Title : Multicast Protocol for Low power and Lossy >> Networks (MPL) >> Author(s) : Jonathan W. Hui >> Richard Kelsey >> Filename : draft-ietf-roll-trickle-mcast-**03.txt >> Pages : 29 >> Date : 2013-01-24 >> >> Abstract: >> This document specifies the Multicast Protocol for Low power and >> Lossy Networks (MPL) that provides IPv6 multicast forwarding in >> constrained networks. MPL avoids the need to construct or maintain >> any multicast forwarding topology, disseminating messages to all MPL >> forwarders in an MPL domain. MPL uses the Trickle algorithm to >> manage message transmissions for both control and data-plane >> messages. Different Trickle parameter configurations allow MPL to >> trade between dissemination latency and transmission efficiency. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/**doc/draft-ietf-roll-trickle-**mcast >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/**draft-ietf-roll-trickle-mcast-**03 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?**url2=draft-ietf-roll-trickle-**mcast-03 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-**drafts/ >> >> >> >> ______________________________**_________________ >> 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 > --047d7b5dbe20aab1f504d47268a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I would also like to thank Jonathan and say that the draft satisfies all my= previous comments as well

Robert

On Tue, Jan 29, 2013 at 6:57 PM, Dario Tedeschi <dat@exegin.com> wrote:
Thank you Jonathan. The draft satisfies all = my previous concerns.

- Dario


On 13-01-25 10:52 PM, Reddy, Joseph wrote:
Thanks Jonathan and Richard for the updated draft. It looks good and addres= sed all my previous comments.

I should also mention that we have been performing interoperability testing= within the ZigBee IP community this week. We have 6 independent implementa= tions of the MPL protocol (running over 802.15.4 radios) and were able to s= uccessfully interop among all of them. We tested MPL protocol with and with= out the tunneling options.


-Regards, Joseph

------------------------------

Message: 5
Date: Thu, 24 Jan 2013 08:09:07 -0800
From: interne= t-drafts@ietf.org
To: i-d-announce= @ietf.org
Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt
Message-ID: <20130124160907.4820.99930.idtracker@iet= fa.amsl.com>
Content-Type: text/plain; charset=3D"utf-8"


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

=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Multicast Protocol for Low powe= r and Lossy Networks (MPL)
=A0 =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : Jonathan W. Hui
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Richard Kelsey
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-roll-trickle-mcast-= 03.txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 29
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-01-24

Abstract:
=A0 =A0 This document specifies the Multicast Protocol for Low power and =A0 =A0 Lossy Networks (MPL) that provides IPv6 multicast forwarding in
=A0 =A0 constrained networks. =A0MPL avoids the need to construct or mainta= in
=A0 =A0 any multicast forwarding topology, disseminating messages to all MP= L
=A0 =A0 forwarders in an MPL domain. =A0MPL uses the Trickle algorithm to =A0 =A0 manage message transmissions for both control and data-plane
=A0 =A0 messages. =A0Different Trickle parameter configurations allow MPL t= o
=A0 =A0 trade between dissemination latency and transmission efficiency.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-t= rickle-mcast

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-roll-trickle-mc= ast-03

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf= -roll-trickle-mcast-03


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



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


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

--047d7b5dbe20aab1f504d47268a7-- From esko.dijk@philips.com Wed Jan 30 05:15:15 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C8AA21F89F9 for ; Wed, 30 Jan 2013 05:15:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TEqtWdt2VZdq for ; Wed, 30 Jan 2013 05:15:11 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe005.messaging.microsoft.com [216.32.180.188]) by ietfa.amsl.com (Postfix) with ESMTP id 57EC221F89D8 for ; Wed, 30 Jan 2013 05:15:09 -0800 (PST) Received: from mail127-co1-R.bigfish.com (10.243.78.223) by CO1EHSOBE036.bigfish.com (10.243.66.101) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 Jan 2013 13:15:08 +0000 Received: from mail127-co1 (localhost [127.0.0.1]) by mail127-co1-R.bigfish.com (Postfix) with ESMTP id D5B32A800AD; Wed, 30 Jan 2013 13:15:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: VPS-35(zz217bI98dI15d6O9371I9251J936eI542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h1155h) Received: from mail127-co1 (localhost.localdomain [127.0.0.1]) by mail127-co1 (MessageSwitch) id 1359551707830228_26898; Wed, 30 Jan 2013 13:15:07 +0000 (UTC) Received: from CO1EHSMHS028.bigfish.com (unknown [10.243.78.196]) by mail127-co1.bigfish.com (Postfix) with ESMTP id C6A5898004A; Wed, 30 Jan 2013 13:15:07 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS028.bigfish.com (10.243.66.38) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 Jan 2013 13:15:07 +0000 Received: from 011-DB3MPN2-081.MGDPHG.emi.philips.com ([169.254.1.86]) by 011-DB3MMR1-004.MGDPHG.emi.philips.com ([10.128.28.54]) with mapi id 14.02.0318.003; Wed, 30 Jan 2013 13:14:32 +0000 From: "Dijk, Esko" To: "Jonathan Hui (johui)" Thread-Topic: Seed Set use across MPL Domains (was: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt) Thread-Index: AQHN/uu9Eoo2YugjFkKDyYhvrPtHxA== Date: Wed, 30 Jan 2013 13:14:31 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B76709@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.138.224.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "roll@ietf.org WG" Subject: [Roll] Seed Set use across MPL Domains (was: Re: I-D Action: draft-ietf-roll-trickle-mcast-03.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 13:15:15 -0000 Thanks Jonathan and Richard for this major update to the draft. The option = to allow multiple MPL Domains to co-exist is a very useful addition. On thi= s topic some questions / remarks: 1. adding "Seed Identifier" to the section 2 Terminology could help to clar= ify that a single MPL Forwarder/Seed has a single Seed Identifier. This See= dID remains identical across multiple MPL Domains it participates in, right= ? 2. I think for the text to be correct (sections 4.3, 6.2. 6.3, 7.3, 10.3, 1= 1.X e.g. - any text where Seed Set is used in fact) there needs to be a sep= arate Seed Set per MPL Domain a Forwarder participates in. Is this the solu= tion? Peter already remarked the problem for sections 4.1/11.3. Note that the Buffered Message Set already contains information on MPL Doma= in, somewhat hidden in the 'DataMessage' object in the tuple (Section 7.4).= (The IPv6 Destination Address of this MPL Data Message identifies the MPL = Domain). So for this data structure, there's perhaps no need to add an expl= icit "Domain identifier" to the tuple. But it would clarify the text to add= such element to the tuple. regards, Esko -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jon= athan Hui (johui) Sent: Thursday 24 January 2013 17:14 To: roll@ietf.org WG Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt This update addresses all of the open tickets in the following manner: Ticket 103: MPL Control Messages may be disabled by setting CONTROL_MESSAGE= _TIMER_EXPIRATIONS to zero. Ticket 104: Added security considerations text. Ticket 105: Scope is determined by the IPv6 Destination Address of MPL Data= Packet. Ticket 106: Text added to always use IPv6-in-IPv6 encapsulation when multic= ast destination does not match MPL Domain Address. Ticket 107: Multiple parameter sets are not supported at this time. Ticket 108: Added explicit 1-bit version field. Ticket 109: All MPL packets must be destined to the MPL Domain Address that= identifies the MPL Domain. Ticket 110: Not in scope. If an application subscribes to an address, it s= hould receive all packets destined to that address whether or not they were= received in an MPL Data Packet. -- Jonathan Hui On Jan 24, 2013, at 8:09 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Routing Over Low power and Lossy network= s Working Group of the IETF. > > Title : Multicast Protocol for Low power and Lossy Networ= ks (MPL) > Author(s) : Jonathan W. Hui > Richard Kelsey > Filename : draft-ietf-roll-trickle-mcast-03.txt > Pages : 29 > Date : 2013-01-24 > > Abstract: > This document specifies the Multicast Protocol for Low power and > Lossy Networks (MPL) that provides IPv6 multicast forwarding in > constrained networks. MPL avoids the need to construct or maintain > any multicast forwarding topology, disseminating messages to all MPL > forwarders in an MPL domain. MPL uses the Trickle algorithm to > manage message transmissions for both control and data-plane > messages. Different Trickle parameter configurations allow MPL to > trade between dissemination latency and transmission efficiency. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From esko.dijk@philips.com Wed Jan 30 05:45:27 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0860721F8460 for ; Wed, 30 Jan 2013 05:45:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bM7vfIYD2CSt for ; Wed, 30 Jan 2013 05:45:26 -0800 (PST) Received: from db3outboundpool.messaging.microsoft.com (db3ehsobe004.messaging.microsoft.com [213.199.154.142]) by ietfa.amsl.com (Postfix) with ESMTP id 8524121F8450 for ; Wed, 30 Jan 2013 05:45:24 -0800 (PST) Received: from mail108-db3-R.bigfish.com (10.3.81.238) by DB3EHSOBE007.bigfish.com (10.3.84.27) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 Jan 2013 13:45:21 +0000 Received: from mail108-db3 (localhost [127.0.0.1]) by mail108-db3-R.bigfish.com (Postfix) with ESMTP id 7F7122C0755; Wed, 30 Jan 2013 13:45:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: VPS-35(zz217bI98dI15d6O9371I9251J936eI542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h1155h) Received: from mail108-db3 (localhost.localdomain [127.0.0.1]) by mail108-db3 (MessageSwitch) id 1359553519495516_28908; Wed, 30 Jan 2013 13:45:19 +0000 (UTC) Received: from DB3EHSMHS002.bigfish.com (unknown [10.3.81.234]) by mail108-db3.bigfish.com (Postfix) with ESMTP id 747554E0084; Wed, 30 Jan 2013 13:45:19 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB3EHSMHS002.bigfish.com (10.3.87.102) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 Jan 2013 13:45:16 +0000 Received: from 011-DB3MMR1-013.MGDPHG.emi.philips.com (10.128.28.97) by 011-DB3MMR1-008.MGDPHG.emi.philips.com (10.128.28.47) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 30 Jan 2013 13:45:15 +0000 Received: from 011-DB3MPN2-081.MGDPHG.emi.philips.com ([169.254.1.86]) by 011-DB3MMR1-013.MGDPHG.emi.philips.com ([10.128.28.97]) with mapi id 14.02.0318.003; Wed, 30 Jan 2013 13:45:15 +0000 From: "Dijk, Esko" To: "Jonathan Hui (johui)" Thread-Topic: draft-ietf-roll-trickle-mcast-03: Varying Trickle parameters per MPL Domain Thread-Index: AQHN/vAINxczu3EJA0upl+RyiN3Xew== Date: Wed, 30 Jan 2013 13:45:15 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B7678F@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.138.224.48] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "roll@ietf.org WG" Subject: [Roll] draft-ietf-roll-trickle-mcast-03: Varying Trickle parameters per MPL Domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 13:45:27 -0000 In Section 5.4, Trickle parameters are (implicitly?) forced to be equal for= all MPL Domains that an MPL Forwarder participates in, because only 2 sets= are supported per MPL Forwarder. Isn't this overly restrictive? Given that= the MPL Domains don't interact with each other, it would be fine if a set = of parameters is equal only within one and the same MPL Domain (so, that me= ans an MPL Forwarder could have different Trickle parameters for each MPL D= omain it is in.) The final sentence of section 5.4 confirms this view, that only within-Doma= in parameter equality is important: "It is RECOMMENDED that all MPL Forwarder within an MPL Domain use the same= values for the Trickle Parameters above" Since a configuration method for Trickle parameters is out of scope of the = I-D, it doesn't add any extra complexity here to allow different Trickle pa= rameters for different MPL Domains. Also, allowing this does not seem to br= eak the protocol in any way (unless I overlook something.) regards, Esko -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jon= athan Hui (johui) Sent: Thursday 24 January 2013 17:14 To: roll@ietf.org WG Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt This update addresses all of the open tickets in the following manner: Ticket 103: MPL Control Messages may be disabled by setting CONTROL_MESSAGE= _TIMER_EXPIRATIONS to zero. Ticket 104: Added security considerations text. Ticket 105: Scope is determined by the IPv6 Destination Address of MPL Data= Packet. Ticket 106: Text added to always use IPv6-in-IPv6 encapsulation when multic= ast destination does not match MPL Domain Address. Ticket 107: Multiple parameter sets are not supported at this time. Ticket 108: Added explicit 1-bit version field. Ticket 109: All MPL packets must be destined to the MPL Domain Address that= identifies the MPL Domain. Ticket 110: Not in scope. If an application subscribes to an address, it s= hould receive all packets destined to that address whether or not they were= received in an MPL Data Packet. -- Jonathan Hui On Jan 24, 2013, at 8:09 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Routing Over Low power and Lossy network= s Working Group of the IETF. > > Title : Multicast Protocol for Low power and Lossy Networ= ks (MPL) > Author(s) : Jonathan W. Hui > Richard Kelsey > Filename : draft-ietf-roll-trickle-mcast-03.txt > Pages : 29 > Date : 2013-01-24 > > Abstract: > This document specifies the Multicast Protocol for Low power and > Lossy Networks (MPL) that provides IPv6 multicast forwarding in > constrained networks. MPL avoids the need to construct or maintain > any multicast forwarding topology, disseminating messages to all MPL > forwarders in an MPL domain. MPL uses the Trickle algorithm to > manage message transmissions for both control and data-plane > messages. Different Trickle parameter configurations allow MPL to > trade between dissemination latency and transmission efficiency. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From esko.dijk@philips.com Wed Jan 30 06:10:57 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6ABB21F8B29 for ; Wed, 30 Jan 2013 06:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wckWFQPtER+Z for ; Wed, 30 Jan 2013 06:10:56 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe006.messaging.microsoft.com [216.32.180.189]) by ietfa.amsl.com (Postfix) with ESMTP id C16A821F8B06 for ; Wed, 30 Jan 2013 06:10:56 -0800 (PST) Received: from mail20-co1-R.bigfish.com (10.243.78.204) by CO1EHSOBE006.bigfish.com (10.243.66.69) with Microsoft SMTP Server id 14.1.225.23; Wed, 30 Jan 2013 14:10:56 +0000 Received: from mail20-co1 (localhost [127.0.0.1]) by mail20-co1-R.bigfish.com (Postfix) with ESMTP id 1A6D9C400E6; Wed, 30 Jan 2013 14:10:56 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zz217bI15d6O9251Jc85fhzz1ee6h1de0h1202h1e76h1d1ah1d2ahzz18de19h1033IL17326ah8275dh18c673hz2dh2a8h668h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h1155h) Received: from mail20-co1 (localhost.localdomain [127.0.0.1]) by mail20-co1 (MessageSwitch) id 1359555007275058_24116; Wed, 30 Jan 2013 14:10:07 +0000 (UTC) Received: from CO1EHSMHS024.bigfish.com (unknown [10.243.78.196]) by mail20-co1.bigfish.com (Postfix) with ESMTP id 10AA0800059; Wed, 30 Jan 2013 14:09:52 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO1EHSMHS024.bigfish.com (10.243.66.34) with Microsoft SMTP Server (TLS) id 14.1.225.23; Wed, 30 Jan 2013 14:09:52 +0000 Received: from 011-DB3MMR1-012.MGDPHG.emi.philips.com (10.128.28.96) by 011-DB3MMR1-005.MGDPHG.emi.philips.com (10.128.28.55) with Microsoft SMTP Server (TLS) id 14.2.318.3; Wed, 30 Jan 2013 14:09:49 +0000 Received: from 011-DB3MPN2-081.MGDPHG.emi.philips.com ([169.254.1.86]) by 011-DB3MMR1-012.MGDPHG.emi.philips.com ([10.128.28.96]) with mapi id 14.02.0318.003; Wed, 30 Jan 2013 14:09:49 +0000 From: "Dijk, Esko" To: "Jonathan Hui (johui)" Thread-Topic: draft-ietf-roll-trickle-mcast-03: IANA request ALL_MPL_FORWARDERS in 0x0-0xFF range Thread-Index: Ac3+83VcqrMjS4SDRUumHx/mSa8NNA== Date: Wed, 30 Jan 2013 14:09:48 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B767C1@011-DB3MPN2-081.MGDPHG.emi.philips.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.138.224.48] Content-Type: multipart/alternative; boundary="_000_031DD135F9160444ABBE3B0C36CED618B767C1011DB3MPN2081MGDP_" MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "roll@ietf.org WG" Subject: [Roll] draft-ietf-roll-trickle-mcast-03: IANA request ALL_MPL_FORWARDERS in 0x0-0xFF range X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 14:10:57 -0000 --_000_031DD135F9160444ABBE3B0C36CED618B767C1011DB3MPN2081MGDP_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If still relevant for the new MPL I-D, I can create a ticket for this: to = include request for 6LoWPAN-compressible multicast group identifier for AL= L_MPL_FORWARDERS in the 0x0-0xFF range preferably. See http://www.ietf.org/mail-archive/web/roll/current/msg07497.html regards, Esko ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_031DD135F9160444ABBE3B0C36CED618B767C1011DB3MPN2081MGDP_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If still relevant for the new MPL I-D, I can create = a ticket for  this: to include request for 6LoWPAN-compressible multic= ast group identifier for  ALL_MPL_FORWARDERS in the 0x0-0xFF range pre= ferably.

 

See http://www.ietf.org/mail-archive/web/roll/current/msg07497.html

 

regards,

Esko


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_031DD135F9160444ABBE3B0C36CED618B767C1011DB3MPN2081MGDP_-- From abdussalambaryun@gmail.com Wed Jan 30 12:53:46 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D31C121F888B for ; Wed, 30 Jan 2013 12:53:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f3yM5Wp82qM6 for ; Wed, 30 Jan 2013 12:53:46 -0800 (PST) Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by ietfa.amsl.com (Postfix) with ESMTP id 87CD921F886C for ; Wed, 30 Jan 2013 12:53:45 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id kp14so1294534pab.19 for ; Wed, 30 Jan 2013 12:53:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=7DD0p9VLuKWkM93ntKilHtdMXbhcfMsImYxwSfZcCPk=; b=vGubaSYxLDmxhJnIPuVC6OEpohpnH4EhDkRVOYtpF3rLN0+7ks4LL3qCHX5MsMDmlT oJQ2NcV8WPOp9ODwEzZJreyHeB1gL1Kgabnkz2K+qt6/EVM3KUrIcGFTKE/X4Jpdpm8C wvNWp6lg0nhUqByk65v/d0Ud7epzwXZDIOTGbPkgucnQxKtEl8jTrCfx11ymya/PQcRS G8p9pFeU3WPXygMA28LzV7++q3KgPdwKxaYQVMBFh964ao9diDt62nWLKUlY0r9Y8vnd 7eVQizMZRMNJDARvTlWPscxuY9eHFY3U0fCr5jNdLF9xF8lsSFh2hmHSxwrs+Ma/OQe7 L+Cg== MIME-Version: 1.0 X-Received: by 10.66.73.164 with SMTP id m4mr14577624pav.12.1359579223925; Wed, 30 Jan 2013 12:53:43 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 30 Jan 2013 12:53:43 -0800 (PST) In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B7678F@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED618B7678F@011-DB3MPN2-081.MGDPHG.emi.philips.com> Date: Wed, 30 Jan 2013 21:53:43 +0100 Message-ID: From: Abdussalam Baryun To: "Dijk, Esko" Content-Type: text/plain; charset=ISO-8859-1 Cc: "roll@ietf.org WG" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] draft-ietf-roll-trickle-mcast-03: Varying Trickle parameters per MPL Domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 20:53:46 -0000 Hi Esko, comments in line, On 1/30/13, Dijk, Esko wrote: > In Section 5.4, Trickle parameters are (implicitly?) forced to be equal for > all MPL Domains that an MPL Forwarder participates in, because only 2 sets > are supported per MPL Forwarder. Isn't this overly restrictive? Given that > the MPL Domains don't interact with each other, it would be fine if a set of > parameters is equal only within one and the same MPL Domain (so, that means > an MPL Forwarder could have different Trickle parameters for each MPL Domain > it is in.) I think having more than one domain per forwarder makes success of multicast complicated. If different trickel parameters for domains, the drafts should explain more about this issue, > > The final sentence of section 5.4 confirms this view, that only > within-Domain parameter equality is important: > "It is RECOMMENDED that all MPL Forwarder within an MPL Domain use the same > values for the Trickle Parameters above" > So it is recommended, so it can be different in one domain, which gives flexibility to the protocol in one domain, > Since a configuration method for Trickle parameters is out of scope of the > I-D, it doesn't add any extra complexity here to allow different Trickle > parameters for different MPL Domains. Also, allowing this does not seem to > break the protocol in any way (unless I overlook something.) You cannot just make every thing out of scope to avoid complexity. If the protocol allows same forwarder with different domains, I think it is important at least to identify a parameter for different domains or explain how forwards, then its config can be out of scope, but just mentioning that the protocol can allow multi-domains per forwarder, I think there should be an answer of how forwarder does such activity, My thoughts. I may be missing something because not completed my review, AB From abdussalambaryun@gmail.com Wed Jan 30 13:11:36 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE74D21F883C for ; Wed, 30 Jan 2013 13:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYe7QrOJ5AFv for ; Wed, 30 Jan 2013 13:11:35 -0800 (PST) Received: from mail-pb0-f48.google.com (mail-pb0-f48.google.com [209.85.160.48]) by ietfa.amsl.com (Postfix) with ESMTP id 39E6521F8803 for ; Wed, 30 Jan 2013 13:11:35 -0800 (PST) Received: by mail-pb0-f48.google.com with SMTP id wy12so1191975pbc.21 for ; Wed, 30 Jan 2013 13:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=6WJA1yzxx6vE92cyh40DwzrdvAYhAZ8XFGiAcvj9zKo=; b=gt7m/Ts3N4n209K2KN86rd5wUH8a2bikg2/dTjemcct1uE3T9FoRDFi4zGgwoVfGZn q7u+ZOCPNY2nZPEiJXWO0ILbQmY1eHQ3QS6fhSeTvniBW++fBP2ChNrr5K3JQlrKEomD olgabWVV5+4D4/I11VNDd1+4gN5Md6WxYc0mFrUai6VOEv2wwFENF28SPbhWFxSnhWED YJi1QDbSsY1DdcOWPaLMo3Req4r2nHXl0ITltEnwXy7jcNJ7NBhYDSzBY1l9pZDpHPdD hQZghcrKdzFCi2Iq7j2KpEi+afpv4UQUZNb3G+KhEsckTKWMmhmjGBFkDqMe1cU+E7XQ Zb0A== MIME-Version: 1.0 X-Received: by 10.66.79.202 with SMTP id l10mr14326497pax.36.1359580294897; Wed, 30 Jan 2013 13:11:34 -0800 (PST) Received: by 10.68.218.134 with HTTP; Wed, 30 Jan 2013 13:11:34 -0800 (PST) In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B76709@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED618B76709@011-DB3MPN2-081.MGDPHG.emi.philips.com> Date: Wed, 30 Jan 2013 22:11:34 +0100 Message-ID: From: Abdussalam Baryun To: "Dijk, Esko" Content-Type: text/plain; charset=ISO-8859-1 Cc: "roll@ietf.org WG" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] Seed Set use across MPL Domains (was: Re: I-D Action: draft-ietf-roll-trickle-mcast-03.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 21:11:36 -0000 Hi Esko, comments below On 1/30/13, Dijk, Esko wrote: > Thanks Jonathan and Richard for this major update to the draft. The option > to allow multiple MPL Domains to co-exist is a very useful addition. On this > topic some questions / remarks: > > 1. adding "Seed Identifier" to the section 2 Terminology could help to > clarify that a single MPL Forwarder/Seed has a single Seed Identifier. This > SeedID remains identical across multiple MPL Domains it participates in, > right? I think each domain has its different seedID increment, otherwise, we are not multicast within domains, if you mix incrementing you have considered all domains, but this is conflict with the condition that if outside domain we use IP-in-IP encapsulation. > > 2. I think for the text to be correct (sections 4.3, 6.2. 6.3, 7.3, 10.3, > 11.X e.g. - any text where Seed Set is used in fact) there needs to be a > separate Seed Set per MPL Domain a Forwarder participates in. Is this the > solution? Peter already remarked the problem for sections 4.1/11.3. > I think that is good but still needs more, not sure :( > Note that the Buffered Message Set already contains information on MPL > Domain, somewhat hidden in the 'DataMessage' object in the tuple (Section > 7.4). (The IPv6 Destination Address of this MPL Data Message identifies the > MPL Domain). So for this data structure, there's perhaps no need to add an > explicit "Domain identifier" to the tuple. But it would clarify the text to > add such element to the tuple. Why not, I think it is important parameter, AB From johui@cisco.com Wed Jan 30 14:09:58 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FE0221F8855 for ; Wed, 30 Jan 2013 14:09:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gIM0Vt7jyxsP for ; Wed, 30 Jan 2013 14:09:57 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 8B00821F883C for ; Wed, 30 Jan 2013 14:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5549; q=dns/txt; s=iport; t=1359583796; x=1360793396; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=p9LVSCHU6Wzkl0lAruX4rP/lUfDUKXN6appqzugzgyM=; b=bf5cKQHxifeS66HXbHrbAYDWyvgwF920LlabWZSgjBHjXBZdDPC+v2s3 Er1JZjxqPGZID1x2rHfJLs13/55yBHIycHOjYU1PQ/qdDe0hwK1AjwviO z9FZS9Oe8dL6PDi+dTjZNyFW+LNt0ts39LrbwaC62ZO5tk0MEZJ0FOAJM s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAMWYCVGtJV2Z/2dsb2JhbABFg3e7GBZzgh4BAQEDAQEBATc0CwUHBAIBCBEEAQEBChQJBycLFAkIAgQOBQgBiAIGBwXBfo0hAQmDAGEDlymPL4J3gW81 X-IronPort-AV: E=Sophos;i="4.84,572,1355097600"; d="scan'208";a="170799081" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-3.cisco.com with ESMTP; 30 Jan 2013 22:09:51 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r0UM9p1d027030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jan 2013 22:09:51 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 16:09:51 -0600 From: "Jonathan Hui (johui)" To: "Dijk, Esko" Thread-Topic: draft-ietf-roll-trickle-mcast-03: Varying Trickle parameters per MPL Domain Thread-Index: AQHN/zaFieptKAYN2UiL1s1N7Uefyw== Date: Wed, 30 Jan 2013 22:09:50 +0000 Message-ID: References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED618B7678F@011-DB3MPN2-081.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B7678F@011-DB3MPN2-081.MGDPHG.emi.philips.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.79.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <6ECF4F4DB39A304D80F1AFA2AFDB7C96@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org WG" Subject: Re: [Roll] draft-ietf-roll-trickle-mcast-03: Varying Trickle parameters per MPL Domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 22:09:58 -0000 Hi Esko, See below: On Jan 30, 2013, at 5:45 AM, "Dijk, Esko" wrote: > In Section 5.4, Trickle parameters are (implicitly?) forced to be equal f= or all MPL Domains that an MPL Forwarder participates in, because only 2 se= ts are supported per MPL Forwarder. Isn't this overly restrictive? Given th= at the MPL Domains don't interact with each other, it would be fine if a se= t of parameters is equal only within one and the same MPL Domain (so, that = means an MPL Forwarder could have different Trickle parameters for each MPL= Domain it is in.) Yes, having the same Trickle parameters for all MPL Domains is overly restr= ictive. > The final sentence of section 5.4 confirms this view, that only within-Do= main parameter equality is important: > "It is RECOMMENDED that all MPL Forwarder within an MPL Domain use the sa= me values for the Trickle Parameters above" Correct. That was the intention. > Since a configuration method for Trickle parameters is out of scope of th= e I-D, it doesn't add any extra complexity here to allow different Trickle = parameters for different MPL Domains. Also, allowing this does not seem to = break the protocol in any way (unless I overlook something.) How about the following change: Original from 5.4: Each MPL forwarder maintains a separate Trickle parameter set for MPL Data Message and MPL Control Message transmissions. The Trickle parameters are listed below: Change to: Each MPL Forwarder uses the following Trickle parameters for MPL Data Me= ssage and MPL Control Message transmissions. Then keep the last sentence of 5.4 to indicate that one may use different p= arameters for different MPL Domains. -- Jonathan Hui >=20 > regards, > Esko >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of J= onathan Hui (johui) > Sent: Thursday 24 January 2013 17:14 > To: roll@ietf.org WG > Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt >=20 >=20 > This update addresses all of the open tickets in the following manner: >=20 > Ticket 103: MPL Control Messages may be disabled by setting CONTROL_MESSA= GE_TIMER_EXPIRATIONS to zero. >=20 > Ticket 104: Added security considerations text. >=20 > Ticket 105: Scope is determined by the IPv6 Destination Address of MPL Da= ta Packet. >=20 > Ticket 106: Text added to always use IPv6-in-IPv6 encapsulation when mult= icast destination does not match MPL Domain Address. >=20 > Ticket 107: Multiple parameter sets are not supported at this time. >=20 > Ticket 108: Added explicit 1-bit version field. >=20 > Ticket 109: All MPL packets must be destined to the MPL Domain Address th= at identifies the MPL Domain. >=20 > Ticket 110: Not in scope. If an application subscribes to an address, it= should receive all packets destined to that address whether or not they we= re received in an MPL Data Packet. >=20 > -- > Jonathan Hui >=20 > On Jan 24, 2013, at 8:09 AM, wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Routing Over Low power and Lossy networ= ks Working Group of the IETF. >>=20 >> Title : Multicast Protocol for Low power and Lossy Networ= ks (MPL) >> Author(s) : Jonathan W. Hui >> Richard Kelsey >> Filename : draft-ietf-roll-trickle-mcast-03.txt >> Pages : 29 >> Date : 2013-01-24 >>=20 >> Abstract: >> This document specifies the Multicast Protocol for Low power and >> Lossy Networks (MPL) that provides IPv6 multicast forwarding in >> constrained networks. MPL avoids the need to construct or maintain >> any multicast forwarding topology, disseminating messages to all MPL >> forwarders in an MPL domain. MPL uses the Trickle algorithm to >> manage message transmissions for both control and data-plane >> messages. Different Trickle parameter configurations allow MPL to >> trade between dissemination latency and transmission efficiency. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-03 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-03 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 > ________________________________ > The information contained in this message may be confidential and legally= protected under applicable law. The message is intended solely for the add= ressee(s). If you are not the intended recipient, you are hereby notified t= hat any use, forwarding, dissemination, or reproduction of this message is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original message. >=20 From johui@cisco.com Wed Jan 30 14:13:40 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A363D21F86E6 for ; Wed, 30 Jan 2013 14:13:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VCrnBu5iVHdQ for ; Wed, 30 Jan 2013 14:13:37 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 623C021F8688 for ; Wed, 30 Jan 2013 14:13:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5370; q=dns/txt; s=iport; t=1359584012; x=1360793612; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=oQetpeDS1bkhOpmQzKW+7LFDgXvdPaBEnZAybrvzdME=; b=YMYbHLdMpyJH7Rmc8aFhlSJfrXM2j65PoXuMap+HU/GeROUrpSDeO/2b R0JD0OmzHbSVXVvio76cND4jmaFXVqRZ47vC+oQo9M6bNvv+HMU2yHVQo PWxGna1VziM4glfJSQbv9lnLJkK06WSjNUMDkK6IGhiO9k0SaIhVt/rky 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAEaZCVGtJV2b/2dsb2JhbABFg3e7GRZzgh4BAQEDAQEBATc0CwUHBAIBCBEEAQEBChQFBAcnCxQJCAIEDgUIARKHcAYHBcF9jSEBCYMAYQOXKY8vgneBbzU X-IronPort-AV: E=Sophos;i="4.84,572,1355097600"; d="scan'208";a="170771364" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 30 Jan 2013 22:13:28 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r0UMDS4A030789 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jan 2013 22:13:28 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.79]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Wed, 30 Jan 2013 16:13:28 -0600 From: "Jonathan Hui (johui)" To: "Dijk, Esko" Thread-Topic: Seed Set use across MPL Domains (was: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt) Thread-Index: AQHN/zcHrJUJnbyyeEC9R76ZGtKH/Q== Date: Wed, 30 Jan 2013 22:13:27 +0000 Message-ID: References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED618B76709@011-DB3MPN2-081.MGDPHG.emi.philips.com> In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B76709@011-DB3MPN2-081.MGDPHG.emi.philips.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.79.12] Content-Type: text/plain; charset="us-ascii" Content-ID: <197F4592A1A1844DBDD26589310786C6@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org WG" Subject: Re: [Roll] Seed Set use across MPL Domains (was: Re: I-D Action: draft-ietf-roll-trickle-mcast-03.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jan 2013 22:13:40 -0000 Hi Esko, Thanks again for your review. See below: On Jan 30, 2013, at 5:14 AM, "Dijk, Esko" wrote: > Thanks Jonathan and Richard for this major update to the draft. The optio= n to allow multiple MPL Domains to co-exist is a very useful addition. On t= his topic some questions / remarks: >=20 > 1. adding "Seed Identifier" to the section 2 Terminology could help to cl= arify that a single MPL Forwarder/Seed has a single Seed Identifier. This S= eedID remains identical across multiple MPL Domains it participates in, rig= ht? An MPL Forwarder may use a single Seed Identifier across all MPL Domains or= different Seed Identifiers for different MPL Domains. > 2. I think for the text to be correct (sections 4.3, 6.2. 6.3, 7.3, 10.3,= 11.X e.g. - any text where Seed Set is used in fact) there needs to be a s= eparate Seed Set per MPL Domain a Forwarder participates in. Is this the so= lution? Peter already remarked the problem for sections 4.1/11.3. Alternatively, we could add the MPL Domain Address to the MPL Seed Tuple in= Section 7.3. > Note that the Buffered Message Set already contains information on MPL Do= main, somewhat hidden in the 'DataMessage' object in the tuple (Section 7.4= ). (The IPv6 Destination Address of this MPL Data Message identifies the MP= L Domain). So for this data structure, there's perhaps no need to add an ex= plicit "Domain identifier" to the tuple. But it would clarify the text to a= dd such element to the tuple. I can add that to the next revision. -- Jonathan Hui >=20 > regards, > Esko >=20 >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of J= onathan Hui (johui) > Sent: Thursday 24 January 2013 17:14 > To: roll@ietf.org WG > Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt >=20 >=20 > This update addresses all of the open tickets in the following manner: >=20 > Ticket 103: MPL Control Messages may be disabled by setting CONTROL_MESSA= GE_TIMER_EXPIRATIONS to zero. >=20 > Ticket 104: Added security considerations text. >=20 > Ticket 105: Scope is determined by the IPv6 Destination Address of MPL Da= ta Packet. >=20 > Ticket 106: Text added to always use IPv6-in-IPv6 encapsulation when mult= icast destination does not match MPL Domain Address. >=20 > Ticket 107: Multiple parameter sets are not supported at this time. >=20 > Ticket 108: Added explicit 1-bit version field. >=20 > Ticket 109: All MPL packets must be destined to the MPL Domain Address th= at identifies the MPL Domain. >=20 > Ticket 110: Not in scope. If an application subscribes to an address, it= should receive all packets destined to that address whether or not they we= re received in an MPL Data Packet. >=20 > -- > Jonathan Hui >=20 > On Jan 24, 2013, at 8:09 AM, wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Routing Over Low power and Lossy networ= ks Working Group of the IETF. >>=20 >> Title : Multicast Protocol for Low power and Lossy Networ= ks (MPL) >> Author(s) : Jonathan W. Hui >> Richard Kelsey >> Filename : draft-ietf-roll-trickle-mcast-03.txt >> Pages : 29 >> Date : 2013-01-24 >>=20 >> Abstract: >> This document specifies the Multicast Protocol for Low power and >> Lossy Networks (MPL) that provides IPv6 multicast forwarding in >> constrained networks. MPL avoids the need to construct or maintain >> any multicast forwarding topology, disseminating messages to all MPL >> forwarders in an MPL domain. MPL uses the Trickle algorithm to >> manage message transmissions for both control and data-plane >> messages. Different Trickle parameter configurations allow MPL to >> trade between dissemination latency and transmission efficiency. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-03 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-03 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 > ________________________________ > The information contained in this message may be confidential and legally= protected under applicable law. The message is intended solely for the add= ressee(s). If you are not the intended recipient, you are hereby notified t= hat any use, forwarding, dissemination, or reproduction of this message is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original message. >=20 From esko.dijk@philips.com Thu Jan 31 00:04:28 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B698621F866F for ; Thu, 31 Jan 2013 00:04:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uir+rifxA9Ta for ; Thu, 31 Jan 2013 00:04:27 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id CCEAE21F8652 for ; Thu, 31 Jan 2013 00:04:26 -0800 (PST) Received: from mail130-co9-R.bigfish.com (10.236.132.227) by CO9EHSOBE006.bigfish.com (10.236.130.69) with Microsoft SMTP Server id 14.1.225.23; Thu, 31 Jan 2013 08:04:24 +0000 Received: from mail130-co9 (localhost [127.0.0.1]) by mail130-co9-R.bigfish.com (Postfix) with ESMTP id 4C16A3C022B; Thu, 31 Jan 2013 08:04:24 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -35 X-BigFish: VPS-35(zz217bI98dI15d6O9371I9251J936eI542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dh8275bhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h1155h) Received: from mail130-co9 (localhost.localdomain [127.0.0.1]) by mail130-co9 (MessageSwitch) id 135961946185674_25012; Thu, 31 Jan 2013 08:04:21 +0000 (UTC) Received: from CO9EHSMHS026.bigfish.com (unknown [10.236.132.251]) by mail130-co9.bigfish.com (Postfix) with ESMTP id 10C2D68005B; Thu, 31 Jan 2013 08:04:21 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS026.bigfish.com (10.236.130.36) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 31 Jan 2013 08:04:20 +0000 Received: from 011-DB3MPN2-081.MGDPHG.emi.philips.com ([169.254.1.86]) by 011-DB3MMR1-003.MGDPHG.emi.philips.com ([10.128.28.53]) with mapi id 14.02.0318.003; Thu, 31 Jan 2013 08:04:07 +0000 From: "Dijk, Esko" To: "Jonathan Hui (johui)" Thread-Topic: draft-ietf-roll-trickle-mcast-03: Varying Trickle parameters per MPL Domain Thread-Index: AQHN/vAINxczu3EJA0upl+RyiN3Xe5hibysAgACkyoA= Date: Thu, 31 Jan 2013 08:04:07 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B7697F@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED618B7678F@011-DB3MPN2-081.MGDPHG.emi.philips.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [62.140.137.95] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "roll@ietf.org WG" Subject: Re: [Roll] draft-ietf-roll-trickle-mcast-03: Varying Trickle parameters per MPL Domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 08:04:28 -0000 Hi Jonathan, agree with your suggestion. Reading again , I think the last sentence of 5.= 4 would be even better like this: It is RECOMMENDED that all MPL Forwarders use the same values within an MPL Domain for the Trickle Parameters above, as speci= fied in [RFC6206]. Because the original text one could interpret as follows: if an MPL Forward= er F1 uses parameter set P1 in a Domain D1; F1 SHOULD also use P1 in a Doma= in D2. The above sentence does not have this interpretation. regards, Esko -----Original Message----- From: Jonathan Hui (johui) [mailto:johui@cisco.com]=20 Sent: Wednesday 30 January 2013 23:10 To: Dijk, Esko Cc: roll@ietf.org WG Subject: Re: draft-ietf-roll-trickle-mcast-03: Varying Trickle parameters p= er MPL Domain Hi Esko, See below: On Jan 30, 2013, at 5:45 AM, "Dijk, Esko" wrote: > In Section 5.4, Trickle parameters are (implicitly?) forced to be=20 > equal for all MPL Domains that an MPL Forwarder participates in,=20 > because only 2 sets are supported per MPL Forwarder. Isn't this overly=20 > restrictive? Given that the MPL Domains don't interact with each=20 > other, it would be fine if a set of parameters is equal only within=20 > one and the same MPL Domain (so, that means an MPL Forwarder could=20 > have different Trickle parameters for each MPL Domain it is in.) Yes, having the same Trickle parameters for all MPL Domains is overly restr= ictive. > The final sentence of section 5.4 confirms this view, that only within-Do= main parameter equality is important: > "It is RECOMMENDED that all MPL Forwarder within an MPL Domain use the sa= me values for the Trickle Parameters above" Correct. That was the intention. > Since a configuration method for Trickle parameters is out of scope of=20 > the I-D, it doesn't add any extra complexity here to allow different=20 > Trickle parameters for different MPL Domains. Also, allowing this does=20 > not seem to break the protocol in any way (unless I overlook=20 > something.) How about the following change: Original from 5.4: Each MPL forwarder maintains a separate Trickle parameter set for MPL Data Message and MPL Control Message transmissions. The Trickle parameters are listed below: Change to: Each MPL Forwarder uses the following Trickle parameters for MPL Data Me= ssage and MPL Control Message transmissions. Then keep the last sentence of 5.4 to indicate that one may use different p= arameters for different MPL Domains. -- Jonathan Hui >=20 > regards, > Esko >=20 > -----Original Message----- > From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf=20 > Of Jonathan Hui (johui) > Sent: Thursday 24 January 2013 17:14 > To: roll@ietf.org WG > Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt >=20 >=20 > This update addresses all of the open tickets in the following manner: >=20 > Ticket 103: MPL Control Messages may be disabled by setting CONTROL_MESSA= GE_TIMER_EXPIRATIONS to zero. >=20 > Ticket 104: Added security considerations text. >=20 > Ticket 105: Scope is determined by the IPv6 Destination Address of MPL Da= ta Packet. >=20 > Ticket 106: Text added to always use IPv6-in-IPv6 encapsulation when mult= icast destination does not match MPL Domain Address. >=20 > Ticket 107: Multiple parameter sets are not supported at this time. >=20 > Ticket 108: Added explicit 1-bit version field. >=20 > Ticket 109: All MPL packets must be destined to the MPL Domain Address th= at identifies the MPL Domain. >=20 > Ticket 110: Not in scope. If an application subscribes to an address, it= should receive all packets destined to that address whether or not they we= re received in an MPL Data Packet. >=20 > -- > Jonathan Hui >=20 > On Jan 24, 2013, at 8:09 AM, wrote: >=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts direc= tories. >> This draft is a work item of the Routing Over Low power and Lossy networ= ks Working Group of the IETF. >>=20 >> Title : Multicast Protocol for Low power and Lossy Networ= ks (MPL) >> Author(s) : Jonathan W. Hui >> Richard Kelsey >> Filename : draft-ietf-roll-trickle-mcast-03.txt >> Pages : 29 >> Date : 2013-01-24 >>=20 >> Abstract: >> This document specifies the Multicast Protocol for Low power and =20 >> Lossy Networks (MPL) that provides IPv6 multicast forwarding in =20 >> constrained networks. MPL avoids the need to construct or maintain =20 >> any multicast forwarding topology, disseminating messages to all MPL =20 >> forwarders in an MPL domain. MPL uses the Trickle algorithm to =20 >> manage message transmissions for both control and data-plane =20 >> messages. Different Trickle parameter configurations allow MPL to =20 >> trade between dissemination latency and transmission efficiency. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast >>=20 >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-03 >>=20 >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-03 >>=20 >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll >=20 > ________________________________ > The information contained in this message may be confidential and legally= protected under applicable law. The message is intended solely for the add= ressee(s). If you are not the intended recipient, you are hereby notified t= hat any use, forwarding, dissemination, or reproduction of this message is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original message. >=20 From trac+roll@trac.tools.ietf.org Thu Jan 31 00:59:29 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D368021F8B6D for ; Thu, 31 Jan 2013 00:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xD5CgXZLfgOL for ; Thu, 31 Jan 2013 00:59:28 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADF821F8648 for ; Thu, 31 Jan 2013 00:59:27 -0800 (PST) Received: from localhost ([127.0.0.1]:56104 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U0pzN-00041N-Fc; Thu, 31 Jan 2013 09:59:21 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: roll Date: Thu, 31 Jan 2013 08:59:21 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/112 Message-ID: <063.468e22713e8b5bd609d1d9128c4b5ce4@trac.tools.ietf.org> X-Trac-Ticket-ID: 112 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20130131085927.5ADF821F8648@ietfa.amsl.com> Resent-Date: Thu, 31 Jan 2013 00:59:27 -0800 (PST) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: [Roll] [roll] #112: MPL IANA request section to mention 0x0-0xFF range group ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 08:59:29 -0000 #112: MPL IANA request section to mention 0x0-0xFF range group ID to include request for 6LoWPAN-compressible multicast group identifier for ALL_MPL_FORWARDERS in the 0x0-0xFF range preferably. See thread http://www.ietf.org/mail-archive/web/roll/current/msg07497.html -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- esko.dijk@philips.com | mcast@tools.ietf.org Type: enhancement | Status: new Priority: major | Milestone: Component: trickle- | Version: mcast | Keywords: Severity: In WG Last | Call | -------------------------+------------------------------------------------- Ticket URL: roll From trac+roll@trac.tools.ietf.org Thu Jan 31 01:00:38 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DFC021F863F for ; Thu, 31 Jan 2013 01:00:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ri7BCaW8nsMI for ; Thu, 31 Jan 2013 01:00:37 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id 81ACE21F863B for ; Thu, 31 Jan 2013 01:00:37 -0800 (PST) Received: from localhost ([127.0.0.1]:56244 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U0q0W-0005D2-Ue; Thu, 31 Jan 2013 10:00:32 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com X-Trac-Project: roll Date: Thu, 31 Jan 2013 09:00:32 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/112#comment:1 Message-ID: <078.0ff4703a8c2183a82edebcd7277a4b58@trac.tools.ietf.org> References: <063.468e22713e8b5bd609d1d9128c4b5ce4@trac.tools.ietf.org> X-Trac-Ticket-ID: 112 In-Reply-To: <063.468e22713e8b5bd609d1d9128c4b5ce4@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, esko.dijk@philips.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20130131090037.81ACE21F863B@ietfa.amsl.com> Resent-Date: Thu, 31 Jan 2013 01:00:37 -0800 (PST) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: Re: [Roll] [roll] #112: MPL IANA request section to mention 0x0-0xFF range group ID X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 09:00:38 -0000 #112: MPL IANA request section to mention 0x0-0xFF range group ID Changes (by esko.dijk@philips.com): * priority: major => minor -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- esko.dijk@philips.com | mcast@tools.ietf.org Type: enhancement | Status: new Priority: minor | Milestone: Component: trickle- | Version: mcast | Resolution: Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From jvasseur@cisco.com Thu Jan 31 02:42:02 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCA321F86BC for ; Thu, 31 Jan 2013 02:42:02 -0800 (PST) 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0u1X5FNJFGl for ; Thu, 31 Jan 2013 02:42:01 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 8549321F86BB for ; Thu, 31 Jan 2013 02:42:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4981; q=dns/txt; s=iport; t=1359628921; x=1360838521; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+3uNkLj5XmmBDWlcLAxQyAQsxGUP21kZaftT2Vd3iFk=; b=MPzrskKtaeBhhKsHUBLM0ovxSvs/7973vrNatvE4QVJYlo8fDK5fX3I/ p5T8ZyephH271I4/UAZ/CQkfqdie4bxhTtfRavMa7bZL6mt1qE409U3ea ftlgv693AGgS1C5LuRlZGlWxw+fjocMSvP8HrpkmIIEvil8CfxCcQ0eeG c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqwFAAdJClGtJV2a/2dsb2JhbABFrHaJEwGJFhZzgh8BAQQBAQFrCxACAQgEHh0HJwsUEQIEDgUIiAkMwgWNIoMJYQOXLo8wgneBZiMBGg X-IronPort-AV: E=Sophos;i="4.84,575,1355097600"; d="scan'208,217";a="170982844" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 31 Jan 2013 10:42:01 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r0VAg19d028792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 31 Jan 2013 10:42:01 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.64]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Thu, 31 Jan 2013 04:42:00 -0600 From: "JP Vasseur (jvasseur)" To: Abdussalam Baryun Thread-Topic: [Roll] definition of sleepy node Thread-Index: AQHN/5+ZgMkErc4YM06OsbUF+Z2e7g== Date: Thu, 31 Jan 2013 10:42:00 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A772324DDB5@xmb-rcd-x02.cisco.com> References: <50FEE333.5080706@saloits.com> <6366.1358887999@sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.98.78] Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A772324DDB5xmbrcdx02ciscoc_" MIME-Version: 1.0 Cc: "" Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 10:42:02 -0000 --_000_03B78081B371D44390ED6E7BADBB4A772324DDB5xmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Seems like we have a consensus for: Sleepy Node A sleepy node is a node that may sometimes go into a sleep mode (i.e. go in= to a low power state to conserve power) and temporarily suspend protocol co= mmunication. A sleepy node may also sometimes remain in a fully powered on= state where it has the capability to perform RPL protocol communication. Non-Sleepy Node A non-sleepy node is a node that always remains in a fully powered on state= (i.e. always awake) where it has the capability to perform RPL protocol co= mmunication. Added to draft-ietf-roll-terminology-10. Thanks. JP. On Jan 22, 2013, at 4:36 PM, Abdussalam Baryun wrote: +1 AB On 1/22/13, Michael Richardson > wrote: Please be aware that the definition of sleepy node need not be pendantically precise. The purpose of the glossary of terms is mostly so that when discussing LLNs with non-LLN network specialists that we give them an idea what this could mean, not that we find do LLN taxonomy. -- Michael Richardson >, S= andelman Software Works IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_03B78081B371D44390ED6E7BADBB4A772324DDB5xmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable Seems like we have a consensus for: 

Sleepy Node
A sleepy node is a node that may sometimes go into a sleep mode (i.e. go in=
to a low power state to conserve power) and temporarily suspend protocol co=
mmunication.  A sleepy node may also sometimes remain in a fully powered on=
 state where it has the capability to perform RPL protocol communication.

Non-Sleepy Node
A non-sleepy node is a node that always remains in a fully powered on state=
 (i.e. always awake) where it has the capability to perform RPL protocol co=
mmunication.

Added to draft-ietf-roll-terminology-10.

Thanks.

JP.

On Jan 22, 2013, at 4:36 PM, Abdussalam Baryun wrote:

+1

AB

On 1/22/13, Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Please be aware that the definition of sleepy nod= e need not be
pendantically precise.  The purpose of the g= lossary of terms is
mostly so that when discussing LLNs with non-LLN = network specialists
that we give them an idea what this could mean, n= ot that we find do
LLN taxonomy.





--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Wo= rks
IETF ROLL WG co-chair.    http://datatracker.ietf.o= rg/wg/roll/charter/


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

--_000_03B78081B371D44390ED6E7BADBB4A772324DDB5xmbrcdx02ciscoc_-- From abdussalambaryun@gmail.com Thu Jan 31 02:55:43 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EAF421F86A8 for ; Thu, 31 Jan 2013 02:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.59 X-Spam-Level: X-Spam-Status: No, score=-3.59 tagged_above=-999 required=5 tests=[AWL=0.009, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HMnwLvyyr00m for ; Thu, 31 Jan 2013 02:55:42 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id CA30621F869B for ; Thu, 31 Jan 2013 02:55:41 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so2624267wib.7 for ; Thu, 31 Jan 2013 02:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=AuS0mYWrbT7hoPCOnYH6mcPsi79tQPrnxGLLHMHPsIA=; b=u8YGb/IoH0/J9i0u3YnKGlH5sKk/9js4TM3A3Ucy6U64zoCbrEeLZR1TLTUQhdo7nO C1A5dQtXJwHezdnYZ463E+dPnBzcNxGLw5VgJcpvZansh2XpUGKyGOvMa7sbjbshmSea 6Zg6rzJHknG4pqcvYci4txYk5YObOF7te0w/LOefSeDGg0rgx/A+dopYpKmCQr27ZjYf 5aY8WGpdS5rxxKs/uVz2DHyu4Gq9cztZDDGt18ifsfzJ/qKRoxAePLGSMwL26nybXSm1 IghXp90rkjnRlNc8BuToH7Y3uExHyC2slO++3ah9uHHAHkxT0HX2CEzA4MANc6hZBZfC /mAQ== MIME-Version: 1.0 X-Received: by 10.180.86.36 with SMTP id m4mr14242972wiz.5.1359629740939; Thu, 31 Jan 2013 02:55:40 -0800 (PST) Received: by 10.180.14.33 with HTTP; Thu, 31 Jan 2013 02:55:40 -0800 (PST) In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B7697F@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED618B7678F@011-DB3MPN2-081.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618B7697F@011-DB3MPN2-081.MGDPHG.emi.philips.com> Date: Thu, 31 Jan 2013 11:55:40 +0100 Message-ID: From: Abdussalam Baryun To: "Dijk, Esko" Content-Type: text/plain; charset=ISO-8859-1 Cc: "roll@ietf.org WG" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] draft-ietf-roll-trickle-mcast-03: Varying Trickle parameters per MPL Domain X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 10:55:43 -0000 +1 AB On 1/31/13, Dijk, Esko wrote: > Hi Jonathan, > > agree with your suggestion. Reading again , I think the last sentence of 5.4 > would be even better like this: > > It is RECOMMENDED that all MPL Forwarders use the > same values within an MPL Domain for the Trickle Parameters above, as > specified in > [RFC6206]. > > Because the original text one could interpret as follows: if an MPL > Forwarder F1 uses parameter set P1 in a Domain D1; F1 SHOULD also use P1 in > a Domain D2. > The above sentence does not have this interpretation. > > regards, > Esko > > -----Original Message----- > From: Jonathan Hui (johui) [mailto:johui@cisco.com] > Sent: Wednesday 30 January 2013 23:10 > To: Dijk, Esko > Cc: roll@ietf.org WG > Subject: Re: draft-ietf-roll-trickle-mcast-03: Varying Trickle parameters > per MPL Domain > > > Hi Esko, > > See below: > > On Jan 30, 2013, at 5:45 AM, "Dijk, Esko" wrote: > >> In Section 5.4, Trickle parameters are (implicitly?) forced to be >> equal for all MPL Domains that an MPL Forwarder participates in, >> because only 2 sets are supported per MPL Forwarder. Isn't this overly >> restrictive? Given that the MPL Domains don't interact with each >> other, it would be fine if a set of parameters is equal only within >> one and the same MPL Domain (so, that means an MPL Forwarder could >> have different Trickle parameters for each MPL Domain it is in.) > > Yes, having the same Trickle parameters for all MPL Domains is overly > restrictive. > >> The final sentence of section 5.4 confirms this view, that only >> within-Domain parameter equality is important: >> "It is RECOMMENDED that all MPL Forwarder within an MPL Domain use the >> same values for the Trickle Parameters above" > > Correct. That was the intention. > >> Since a configuration method for Trickle parameters is out of scope of >> the I-D, it doesn't add any extra complexity here to allow different >> Trickle parameters for different MPL Domains. Also, allowing this does >> not seem to break the protocol in any way (unless I overlook >> something.) > > How about the following change: > > Original from 5.4: > > Each MPL forwarder maintains a separate Trickle parameter set for MPL > Data Message and MPL Control Message transmissions. The Trickle > parameters are listed below: > > Change to: > > Each MPL Forwarder uses the following Trickle parameters for MPL Data > Message > and MPL Control Message transmissions. > > Then keep the last sentence of 5.4 to indicate that one may use different > parameters for different MPL Domains. > > -- > Jonathan Hui > >> >> regards, >> Esko >> >> -----Original Message----- >> From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf >> Of Jonathan Hui (johui) >> Sent: Thursday 24 January 2013 17:14 >> To: roll@ietf.org WG >> Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt >> >> >> This update addresses all of the open tickets in the following manner: >> >> Ticket 103: MPL Control Messages may be disabled by setting >> CONTROL_MESSAGE_TIMER_EXPIRATIONS to zero. >> >> Ticket 104: Added security considerations text. >> >> Ticket 105: Scope is determined by the IPv6 Destination Address of MPL >> Data Packet. >> >> Ticket 106: Text added to always use IPv6-in-IPv6 encapsulation when >> multicast destination does not match MPL Domain Address. >> >> Ticket 107: Multiple parameter sets are not supported at this time. >> >> Ticket 108: Added explicit 1-bit version field. >> >> Ticket 109: All MPL packets must be destined to the MPL Domain Address >> that identifies the MPL Domain. >> >> Ticket 110: Not in scope. If an application subscribes to an address, it >> should receive all packets destined to that address whether or not they >> were received in an MPL Data Packet. >> >> -- >> Jonathan Hui >> >> On Jan 24, 2013, at 8:09 AM, wrote: >> >>> >>> A New Internet-Draft is available from the on-line Internet-Drafts >>> directories. >>> This draft is a work item of the Routing Over Low power and Lossy >>> networks Working Group of the IETF. >>> >>> Title : Multicast Protocol for Low power and Lossy >>> Networks (MPL) >>> Author(s) : Jonathan W. Hui >>> Richard Kelsey >>> Filename : draft-ietf-roll-trickle-mcast-03.txt >>> Pages : 29 >>> Date : 2013-01-24 >>> >>> Abstract: >>> This document specifies the Multicast Protocol for Low power and >>> Lossy Networks (MPL) that provides IPv6 multicast forwarding in >>> constrained networks. MPL avoids the need to construct or maintain >>> any multicast forwarding topology, disseminating messages to all MPL >>> forwarders in an MPL domain. MPL uses the Trickle algorithm to >>> manage message transmissions for both control and data-plane >>> messages. Different Trickle parameter configurations allow MPL to >>> trade between dissemination latency and transmission efficiency. >>> >>> >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast >>> >>> There's also a htmlized version available at: >>> http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-03 >>> >>> A diff from the previous version is available at: >>> http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-trickle-mcast-03 >>> >>> >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>> >>> _______________________________________________ >>> 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 >> >> ________________________________ >> The information contained in this message may be confidential and legally >> protected under applicable law. The message is intended solely for the >> addressee(s). If you are not the intended recipient, you are hereby >> notified that any use, forwarding, dissemination, or reproduction of this >> message is strictly prohibited and may be unlawful. If you are not the >> intended recipient, please contact the sender by return e-mail and destroy >> all copies of the original message. >> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From abdussalambaryun@gmail.com Thu Jan 31 02:58:43 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B6321F8650 for ; Thu, 31 Jan 2013 02:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTnkmNakWv+K for ; Thu, 31 Jan 2013 02:58:42 -0800 (PST) Received: from mail-we0-x22e.google.com (mail-we0-x22e.google.com [IPv6:2a00:1450:400c:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 4168721F8673 for ; Thu, 31 Jan 2013 02:58:42 -0800 (PST) Received: by mail-we0-f174.google.com with SMTP id r6so1973807wey.19 for ; Thu, 31 Jan 2013 02:58:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=NFPbMg3Vdlu3cswSgxsrGJfsx1VZ/r4pAlmhmRyLrPg=; b=RquotyzQwFfP0bTk1N0OcbdUeQOb02qLgJL0N/Y32+R5ATOixmxQjwWOTQ1w5oVjys sJWPJqXknmZZtXf/cVn/Y3ls5AYSiElCLuyjNHJQBw9oWGiUWyJlugrLnSidOGoHuKgz YmNyIliVk6t4nz80LQHavnYXmx2FnlLLY+U9ES3GLUJdDbbxTRc5hZ1SVLtNQ+aXyx+g dxsJdpnN8VAP3U1q/ytXXLwB55vgDMtt8xnrGv7+npP4onn4F0TF1bnFiQhsdROge6Zj tnUkuUfkl7FIONdV5Nwq9X9yTTIp8+maeFMZc7srvoX2+aYx08h26MHszZygwq1pj7Ts XJ8w== MIME-Version: 1.0 X-Received: by 10.180.86.36 with SMTP id m4mr14260839wiz.5.1359629921183; Thu, 31 Jan 2013 02:58:41 -0800 (PST) Received: by 10.180.14.33 with HTTP; Thu, 31 Jan 2013 02:58:41 -0800 (PST) In-Reply-To: <03B78081B371D44390ED6E7BADBB4A772324DDB5@xmb-rcd-x02.cisco.com> References: <50FEE333.5080706@saloits.com> <6366.1358887999@sandelman.ca> <03B78081B371D44390ED6E7BADBB4A772324DDB5@xmb-rcd-x02.cisco.com> Date: Thu, 31 Jan 2013 11:58:41 +0100 Message-ID: From: Abdussalam Baryun To: "JP Vasseur (jvasseur)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "" Subject: Re: [Roll] definition of sleepy node X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 10:58:43 -0000 +1 AB On 1/31/13, JP Vasseur (jvasseur) wrote: > Seems like we have a consensus for: > > > Sleepy Node > A sleepy node is a node that may sometimes go into a sleep mode (i.e. go > into a low power state to conserve power) and temporarily suspend protocol > communication. A sleepy node may also sometimes remain in a fully powered > on state where it has the capability to perform RPL protocol communication. > > > Non-Sleepy Node > A non-sleepy node is a node that always remains in a fully powered on state > (i.e. always awake) where it has the capability to perform RPL protocol > communication. > > > Added to draft-ietf-roll-terminology-10. > > Thanks. > > JP. > > On Jan 22, 2013, at 4:36 PM, Abdussalam Baryun wrote: > > +1 > > AB > > On 1/22/13, Michael Richardson > > wrote: > > Please be aware that the definition of sleepy node need not be > pendantically precise. The purpose of the glossary of terms is > mostly so that when discussing LLNs with non-LLN network specialists > that we give them an idea what this could mean, not that we find do > LLN taxonomy. > > > > > > -- > Michael Richardson >, > Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > From abdussalambaryun@gmail.com Thu Jan 31 03:06:11 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E9D421F86C3 for ; Thu, 31 Jan 2013 03:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNy96luqoVKz for ; Thu, 31 Jan 2013 03:06:10 -0800 (PST) Received: from mail-we0-x232.google.com (we-in-x0232.1e100.net [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 97DF321F86C2 for ; Thu, 31 Jan 2013 03:06:10 -0800 (PST) Received: by mail-we0-f178.google.com with SMTP id x48so1916093wey.23 for ; Thu, 31 Jan 2013 03:06:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=VF3rME2khFLB2CDtBwI/+izc2TwJl040rpHfwOPGw/o=; b=usznuoSB5YPQxqLIQkdtknzGkhIrITixB+NhLp8sdKTmI+QfGxVVV/3XcCVx0hBCpm o0Vk4cXD5AsOl6lFLH+ZocRJOBg/A+g1/ocbQ/FTyK67xQ4SN4Uxn9Z5p58YQGYiUXtV I3jHNdX2QxhW7dGWwYAcVhb4cLg4NE2JUqeFJbGGjCXOOYC2vd1c6ao2eCSQ74vS9tA8 WB1S6+xHUpcitd0MevwShH5+SATdQBfXlhC7ZpFwXH8i0yig9FQuIhxE5WFzYVxfG/uu JXeyHB/e/Jqhbh6QRaG5tVKoWnBjCE8tYSAjmmGErluYQMaaxy8xU+2nawhql6Zy4IQr wlFA== MIME-Version: 1.0 X-Received: by 10.194.20.231 with SMTP id q7mr14485078wje.44.1359630362614; Thu, 31 Jan 2013 03:06:02 -0800 (PST) Received: by 10.180.14.33 with HTTP; Thu, 31 Jan 2013 03:06:02 -0800 (PST) In-Reply-To: References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED618B76709@011-DB3MPN2-081.MGDPHG.emi.philips.com> Date: Thu, 31 Jan 2013 12:06:02 +0100 Message-ID: From: Abdussalam Baryun To: "Jonathan Hui (johui)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "roll@ietf.org WG" Subject: Re: [Roll] Seed Set use across MPL Domains (was: Re: I-D Action: draft-ietf-roll-trickle-mcast-03.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 11:06:11 -0000 On 1/30/13, Jonathan Hui (johui) wrote: > Alternatively, we could add the MPL Domain Address to the MPL Seed Tuple in > Section 7.3. Yes agree the alternative is a MUST, if we want to make MPL allow multi-domain forwarding, but still think an explaination of such activity will be helpful for reader/implementors, AB From abdussalambaryun@gmail.com Thu Jan 31 03:37:14 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD0B921F8496 for ; Thu, 31 Jan 2013 03:37:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ErqRJ9kzDfdf for ; Thu, 31 Jan 2013 03:37:14 -0800 (PST) Received: from mail-we0-x22f.google.com (we-in-x022f.1e100.net [IPv6:2a00:1450:400c:c03::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED4721F8446 for ; Thu, 31 Jan 2013 03:37:14 -0800 (PST) Received: by mail-we0-f175.google.com with SMTP id x8so2040195wey.34 for ; Thu, 31 Jan 2013 03:37:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to:cc :content-type; bh=OBfWSU2CW71gnuwDZIreUjeFA0ORwyxJI+nBaa00dM8=; b=ZPllopfJi/8W9Cpk/HyLtKryf41u5LqfXDrb7jyoY3GGzE7gWvP2bMbWmW2vK0MM2A vRF7TrC5jcbbGhVA0YNXSPnqVxrEm/KSLoB2rIf1NES90kqGkdF3iNIL2xmdzwXhh+D8 Sh5ny+3+OIyOyM11sI892Aqg2QcCs964n+Dli3Uc31hcuxhiScOy+NK5FjqLYmYgpN/N 9+Nmj7z27yWT8JVtubxlPahi2Z9LUv+TRqjnVrKSQCZGnSEq6p/4JV27TzLnRVhL+st4 ROYSUexS3HyyWBQG5G4OjyUo3q395trPXnoqOrcLAowZ00yondi1xfu45BtcFB/IVDeu kxcQ== MIME-Version: 1.0 X-Received: by 10.194.20.231 with SMTP id q7mr14695400wje.44.1359632233389; Thu, 31 Jan 2013 03:37:13 -0800 (PST) Received: by 10.180.14.33 with HTTP; Thu, 31 Jan 2013 03:37:13 -0800 (PST) Date: Thu, 31 Jan 2013 12:37:13 +0100 Message-ID: From: Abdussalam Baryun To: "Jonathan Hui (johui)" Content-Type: text/plain; charset=ISO-8859-1 Cc: "roll@ietf.org WG" Subject: [Roll] Seed Set and domain-address used across MPL multi-Domains (was: Re: I-D Action: draft-ietf-roll-trickle-mcast-03.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 11:37:15 -0000 Hi Jonathan, The example of co-exist domains (the example of Esko) is not clear in the draft, is there a condition for this co-exist, I think the scenario needs more condition explain, because we are already using IP-in-IP encapsulation (see 10.1) for multicast outside the forwarder's domain to its neighbor domains. There may be nodes exist in both/all domains but other are in one domain only, which they may receive the messages. Therefore, if forwarding from one forwarder to another there should be some condition that the co-exist-domains-MPL-forwarder and/or the one-domain-MPL-forwarder should follow, Does that make sense? please advise, AB On 1/31/13, Abdussalam Baryun wrote: > On 1/30/13, Jonathan Hui (johui) wrote: >> Alternatively, we could add the MPL Domain Address to the MPL Seed Tuple >> in >> Section 7.3. > > Yes agree the alternative is a MUST, if we want to make MPL allow > multi-domain forwarding, but still think an explaination of such > activity will be helpful for reader/implementors, > > AB > From trac+roll@trac.tools.ietf.org Thu Jan 31 04:07:26 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C970421F854D for ; Thu, 31 Jan 2013 04:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zs4HoawHTv-o for ; Thu, 31 Jan 2013 04:07:26 -0800 (PST) Received: from grenache.tools.ietf.org (grenache.tools.ietf.org [IPv6:2a01:3f0:1:2::30]) by ietfa.amsl.com (Postfix) with ESMTP id D2BD921F8549 for ; Thu, 31 Jan 2013 04:07:14 -0800 (PST) Received: from localhost ([127.0.0.1]:41651 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U0sv4-0006ja-8F; Thu, 31 Jan 2013 13:07:06 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "roll issue tracker" X-Trac-Version: 0.12.3 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.12.3, by Edgewall Software To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, esko.dijk@philips.com X-Trac-Project: roll Date: Thu, 31 Jan 2013 12:07:06 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/roll/trac/ticket/107#comment:4 Message-ID: <073.9130f4743f1a95f8bdcf39105870caab@trac.tools.ietf.org> References: <058.d8b807f46e7601c2df8bad69d7cb737b@trac.tools.ietf.org> X-Trac-Ticket-ID: 107 In-Reply-To: <058.d8b807f46e7601c2df8bad69d7cb737b@trac.tools.ietf.org> X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: draft-ietf-roll-trickle-mcast@tools.ietf.org, mcr@sandelman.ca, esko.dijk@philips.com, roll@ietf.org X-SA-Exim-Mail-From: trac+roll@trac.tools.ietf.org X-SA-Exim-Scanned: No (on grenache.tools.ietf.org); SAEximRunCond expanded to false Resent-To: jonhui@cisco.com, richard.kelsey@silabs.com Resent-Message-Id: <20130131120725.D2BD921F8549@ietfa.amsl.com> Resent-Date: Thu, 31 Jan 2013 04:07:14 -0800 (PST) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org Subject: Re: [Roll] [roll] #107: trickle-mcast: should multiple parameter sets be supported X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 12:07:27 -0000 #107: trickle-mcast: should multiple parameter sets be supported Changes (by esko.dijk@philips.com): * status: new => closed * resolution: => fixed Comment: MPL-03 allows a Forwarder to participate in multiple MPL Domains, using a different Trickle parameter set per Domain. So I believe this satisfies the indicated requirements in the building control domain and there's no need for supporting multiple parameter sets selection in the MPL Data Message and MPL Control Message. -- -------------------------+------------------------------------------------- Reporter: | Owner: draft-ietf-roll-trickle- mcr@sandelman.ca | mcast@tools.ietf.org Type: enhancement | Status: closed Priority: major | Milestone: Component: trickle- | Version: mcast | Resolution: fixed Severity: In WG Last | Call | Keywords: | -------------------------+------------------------------------------------- Ticket URL: roll From esko.dijk@philips.com Thu Jan 31 07:40:19 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B33E21F8550 for ; Thu, 31 Jan 2013 07:40:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[AWL=0.901, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W8l5K4gWO2ga for ; Thu, 31 Jan 2013 07:40:18 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 14DD321F854B for ; Thu, 31 Jan 2013 07:40:17 -0800 (PST) Received: from mail221-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE004.bigfish.com (10.43.70.54) with Microsoft SMTP Server id 14.1.225.23; Thu, 31 Jan 2013 15:40:16 +0000 Received: from mail221-ch1 (localhost [127.0.0.1]) by mail221-ch1-R.bigfish.com (Postfix) with ESMTP id 9812D403E3; Thu, 31 Jan 2013 15:40:16 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -45 X-BigFish: VPS-45(zz217bI98dI15d6O9371I9251J936eI14e4M542I1432Ib73dMzz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h1155h) Received: from mail221-ch1 (localhost.localdomain [127.0.0.1]) by mail221-ch1 (MessageSwitch) id 1359646814613694_26643; Thu, 31 Jan 2013 15:40:14 +0000 (UTC) Received: from CH1EHSMHS027.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.253]) by mail221-ch1.bigfish.com (Postfix) with ESMTP id 8A2B5320045; Thu, 31 Jan 2013 15:40:14 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS027.bigfish.com (10.43.70.27) with Microsoft SMTP Server (TLS) id 14.1.225.23; Thu, 31 Jan 2013 15:40:13 +0000 Received: from 011-DB3MMR1-014.MGDPHG.emi.philips.com (10.128.28.98) by 011-DB3MMR1-007.MGDPHG.emi.philips.com (10.128.28.57) with Microsoft SMTP Server (TLS) id 14.2.318.3; Thu, 31 Jan 2013 15:39:31 +0000 Received: from 011-DB3MPN2-081.MGDPHG.emi.philips.com ([169.254.1.86]) by 011-DB3MMR1-014.MGDPHG.emi.philips.com ([10.128.28.98]) with mapi id 14.02.0318.003; Thu, 31 Jan 2013 15:39:31 +0000 From: "Dijk, Esko" To: "Jonathan Hui (johui)" Thread-Topic: Review draft-ietf-roll-trickle-mcast-03 (was: RE: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt) Thread-Index: AQHN/8kpv2skt5QFkku+WS6LwF7Wbg== Date: Thu, 31 Jan 2013 15:39:31 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B76C51@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.103] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com Cc: "roll@ietf.org WG" Subject: [Roll] Review draft-ietf-roll-trickle-mcast-03 (was: RE: I-D Action: draft-ietf-roll-trickle-mcast-03.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 15:40:19 -0000 Hi Jonathan, please find below my further review comments for the new MPL-03 draft. None= of these would affect current implementations, with the exception maybe of= the comment for Section 6.3 page 14. I hope this helps to improve the text. Esko Section 2. - "Seed Identifier" could be added here (as I noted before). I'm wondering = whether one MPL Forwarder incorporates multiple Seeds (for different Domain= s); or that there's only one Seed per Forwarder but with this Seed storing = potentially multiple Seed IDs. (At most one Seed ID per Domain it participa= tes in in a Seed role.) For an implementation this definition issue may not= be even relevant, though... Section 4.2 - the first bullet could mention that the generated MPL Data Message is als= o multicast. Rationale: other bullets also explicitly mention when messages= are multicast (i.e. transmitted). Section 4.3, pg. 8 - "minimum threshold maintained in the Seed Set." -> It seems "minimum threshold" should be "minimum sequence number"? If not, w= hat is the threshold? Section 5 - title: would be better "MPL Parameters" or "MPL Parameters and Constants= " since most of the definitions are not constants. If updated, also the int= ro text should be updated. - the MPL Seed Identifiers could be added , e.g. to 5.1. Each MPL Domain ne= eds to have a Seed ID configured in case the MPL Forwarder acts as a Seed f= or that Domain. - maybe to add that setting of parameters is out of scope (since RFC 6206 R= ECOMMENDS to define such mechanisms - a reader may expect such mechanisms i= n MPL?) Section 5.3 - both parameters are defined but their syntax/name not further used in the= protocol description. To be fixed? - just wondering if default values here would be appropriate? - do we allow PROACTIVE_FORWARDING and SEED_SET_LIFETIME to be set per MPL = Domain, or not? (there seems to be no reason to disallow per-domain setting= as Domains are cleanly separated) Section 6.1 - editorial "MPL Options received in which this flag is 1 MUST be dropped" = -> "Received Messages with MPL Option in which this flag is 1 MUST be droppe= d"? Section 6.2 - The MLP Seed Info array must contain at least one MPL Seed Info entry. Th= is can be a problem for MPL Forwarders that just started up with empty mess= age buffers. When the Trickle timer fires, such Forwarder may need to send = an MPL Control Message with 'empty' information in case it has no messages = buffered yet. Section 6.3, pg 13 - editorial "minimum sequence number for the MPL Seed maintained" -> "minimum sequence number for an MPL Seed maintained" ? - "Data Messages generated by the MPL Seed within the Buffered Message Set"= -> "Data Messages generated by the MPL Seed that are stored within the Buffe= red Message Set" Section 6.3, pg 14 - S field text: "0 indicates that the seed-id value is the IPv6 Source Addr= ess" -> that would be a link-local address for a Control message, hence not usabl= e as a SeedID in practice. For an MPL Data Message, a Forwarder would typic= ally need to use its global IPv6 address as the IPv6 Source, hence also as = the SeedID (when S flag is 0); so Seed IDs are defined in terms of global I= Pv6 addresses. Is this a spec error? I don't see how the S=3D0 for a MPL Co= ntrol message could be made useful right now. - editorial: text for 'buffered-mpl-messages' could (should?) point forward= to section 11.1 where the meaning of 0/1 bits is specified. Section 7.1 - Shouldn't the Local Interface Tuple contain an identifier of each interfa= ce? or was this left out because format of such IDs is implementation speci= fic. (Interface ID, AddressSet) Section 7.2 - Shouldn't the Domain Address be the first component of the MPL Domain Tup= le? (Domain Address, MPLInterfaceSet) at least the Domain Address information should be stored somewhere per Do= main, and it's not implementation-specific. The present text already suggests of course that Domain Address is stored h= ere so I'd expect it in the tuple too. Section 7.3 - "Lifetime - indicates the minimum lifetime of the Seed Set entry." -> "Lifetime - indicates the minimum remaining lifetime of the Seed Set ent= ry." ? (since the minimum lifetime itself would be always equal to SEED_SET_LIFETI= ME?) Section 10.1 - "when they enter" -> "when these messages enter" (otherwise ambiguous) Section 11.2 - editorial "receiving nor transmitting node has new MPL Data Message." -> "receiving nor transmitting node has any new MPL Data Message to offer." -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Jon= athan Hui (johui) Sent: Thursday 24 January 2013 17:14 To: roll@ietf.org WG Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-03.txt This update addresses all of the open tickets in the following manner: Ticket 103: MPL Control Messages may be disabled by setting CONTROL_MESSAGE= _TIMER_EXPIRATIONS to zero. Ticket 104: Added security considerations text. Ticket 105: Scope is determined by the IPv6 Destination Address of MPL Data= Packet. Ticket 106: Text added to always use IPv6-in-IPv6 encapsulation when multic= ast destination does not match MPL Domain Address. Ticket 107: Multiple parameter sets are not supported at this time. Ticket 108: Added explicit 1-bit version field. Ticket 109: All MPL packets must be destined to the MPL Domain Address that= identifies the MPL Domain. Ticket 110: Not in scope. If an application subscribes to an address, it s= hould receive all packets destined to that address whether or not they were= received in an MPL Data Packet. -- Jonathan Hui On Jan 24, 2013, at 8:09 AM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Routing Over Low power and Lossy network= s Working Group of the IETF. > > Title : Multicast Protocol for Low power and Lossy Networ= ks (MPL) > Author(s) : Jonathan W. Hui > Richard Kelsey > Filename : draft-ietf-roll-trickle-mcast-03.txt > Pages : 29 > Date : 2013-01-24 > > Abstract: > This document specifies the Multicast Protocol for Low power and > Lossy Networks (MPL) that provides IPv6 multicast forwarding in > constrained networks. MPL avoids the need to construct or maintain > any multicast forwarding topology, disseminating messages to all MPL > forwarders in an MPL domain. MPL uses the Trickle algorithm to > manage message transmissions for both control and data-plane > messages. Different Trickle parameter configurations allow MPL to > trade between dissemination latency and transmission efficiency. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-trickle-mcast > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-roll-trickle-mcast-03 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-03 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > 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 ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. From Internet-Drafts@ietf.org Thu Jan 31 07:43:27 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9868521F856F; Thu, 31 Jan 2013 07:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV9JpaED31yH; Thu, 31 Jan 2013 07:43:27 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2DD21F8563; Thu, 31 Jan 2013 07:43:27 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130131154327.12223.87170.idtracker@ietfa.amsl.com> Date: Thu, 31 Jan 2013 07:43:27 -0800 Cc: roll@ietf.org Subject: [Roll] I-D ACTION:draft-ietf-roll-terminology-10.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 15:43:27 -0000 --NextPart A new Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Terminology in Low power And Lossy Networks Author(s) : J. Vasseur Filename : draft-ietf-roll-terminology Pages : 8 Date : Jan. 31, 2013 The documents defines a terminology for discussing routing requirements and solutions for networks referred to as Low power and Lossy Networks (LLN). A LLN is typically composed of many embedded devices with limited power, memory, and processing resources interconnected by a variety of links. There is a wide scope of application areas for LLNs, including industrial monitoring, building automation (e.g. Heating, Ventilating, Air Conditioning, lighting, access control, fire), connected home, healthcare, environmental monitoring, urban sensor networks, energy management, assets tracking, refrigeration. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-roll-terminology-10.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-roll-terminology"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2013-01-31074327.I-D@ietf.org> --NextPart-- From abdussalambaryun@gmail.com Thu Jan 31 08:32:29 2013 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7232921F8230 for ; Thu, 31 Jan 2013 08:32:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZBQqk85HDM0u for ; Thu, 31 Jan 2013 08:32:28 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id 5546F21F8526 for ; Thu, 31 Jan 2013 08:32:28 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so2999660wib.13 for ; Thu, 31 Jan 2013 08:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=ECFD3wjXZExDUDZ2UCgIF4t5KyiXoWjgUz07ga6zgPM=; b=IOXlsWNIwSjShPY/XHstPEek6f/+vaXwVMa15lQu2p1ykkhRmnYiBOOlJFH27kldbo IjVWMAoEhXFyRktNz7yqxPWzXRQ3xoAtkDLrAuXJQ8m3ZkQGYALoQiLEUt4xi9EnjVkb verfrWNaz8Yj8NsXV3AbOBDn46EjvQ0JlPryQvampcBlJjdUiuO/vQdRZnItD06gneb0 0MHRO6dMwRUnRlnfleJ7qsisdujsLCb3s5b4tbMVrNZWyf6gNfKdobXgtioceukalfAN qO1ltwW+o8incl61elZmG+1fE0vR8ziyGrOm32L/SUBJhIpUHRzRQ56DBV9OZDdtC9S+ /8jQ== MIME-Version: 1.0 X-Received: by 10.194.90.11 with SMTP id bs11mr16688709wjb.18.1359649947575; Thu, 31 Jan 2013 08:32:27 -0800 (PST) Received: by 10.180.14.33 with HTTP; Thu, 31 Jan 2013 08:32:27 -0800 (PST) In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B76C51@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED618B76C51@011-DB3MPN2-081.MGDPHG.emi.philips.com> Date: Thu, 31 Jan 2013 17:32:27 +0100 Message-ID: From: Abdussalam Baryun To: "Dijk, Esko" Content-Type: text/plain; charset=ISO-8859-1 Cc: "roll@ietf.org WG" , "Jonathan Hui \(johui\)" Subject: Re: [Roll] Review draft-ietf-roll-trickle-mcast-03 (was: RE: I-D Action: draft-ietf-roll-trickle-mcast-03.txt) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Jan 2013 16:32:29 -0000 Hi Esko, and Jonathan, comments in line; On 1/31/13, Dijk, Esko wrote: > - maybe to add that setting of parameters is out of scope (since RFC 6206 > RECOMMENDS to define such mechanisms - a reader may expect such mechanisms > in MPL?) Why not having a default and/or initial values of both the constants and parameters for MPL, as protocols usually have stated within its I-D > > Section 5.3 > - both parameters are defined but their syntax/name not further used in the > protocol description. To be fixed? > - just wondering if default values here would be appropriate? Yes, I think so, > Section 6.2 > - The MLP Seed Info array must contain at least one MPL Seed Info entry. > This can be a problem for MPL Forwarders that just started up with empty > message buffers. When the Trickle timer fires, such Forwarder may need to > send an MPL Control Message with 'empty' information in case it has no > messages buffered yet. Agree, so we need to know initial MPL states, or define > > Section 7.1 > - Shouldn't the Local Interface Tuple contain an identifier of each > interface? or was this left out because format of such IDs is implementation > specific. > (Interface ID, AddressSet) I agree with you if MPL is doing multicast, but when discussing with authors they inform me that MPL only broadcast to interfaces, but by using Trickel the multicast is done. However, I prefer that we can put your suggestion as a second mode of MPL multicast. > > Section 7.2 > - Shouldn't the Domain Address be the first component of the MPL Domain > Tuple? > (Domain Address, MPLInterfaceSet) don't think so, > The present text already suggests of course that Domain Address is stored > here so I'd expect it in the tuple too. Yes, me too, AB