From internet-drafts@ietf.org Sun Feb 3 12:49: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 6939821F87A9; Sun, 3 Feb 2013 12:49:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 usF173GChyNO; Sun, 3 Feb 2013 12:49:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D2421F881E; Sun, 3 Feb 2013 12:49:32 -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: <20130203204932.29839.41892.idtracker@ietfa.amsl.com> Date: Sun, 03 Feb 2013 12:49:32 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-16.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 20:49:33 -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 : Reactive Discovery of Point-to-Point Routes in Low Power= and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-16.txt Pages : 36 Date : 2013-02-03 Abstract: This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-p2p-rpl-16 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=7390d41c4=mukul@uwm.edu Sun Feb 3 13:13: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 9FBCF21F853E for ; Sun, 3 Feb 2013 13:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 CEakJZgh7Hvy for ; Sun, 3 Feb 2013 13:13:33 -0800 (PST) Received: from ip3mta.uwm.edu (ip3mta.uwm.edu [129.89.7.192]) by ietfa.amsl.com (Postfix) with ESMTP id F1F0F21F8488 for ; Sun, 3 Feb 2013 13:13:32 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEANPRDlF/AAAB/2dsb2JhbABEg3eCUbkBgxIBAQEEAQEBIEsXDxEEAQEDAg0ZAikoCAYTCRCHeAcFnj+OVYhEiQqBI4wIgxSBEwOIZo05gR2PNIMbgUckGg Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id EAC9D2A0F16 for ; Sun, 3 Feb 2013 15:13:31 -0600 (CST) X-Virus-Scanned: amavisd-new at Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qe5MmDdhO9wn for ; Sun, 3 Feb 2013 15:13:31 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 772352A0F11 for ; Sun, 3 Feb 2013 15:13:31 -0600 (CST) Date: Sun, 3 Feb 2013 15:13:31 -0600 (CST) From: Mukul Goyal To: roll Message-ID: <368544206.189079.1359926011411.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20130203204932.29839.41892.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 Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-16.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 03 Feb 2013 21:13:33 -0000 Hi all This version incorporates some editorial changes made in response to the comments we received as part of the IESG review. The only real change is the following: The Life Time field in the P2P Route Discovery Option inside a DIO now indicates the _exact_ life time of the temporary DAG created for a P2P-RPL route discovery. Earlier, this field indicated the _minimum_ life time of the temporary DAG. This change means that a router MUST detach from the temporary DAG once the duration of its membership in the temporary DAG has reached the Life Time duration listed in the P2P Route Discovery Option. This change was required because there was a need to know precisely when does a route discovery complete so that the RPLInstanceID used in this route discovery can be reused in another route discovery. Thanks Mukul ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Sunday, February 3, 2013 2:49:32 PM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-16.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks Working Group of the IETF. Title : Reactive Discovery of Point-to-Point Routes in Low Power and Lossy Networks Author(s) : Mukul Goyal Emmanuel Baccelli Matthias Philipp Anders Brandt Jerald Martocci Filename : draft-ietf-roll-p2p-rpl-16.txt Pages : 36 Date : 2013-02-03 Abstract: This document specifies a point-to-point route discovery mechanism, complementary to the RPL core functionality. This mechanism allows an IPv6 router to discover "on demand" routes to one or more IPv6 routers in the LLN such that the discovered routes meet specified metrics constraints. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-p2p-rpl There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-p2p-rpl-16 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-p2p-rpl-16 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 esko.dijk@philips.com Mon Feb 4 05:17: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 B984821F847B for ; Mon, 4 Feb 2013 05:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.149 X-Spam-Level: X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=0.450, 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 sftFHtpHPdeA for ; Mon, 4 Feb 2013 05:17:23 -0800 (PST) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe004.messaging.microsoft.com [216.32.180.14]) by ietfa.amsl.com (Postfix) with ESMTP id AFC4521F8472 for ; Mon, 4 Feb 2013 05:17:22 -0800 (PST) Received: from mail63-va3-R.bigfish.com (10.7.14.246) by VA3EHSOBE008.bigfish.com (10.7.40.28) with Microsoft SMTP Server id 14.1.225.23; Mon, 4 Feb 2013 13:17:21 +0000 Received: from mail63-va3 (localhost [127.0.0.1]) by mail63-va3-R.bigfish.com (Postfix) with ESMTP id 19C174A013F; Mon, 4 Feb 2013 13:17: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: -36 X-BigFish: VPS-36(zz217bI98dI15d6O9371I9251J936eI542I1432I111aIzz1ee6h1de0h1202h1e76h1d1ah1d2ahzz1033IL17326ah8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h1155h) Received: from mail63-va3 (localhost.localdomain [127.0.0.1]) by mail63-va3 (MessageSwitch) id 1359983838941825_17128; Mon, 4 Feb 2013 13:17:18 +0000 (UTC) Received: from VA3EHSMHS038.bigfish.com (unknown [10.7.14.250]) by mail63-va3.bigfish.com (Postfix) with ESMTP id D7C35300609; Mon, 4 Feb 2013 13:17:18 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS038.bigfish.com (10.7.99.48) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 4 Feb 2013 13:17:18 +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; Mon, 4 Feb 2013 13:17:03 +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/uu9Eoo2YugjFkKDyYhvrPtHxJhicDaAgAdEO+A= Date: Mon, 4 Feb 2013 13:17:03 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B771A3@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED618B76709@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: [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: 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: Mon, 04 Feb 2013 13:17:24 -0000 > Alternatively, we could add the MPL Domain Address to the MPL Seed Tuple = in Section 7.3. That sounds also good to me. For some of the text on "Seed Set" the notion = of MPL Domain needs to be included, in that case. For example in 10.3 "If a Seed Set entry exists for the MPL Seed ..."=20 of course a Seed Set entry for the MPL Seed *for a specific MPL Domain* sho= uld be checked. (Since a Seed ID could be in use across multiple Domains, o= nly one of which is to be considered in the processing indicated in the quo= ted text.) Esko -----Original Message----- From: Jonathan Hui (johui) [mailto:johui@cisco.com]=20 Sent: Wednesday 30 January 2013 23:13 To: Dijk, Esko Cc: roll@ietf.org WG Subject: Re: Seed Set use across MPL Domains (was: Re: [Roll] I-D Action: d= raft-ietf-roll-trickle-mcast-03.txt) 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=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 esko.dijk@philips.com Mon Feb 4 05:35: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 BAF4F21F863F for ; Mon, 4 Feb 2013 05:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.299 X-Spam-Level: X-Spam-Status: No, score=-3.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 NWQ9kffIYBP2 for ; Mon, 4 Feb 2013 05:35:07 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id 009E121F863C for ; Mon, 4 Feb 2013 05:35:06 -0800 (PST) Received: from mail159-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE006.bigfish.com (10.43.70.56) with Microsoft SMTP Server id 14.1.225.23; Mon, 4 Feb 2013 13:35:06 +0000 Received: from mail159-ch1 (localhost [127.0.0.1]) by mail159-ch1-R.bigfish.com (Postfix) with ESMTP id 17CA544036E; Mon, 4 Feb 2013 13:35:06 +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: -34 X-BigFish: VPS-34(zzbb2dI217bI98dI15d6O9251J542I1432Izz1ee6h1de0h1202h1e76h1d1ah1d2ahz8dhz1033IL8275bh8275dhz2dh2a8h668h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h1155h) Received: from mail159-ch1 (localhost.localdomain [127.0.0.1]) by mail159-ch1 (MessageSwitch) id 1359984903926684_26184; Mon, 4 Feb 2013 13:35:03 +0000 (UTC) Received: from CH1EHSMHS002.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236]) by mail159-ch1.bigfish.com (Postfix) with ESMTP id E03862000A6; Mon, 4 Feb 2013 13:35:03 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS002.bigfish.com (10.43.70.2) with Microsoft SMTP Server (TLS) id 14.1.225.23; Mon, 4 Feb 2013 13:35:03 +0000 Received: from 011-DB3MMR1-018.MGDPHG.emi.philips.com (10.128.28.104) by 011-DB3MMR1-007.MGDPHG.emi.philips.com (10.128.28.57) with Microsoft SMTP Server (TLS) id 14.2.318.3; Mon, 4 Feb 2013 13:34:40 +0000 Received: from 011-DB3MPN2-081.MGDPHG.emi.philips.com ([169.254.1.86]) by 011-DB3MMR1-018.MGDPHG.emi.philips.com ([10.128.28.104]) with mapi id 14.02.0318.003; Mon, 4 Feb 2013 13:34:39 +0000 From: "Dijk, Esko" To: Abdussalam Baryun Thread-Topic: [Roll] Review draft-ietf-roll-trickle-mcast-03 (was: RE: I-D Action: draft-ietf-roll-trickle-mcast-03.txt) Thread-Index: AQHN/9CPAu2b9zEK1UG4vnCjqo0Q85hptFNg Date: Mon, 4 Feb 2013 13:34:39 +0000 Message-ID: <031DD135F9160444ABBE3B0C36CED618B771C6@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED618B76C51@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: [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" , "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: Mon, 04 Feb 2013 13:35:07 -0000 Hello, > 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 That's possible, if we have some 'typical' use case for which reasonable Tr= ickle parameters are known. On second thought: in practice the SEED_SET_LIFETIME selection may be linke= d to the Imin/Imax selection. So giving a default for only SEED_SET_LIFETIM= E may not work. E.g. SEED_SET_LIFETIME =3D 100 ms, and Imin=3D5 sec., would= not really work well I assume. regards, Esko -----Original Message----- From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: Thursday 31 January 2013 17:32 To: Dijk, Esko Cc: Jonathan Hui (johui); roll@ietf.org WG Subject: Re: [Roll] Review draft-ietf-roll-trickle-mcast-03 (was: RE: I-D A= ction: draft-ietf-roll-trickle-mcast-03.txt) 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 pa= rameters 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 author= s they inform me that MPL only broadcast to interfaces, but by using Tricke= l 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 ________________________________ 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 abdussalambaryun@gmail.com Mon Feb 4 09: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 BB9F221F8A99 for ; Mon, 4 Feb 2013 09:49:37 -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, HTML_MESSAGE=0.001, 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 IlSVPA-fqusn for ; Mon, 4 Feb 2013 09:49:37 -0800 (PST) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id EE61921F8A94 for ; Mon, 4 Feb 2013 09:49:36 -0800 (PST) Received: by mail-we0-f176.google.com with SMTP id s43so4863894wey.21 for ; Mon, 04 Feb 2013 09:49:36 -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=q6W3RNyAXGKo7nLjk9CdvAsTTF0w7j3qvEOIYHzu/bw=; b=Ode5tWWnq736Wr+1Eedli+0BukEglouP2de4ZNqATs9yBctscKO8wt7A//D/eupsZZ Fn41LSfKB8iBBwJpvnCxAw4Jua7+LJ/6BMHA3ABMxqI+3Gfn82+8a3+5TClbMbbbGSyX Itd8OgdsZWFZ+6c0qJ1TNLDqZlRbp+2xgpZuJJj5IZoyRKSV7wVmm0qtJ3aXr3k9scG0 U/C1nRxLq9bG46JL7f1ZgeqUuas6rraR04ArKu5ODPD+w+jpv2OXs5Nhv/vOvjX9YYMc OuOKNH5tQQAlAnXXmCBuIRoUelSFSXbu66um/7Ulc7cT93hQ2OOszcRZlQP0qHovHvjM qjPg== MIME-Version: 1.0 X-Received: by 10.180.82.9 with SMTP id e9mr12296478wiy.1.1360000175921; Mon, 04 Feb 2013 09:49:35 -0800 (PST) Received: by 10.180.101.70 with HTTP; Mon, 4 Feb 2013 09:49:35 -0800 (PST) In-Reply-To: <031DD135F9160444ABBE3B0C36CED618B771C6@011-DB3MPN2-081.MGDPHG.emi.philips.com> References: <20130124160907.4820.99930.idtracker@ietfa.amsl.com> <031DD135F9160444ABBE3B0C36CED618B76C51@011-DB3MPN2-081.MGDPHG.emi.philips.com> <031DD135F9160444ABBE3B0C36CED618B771C6@011-DB3MPN2-081.MGDPHG.emi.philips.com> Date: Mon, 4 Feb 2013 17:49:35 +0000 Message-ID: From: Abdussalam Baryun To: "Dijk, Esko" Content-Type: multipart/alternative; boundary=f46d04430476615aab04d4e9b732 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: Mon, 04 Feb 2013 17:49:37 -0000 --f46d04430476615aab04d4e9b732 Content-Type: text/plain; charset=ISO-8859-1 Hi Esko, comments inline, On Mon, Feb 4, 2013 at 1:34 PM, Dijk, Esko wrote: > Hello, > > > 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 > That's possible, if we have some 'typical' use case for which reasonable > Trickle parameters are known. > My concerns are the parameters mentioned in the draft, and the questions of any reader or implementor are 1) what will be my start values for these parameter. 2) Is there any recommendations from the authors or the group? > On second thought: in practice the SEED_SET_LIFETIME selection may be > linked to the Imin/Imax selection. So giving a default for only > SEED_SET_LIFETIME may not work. E.g. SEED_SET_LIFETIME = 100 ms, and Imin=5 > sec., would not really work well I assume. > There was one test for the MPL and I would like to know what was their parameters' values if possible, however, if not giving by the draft any example or default for parameters, should that mean that it does not matter any value will work. AB --f46d04430476615aab04d4e9b732 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Esko,
comments inline,
On Mon, Feb 4, 2013 at 1:34 PM, Dijk, Esko <esko.dijk@philips.co= m> wrote:
Hello,

> Why not having a default and/or initial values of both the constants a= nd parameters for MPL, as protocols usually have stated within its I-D
That's possible, if we have some 'typical' use case for w= hich reasonable Trickle parameters are known.
=A0
My concerns are the parameters mentioned in the draft, and the questi= ons of any reader or implementor are 1)=A0what will be my start values for = these parameter. 2)=A0Is there any recommendations from the authors or the = group?
=A0
On second thought: in practice the SEED_SET_LIFETIME selection may be linke= d to the Imin/Imax selection. So giving a default for only SEED_SET_LIFETIM= E may not work. E.g. SEED_SET_LIFETIME =3D 100 ms, and Imin=3D5 sec., would= not really work well I assume.
=A0
There was one test for the MPL and I would = like to know what was their parameters' values if possible, however, if= not giving by the draft any=A0example or default=A0for parameters, should = that mean that it does not matter=A0any value will work.
=A0
AB
--f46d04430476615aab04d4e9b732-- From internet-drafts@ietf.org Mon Feb 4 14:34: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 6D70121F8B38; Mon, 4 Feb 2013 14:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.077, 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 4xTOqggJo9ji; Mon, 4 Feb 2013 14:34:05 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9445721F8B4A; Mon, 4 Feb 2013 14:34:04 -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: <20130204223404.18774.18305.idtracker@ietfa.amsl.com> Date: Mon, 04 Feb 2013 14:34:04 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-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: Mon, 04 Feb 2013 22:34:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks= Working Group of the IETF. Title : 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-09.txt Pages : 25 Date : 2013-02-04 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, 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-p2p-measurement-09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=740f9cb37=mukul@uwm.edu Mon Feb 4 14:36:59 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 F2EDB21F8B54 for ; Mon, 4 Feb 2013 14:36:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.506 X-Spam-Level: X-Spam-Status: No, score=-2.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 dyvqrsK4xtUA for ; Mon, 4 Feb 2013 14:36:58 -0800 (PST) Received: from ip4mta.uwm.edu (ip4mta.uwm.edu [129.89.7.194]) by ietfa.amsl.com (Postfix) with ESMTP id 07AE221F8B33 for ; Mon, 4 Feb 2013 14:36:57 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqcEAI82EFF/AAAB/2dsb2JhbABFg3eCUbkSgxIBAQEEAQEBIEsXDxEEAQEDAg0ZAikoCAYTCYgIBwWaNo5ViTSJCoEjjAiDFIETA4hmjTmBHY80gxuCBQ Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id 2D9D92E0F80 for ; Mon, 4 Feb 2013 16:36:57 -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 Hnc7NGJdgUhp for ; Mon, 4 Feb 2013 16:36:56 -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 ED19D2E0F7E for ; Mon, 4 Feb 2013 16:36:56 -0600 (CST) Date: Mon, 4 Feb 2013 16:36:56 -0600 (CST) From: Mukul Goyal To: roll < roll@ietf.org> Message-ID: <84811060.205594.1360017416942.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <20130204223404.18774.18305.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 Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-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: Mon, 04 Feb 2013 22:36:59 -0000 This version contains minor changes based on IESG reviews I received. Thanks Mukul ----- Original Message ----- From: internet-drafts@ietf.org To: i-d-announce@ietf.org Cc: roll@ietf.org Sent: Monday, February 4, 2013 4:34:04 PM Subject: [Roll] I-D Action: draft-ietf-roll-p2p-measurement-09.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-09.txt Pages : 25 Date : 2013-02-04 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, 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-09 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-roll-p2p-measurement-09 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 Anders_Brandt@sigmadesigns.com Wed Feb 6 00:52: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 83D7121F8468 for ; Wed, 6 Feb 2013 00:52:14 -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 hdZ7P5SIlqC9 for ; Wed, 6 Feb 2013 00:52:12 -0800 (PST) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3F121F8793 for ; Wed, 6 Feb 2013 00:52:09 -0800 (PST) From: Anders Brandt To: roll WG Thread-Topic: Adoption of draft-brandt-roll-rpl-applicability-home-building as a new ROLL WG document Thread-Index: Ac4ERwPxNgU2iwXiS92qsW9XbB2IZw== Date: Wed, 6 Feb 2013 08:52:06 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0AD364D1@cph-ex1> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Roll] Adoption of draft-brandt-roll-rpl-applicability-home-building as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 08:52:17 -0000 Dear WG, The applicability statement document for home and building has been updated= : http://tools.ietf.org/html/draft-brandt-roll-rpl-applicability-home-buildin= g-03 At this time, the authors would like to ask that the document as adopted as= a working group document. Thanks, Anders Brandt From abdussalambaryun@gmail.com Wed Feb 6 03:14: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 02E1821F8809 for ; Wed, 6 Feb 2013 03:14:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=0.500, 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 zP6gjiZLS7s5 for ; Wed, 6 Feb 2013 03:14:43 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id C53A121F8808 for ; Wed, 6 Feb 2013 03:14:42 -0800 (PST) Received: by mail-wi0-f172.google.com with SMTP id ez12so5403241wid.5 for ; Wed, 06 Feb 2013 03:14: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=/BrHa5RA80HcAntR3orEgRrdmo2GeySflfR/NSqcPeE=; b=ZW09KTwoQd5Tp4+WLiuhvIfhs+CPySnKJZofxVPf4K/59ytUjyhxY+ZC5rGvd561JM Wy9rBgqMJ/5S1luwP2TXSxQUAw6k8rkHs4jKpzIsKwKqcUthlgpthi0gtSMXk7/n1MI1 2w2AXyGC/Nk6zgIcvHnRsecQX6shNv8HyD+xtxEM3H/x9b4Qw0fTC7xR6+zlPYOBv+1u zVwgSjHeaka/IHWg/ta1kV7dI2Kvdi5mrGP6PEZGksd28VogFg1Hf4hIGixkGDckQRGf Kl78MU1vbIrjKuG5eVIMHQnT4B+xRR0BljXQ0kpIbxVxSICI08Mc+5F2nBUhWAlHmWQS Tv/A== MIME-Version: 1.0 X-Received: by 10.194.20.231 with SMTP id q7mr48949181wje.44.1360149277420; Wed, 06 Feb 2013 03:14:37 -0800 (PST) Received: by 10.180.101.70 with HTTP; Wed, 6 Feb 2013 03:14:37 -0800 (PST) In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD0AD364D1@cph-ex1> References: <03F31C213F2C6941BFDDBB4336E9E6CD0AD364D1@cph-ex1> Date: Wed, 6 Feb 2013 12:14:37 +0100 Message-ID: From: Abdussalam Baryun To: Anders Brandt Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG Subject: Re: [Roll] Adoption of draft-brandt-roll-rpl-applicability-home-building as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 11:14:45 -0000 Hi Anders, Why you change the aim of the draft? from RPL to RPL-P2P, was there a discussion about this please advise, AB On 2/6/13, Anders Brandt wrote: > Dear WG, > > The applicability statement document for home and building has been > updated: > http://tools.ietf.org/html/draft-brandt-roll-rpl-applicability-home-building-03 > > At this time, the authors would like to ask that the document as adopted as > a working group document. > > Thanks, > Anders Brandt > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From abdussalambaryun@gmail.com Wed Feb 6 03:33: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 E2A0221F8630 for ; Wed, 6 Feb 2013 03:33:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 ZCD5426yiFiy for ; Wed, 6 Feb 2013 03:33:09 -0800 (PST) Received: from mail-wi0-f173.google.com (mail-wi0-f173.google.com [209.85.212.173]) by ietfa.amsl.com (Postfix) with ESMTP id 3156721F85FE for ; Wed, 6 Feb 2013 03:33:09 -0800 (PST) Received: by mail-wi0-f173.google.com with SMTP id hq4so5415055wib.12 for ; Wed, 06 Feb 2013 03:33: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=u5CyfVJo/Tds7lbOp/kVsm+r9lERnMAwZXLHJkqZrhc=; b=wgi749Sn1C1XvxcbFAHvaPaZn8kAsKbzTiHgo5PnRh7mbVAzcs0Tqfi1oLAXFRbYSG W1VcEUJLP6wMSuaNOG1AsDG74CrYmczuUdEqNLfXA90NQPHfDJRJl89qD5vqJScXX6kd YPTD6yLAT3wPve5wmkawv6pctWIHjKFUFnYeeRQFG1N49C/5M7hkFrRj/p/2gahrkOLV u6a4kFoSZxSzarxwAyJ7aMyMngtMIdlyM5E83xdcpQdfEO09N+4bugCFMZ49vK99ierT 7U8FcyALw5lZmWZO7JNKGa37llyfaZBriyxl45qJ5QG0VkmxE74F3qQunmNPJspUkLjp Yv/Q== MIME-Version: 1.0 X-Received: by 10.194.20.231 with SMTP id q7mr49071467wje.44.1360150388309; Wed, 06 Feb 2013 03:33:08 -0800 (PST) Received: by 10.180.101.70 with HTTP; Wed, 6 Feb 2013 03:33:08 -0800 (PST) In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD0AD364D1@cph-ex1> References: <03F31C213F2C6941BFDDBB4336E9E6CD0AD364D1@cph-ex1> Date: Wed, 6 Feb 2013 12:33:08 +0100 Message-ID: From: Abdussalam Baryun To: Anders Brandt Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG Subject: Re: [Roll] Adoption of draft-brandt-roll-rpl-applicability-home-building as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 11:33:10 -0000 Why you discuss peer-to-multipeer that it is in building use, while you make the aim for RPL-P2P as only peer-to-peer for building applicability? AB On 2/6/13, Anders Brandt wrote: > Dear WG, > > The applicability statement document for home and building has been > updated: > http://tools.ietf.org/html/draft-brandt-roll-rpl-applicability-home-building-03 > > At this time, the authors would like to ask that the document as adopted as > a working group document. > > Thanks, > Anders Brandt > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From abdussalambaryun@gmail.com Wed Feb 6 04:40: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 6828A21F8809 for ; Wed, 6 Feb 2013 04:40:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.433 X-Spam-Level: X-Spam-Status: No, score=-3.433 tagged_above=-999 required=5 tests=[AWL=0.167, 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 HWM3PWQzTkna for ; Wed, 6 Feb 2013 04:40:15 -0800 (PST) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) by ietfa.amsl.com (Postfix) with ESMTP id 9E35D21F8808 for ; Wed, 6 Feb 2013 04:40:14 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id hi18so1509745wib.3 for ; Wed, 06 Feb 2013 04:40:13 -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=Tu3V1kjKRN3XCPggVlpxj62nuggnOcY6biiXs8g4IpE=; b=I4iUsDIQx6rVMb8usS3Oms2MWqmulaxlf0qf3GYZiLsC5+PM0VJUi0FxVVua7cIPb5 jV7DPED+ezzNDt6J2qu3dQA6Wqhw1lOsvQtewfUqMFEm1Q+0KQMfnvytr9O13J/KXWRL auNe/xFIZiv2qic0o0exM0HmIPnCG64xHrlAbT4QHoDl0UXrnPP9OIPf9FepEwOGVVDy oIO5ooz01rjb8NQXret3T3PdOnom4k/GrNGFHZX8QerHDtPzE1YSxURpmuetbJgWiKGt O0rZb0aB83CnK7qpskqEth7MIDs4VU3N2TFTSFX8NQCT2hUMFcQZb9Can5Zw5/CLolxu Fvfg== MIME-Version: 1.0 X-Received: by 10.194.20.231 with SMTP id q7mr49490351wje.44.1360154413765; Wed, 06 Feb 2013 04:40:13 -0800 (PST) Received: by 10.180.101.70 with HTTP; Wed, 6 Feb 2013 04:40:13 -0800 (PST) In-Reply-To: <368544206.189079.1359926011411.JavaMail.root@mail17.pantherlink.uwm.edu> References: <20130203204932.29839.41892.idtracker@ietfa.amsl.com> <368544206.189079.1359926011411.JavaMail.root@mail17.pantherlink.uwm.edu> Date: Wed, 6 Feb 2013 13:40:13 +0100 Message-ID: From: Abdussalam Baryun To: Mukul Goyal Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: Re: [Roll] I-D Action: draft-ietf-roll-p2p-rpl-16.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, 06 Feb 2013 12:40:15 -0000 On 2/3/13, Mukul Goyal wrote: >This change means that a router MUST detach from the > temporary DAG once the duration of its membership in the temporary DAG has > reached the Life Time duration listed in the P2P Route Discovery Option. > I read meaning in draft: that the origin MUST detach from the temporary DAG...... > This change was required because there was a need to know precisely when > does a route discovery complete so that the RPLInstanceID used in this route > discovery can be reused in another route discovery. So I understand that the need has been solved and by the update, the origin knows precisely the time, AB From abdussalambaryun@gmail.com Wed Feb 6 10:18: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 29A5421F897A for ; Wed, 6 Feb 2013 10:18:22 -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 NMoCOnmrQJYp for ; Wed, 6 Feb 2013 10:18:21 -0800 (PST) Received: from mail-we0-x22b.google.com (we-in-x022b.1e100.net [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 5B35A21F8464 for ; Wed, 6 Feb 2013 10:18:21 -0800 (PST) Received: by mail-we0-f171.google.com with SMTP id u54so1322633wey.2 for ; Wed, 06 Feb 2013 10:18:11 -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=LBRLwawg2z4G6GaUWtcCbsKGEa34LTA1yJiXUoBwcyY=; b=rrbop6d65vXWRPda1+ow7BA9sYWjFpugF48NA5zPzrhogoFK8kzlq7Tamw9isN2lME F+20IgN7jV/6ynoavtwIpWYzU3GX1+1wto9iRxcYJ/ydSlLD/EjavyMvvtphqZrbvXvo 7DT7FGFq6HeaaKAOE2omR+V1TJjbpO34d4teykUhYB6EStjlooUn6AarHXf+p0dm5SQG MeT1FudLWhyuYPNE4OaFvcEDXAIuMPCodtMEOvwvgK0juPCMMhHQ0IOuBCfU9gBClufg 1ShJh9ZTfg8Nk8nNY3X1mNXfNzXmnQoMnyP2pOgC7K7V0LZbLeuHUzRr5g//r66LvsRD NLLg== MIME-Version: 1.0 X-Received: by 10.180.86.36 with SMTP id m4mr6776944wiz.5.1360174691665; Wed, 06 Feb 2013 10:18:11 -0800 (PST) Received: by 10.180.101.70 with HTTP; Wed, 6 Feb 2013 10:18:11 -0800 (PST) In-Reply-To: References: <03F31C213F2C6941BFDDBB4336E9E6CD0AD364D1@cph-ex1> Date: Wed, 6 Feb 2013 19:18:11 +0100 Message-ID: From: Abdussalam Baryun To: Anders Brandt Content-Type: text/plain; charset=ISO-8859-1 Cc: roll WG Subject: Re: [Roll] Adoption of draft-brandt-roll-rpl-applicability-home-building as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Feb 2013 18:18:22 -0000 I suggest you leave the aim as it was in previous version RPL applicability in home and building, sections of RPL-P2P and RPL-P2MP should be in the scope, AB On 2/6/13, Abdussalam Baryun wrote: > Why you discuss peer-to-multipeer that it is in building use, while > you make the aim for RPL-P2P as only peer-to-peer for building > applicability? > > AB > > On 2/6/13, Anders Brandt wrote: >> Dear WG, >> >> The applicability statement document for home and building has been >> updated: >> http://tools.ietf.org/html/draft-brandt-roll-rpl-applicability-home-building-03 >> >> At this time, the authors would like to ask that the document as adopted >> as >> a working group document. >> >> Thanks, >> Anders Brandt >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > From robert.cragie@gridmerge.com Wed Feb 6 13:57: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 1EFEB21F856E for ; Wed, 6 Feb 2013 13:57:11 -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 xVm6nD6EeEOc for ; Wed, 6 Feb 2013 13:57:10 -0800 (PST) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id 38EBD21F855F for ; Wed, 6 Feb 2013 13:57:10 -0800 (PST) Received: from host86-156-113-29.range86-156.btcentralplus.com ([86.156.113.29] helo=[192.168.0.2]) by mail41.extendcp.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.77) id 1U3CzM-0000j2-4K for roll@ietf.org; Wed, 06 Feb 2013 21:57:08 +0000 Message-ID: <5112D246.4090703@gridmerge.com> Date: Wed, 06 Feb 2013 21:59:34 +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: <03F31C213F2C6941BFDDBB4336E9E6CD0AD364D1@cph-ex1> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms040300060803050608020008" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [Roll] Adoption of draft-brandt-roll-rpl-applicability-home-building as a new ROLL WG document 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: Wed, 06 Feb 2013 21:57:11 -0000 This is a cryptographically signed message in MIME format. --------------ms040300060803050608020008 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable The applicability statement, when it was originally produced, identified = issues with RPL as it stood then for applicability in home and building=20 automation. This kicked off the development of the RPL-P2P work, which=20 is more or less complete. Therefore it is logical to refer to this work=20 in the updated document. Robert On 06/02/2013 6:18 PM, Abdussalam Baryun wrote: > I suggest you leave the aim as it was in previous version RPL > applicability in home and building, sections of RPL-P2P and RPL-P2MP > should be in the scope, > > AB > > On 2/6/13, Abdussalam Baryun wrote: >> Why you discuss peer-to-multipeer that it is in building use, while >> you make the aim for RPL-P2P as only peer-to-peer for building >> applicability? >> >> AB >> >> On 2/6/13, Anders Brandt wrote: >>> Dear WG, >>> >>> The applicability statement document for home and building has been >>> updated: >>> http://tools.ietf.org/html/draft-brandt-roll-rpl-applicability-home-b= uilding-03 >>> >>> At this time, the authors would like to ask that the document as adop= ted >>> as >>> a working group document. >>> >>> Thanks, >>> Anders Brandt >>> >>> >>> _______________________________________________ >>> 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 > --------------ms040300060803050608020008 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 Fw0xMzAyMDYyMTU5MzRaMCMGCSqGSIb3DQEJBDEWBBSdo2fUB6/PezO5uor0F/6Kb34+ZzBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAF4Bb4lA9j4K0cERYwEfxyaFItYg4oGNWcjBulndbxnv8XjS R/XChpDQr+SZYn4I92sb0oebisCjoezx/7jMZCxq2SdzyrDsivZNWJIaoVyoJR7LUFyfiE7z 30feBKvglggN6gpn+7ywdT4aypR6BaI/FSSn7OesA85/AbkZphPfGyU9JqpovwdEAaOdnR70 WHpJ/3gHCCw5lYr9O018UQe2PPPOPapCavhWyYyuDQ+sZHhvVMF6o2FnhZ8IHtmHSTDzwwnE Nok/monNyRuKiVFIy9vAgD8rGxo34p+MaVqEv82g3PRF/tmxCMC/J4NXxDe22T3h4ZwIAlTB 4s/OyCoAAAAAAAA= --------------ms040300060803050608020008-- From abdussalambaryun@gmail.com Thu Feb 7 03:57: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 6043C21F854C for ; Thu, 7 Feb 2013 03:57:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.474 X-Spam-Level: X-Spam-Status: No, score=-3.474 tagged_above=-999 required=5 tests=[AWL=0.124, 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 nmVyVY6AIFzs for ; Thu, 7 Feb 2013 03:57:00 -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 49E0821F8496 for ; Thu, 7 Feb 2013 03:57:00 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hi8so2770246wib.1 for ; Thu, 07 Feb 2013 03:56:59 -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=3BKZfyGljWX9JtPMyHe5MpQNlvJdx3KW6IY734kEv7o=; b=nkoiS2B147gLUTf+oCsRtlI01Rv457XsECB6H7raPlLExrV6/WlG3Dd30QLMqbxDih xGsLuJQrX9yHnxmPsND6vw+D9+24Pxjf0D6+Nc0DU3wQDMFzQsTBVlWEoKv71nkjdWzU 63AkUzCG2FV8Yc3OA0nTwZCcIk3kqieiDLASS10WemtVn6kDh6s962LNds5JErPXLtTG O65o6TtokwbuUy8XdVGsuQBlREbr7DZUP7AMrQSmsODeAbsfcy3HojxsIoBWzpVPH5JE UnJKVDUy1NwXh+2VxFqC48QdBE6QKn2pKqE5sLl0kKDSjEZMeyhJCkh005YsU7NV235u SG9w== MIME-Version: 1.0 X-Received: by 10.194.75.196 with SMTP id e4mr2061408wjw.44.1360238219290; Thu, 07 Feb 2013 03:56:59 -0800 (PST) Received: by 10.180.101.70 with HTTP; Thu, 7 Feb 2013 03:56:59 -0800 (PST) In-Reply-To: <5112D246.4090703@gridmerge.com> References: <03F31C213F2C6941BFDDBB4336E9E6CD0AD364D1@cph-ex1> <5112D246.4090703@gridmerge.com> Date: Thu, 7 Feb 2013 11:56:59 +0000 Message-ID: From: Abdussalam Baryun To: robert.cragie@gridmerge.com Content-Type: multipart/alternative; boundary=047d7bb049c6dee84904d5212361 Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-brandt-roll-rpl-applicability-home-building as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 11:57:01 -0000 --047d7bb049c6dee84904d5212361 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Feb 6, 2013 at 9:59 PM, Robert Cragie wrote: > The applicability statement, when it was originally produced, identified > issues with RPL as it stood then for applicability in home and building > automation. This kicked off the development of the RPL-P2P work, which is > more or less complete. Therefore it is logical to refer to this work in the > updated document. > > I agree that it is logical *to refer* and discuss applicability of RPL-P2P, but don't agree to change the aim of the draft from RPL to RPL-P2P. Do you think both protocols are similar, or do you think that RPL is not applicabile for home applications, just RPL-P2P? AB --047d7bb049c6dee84904d5212361 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Feb 6, 2013 at 9:59 PM, Robert Cragie <robert.cragie@gridmerge.com> wrote:
The applicability statement, when it was originally produced, identified is= sues with RPL as it stood then for applicability in home and building autom= ation. This kicked off the development of the RPL-P2P work, which is more o= r less complete. Therefore it is logical to refer to this work in the updat= ed document.

=A0
I agree that it is logica= l *to refer* and discuss applicability=A0of RPL-P2P, but don't agree to= change the aim of the draft from RPL to RPL-P2P. Do you think both protoco= ls are similar, or do you think that RPL is not applicabile for home applic= ations, just RPL-P2P?
=A0
AB
--047d7bb049c6dee84904d5212361-- From adrian@olddog.co.uk Thu Feb 7 05:47: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 0A2E321F8470 for ; Thu, 7 Feb 2013 05:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.541 X-Spam-Level: X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, 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 qMW01qoi0l+C for ; Thu, 7 Feb 2013 05:47:39 -0800 (PST) Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) by ietfa.amsl.com (Postfix) with ESMTP id D590A21F84DE for ; Thu, 7 Feb 2013 05:47:38 -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 r17DlbMX016007 for ; Thu, 7 Feb 2013 13:47:37 GMT Received: from 950129200 (89-26-111-90.bruck.stat.salzburg-online.at [89.26.111.90]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id r17Dla45015993 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Thu, 7 Feb 2013 13:47:36 GMT From: "Adrian Farrel" To: Date: Thu, 7 Feb 2013 13:47:35 -0000 Message-ID: <00c701ce0539$b07a1a70$116e4f50$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4FOaF4owNQGhrlQhSrEjEbkNLnFQ== Content-Language: en-gb Subject: [Roll] Heads up : Last Call: (Depth-First Forwarding in Unreliable Networks (DFF)) to Experimental RFC 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: Thu, 07 Feb 2013 13:47:40 -0000 This could affect you. Please comment (if you want to) on the IETF list as described. Thanks, Adrian > -----Original Message----- > From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > bounces@ietf.org] On Behalf Of The IESG > Sent: 07 February 2013 13:22 > To: IETF-Announce > Subject: Last Call: (Depth-First Forwarding in > Unreliable Networks (DFF)) to Experimental RFC > > > The IESG has received a request from an individual submitter to consider > the following document: > - 'Depth-First Forwarding in Unreliable Networks (DFF)' > 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-02-24. 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 the "Depth-First Forwarding" (DFF) protocol > for IPv6 networks, a data forwarding mechanism that can increase > reliability of data delivery in networks with dynamic topology and/or > lossy links. The protocol operates entirely on the forwarding plane, > but may interact with the routing plane. DFF forwards data packets > using a mechanism similar to a "depth-first search" for the > destination of a packet. The routing plane may be informed of > failures to deliver a packet or loops. This document specifies the > DFF mechanism both for IPv6 networks (as specified in RFC2460) and in > addition also for LoWPAN "mesh-under" networks (as specified in > RFC4944). > > > > > The file can be obtained via > http://datatracker.ietf.org/doc/draft-cardenas-dff/ > > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-cardenas-dff/ballot/ > > > The following IPR Declarations may be related to this I-D: > > http://datatracker.ietf.org/ipr/1645/ > http://datatracker.ietf.org/ipr/1646/ > From mcr@sandelman.ca Thu Feb 7 05:49: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 AFC6521F84B6; Thu, 7 Feb 2013 05:49:16 -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 StxP0EFqalVb; Thu, 7 Feb 2013 05:49:16 -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 78A9421F8470; Thu, 7 Feb 2013 05:49:15 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 604322016D; Thu, 7 Feb 2013 08:55:09 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 5AB2314852; Thu, 7 Feb 2013 08:48:07 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 2C0D824691; Thu, 7 Feb 2013 08:48:07 -0500 (EST) From: Michael Richardson To: roll@ietf.org, Brian Haberman In-Reply-To: <5112A446.8030105@innovationslab.net> References: <890914225.234527.1360175848049.JavaMail.root@mail17.pantherlink.uwm.edu> <5112A446.8030105@innovationslab.net> 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: draft-ietf-roll-p2p-rpl@tools.ietf.org, afarrel@juniper.net, The IESG , roll-chairs@tools.ietf.org Subject: [Roll] use of PIO payloads in P2P DIO messages (was Re: Brian Haberman's Discuss on draft-ietf-roll-p2p-rpl-16: (with DISCUSS and COMMENT)) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 13:49:16 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable I am including the WG mailing list in my reply, and fixing the subject. This relates to:=20 http://datatracker.ietf.org/streams/draft-ietf-roll-p2p-rpl/history/ (If there is a better way to link to just Brian Haberman's comments in the history I don't know. I don't like the pop-up, I had to play browser tricks to get the above URL) see inline below. Brian> I am confused by the last bullet in 6.1. It states that a Brian> P2P-mode DIO may carry a PIO option, but no where does this Brian> document describe why (or how) that option would be used in this Brian> approach. What benefit would including a PIO have? Where would an Brian> arbitrary node in a RPL network get the information to include in Brian> a PIO?=20 Brian raised an interesting question, and I had to think about this. I see this as an issue of "be liberal in what you accept", and a question of protecting future innovation by not saying things are illegal just because can't think what they mean right now. However, after read the thread, I offer how I can see using a PIO in a DIO. >>>>> "Brian" =3D=3D Brian Haberman writes: >> Hi Brian >>=20 >> Not sure what you mean. >>=20 >> In P2P-RPL, the DAG is ephemeral but not the discovered routes. Brian> What I mean is it does not make sense (to me) to include Brian> information that is used to configure IPv6 addresses. Brian> Including a PIO in a DIO means that the Source node expects Brian> children to autoconfigure addresses using the specified Brian> prefix. However, they already have addresses based on the Brian> PIO that would have come down the DODAG (originated at the Brian> root). I am trying to understand a use-case where having new You assume a root DODAG here, which might not (yet) exist. And, not all DODAGs are grounded, and therefore might not even have address space yet with which to send out PIOs. There might not be any root controller/LBR yet, because the factory and/or house has not yet completed construction. The resulting routes could consist of link layer addresses only, so the light switch could still discover the light bulb when the jiprock(wall) is still not yet up. If one contemplates full EUI-64 based SLACC with the PIO in that DIO, then one would be able to see in the mDNS, (or other service discovery) what the serial number of the light bulb/socket and controller was involved. (What bulb did you just discover?) While mDNS and friends can use link layer addresses, on an LLNs, there is significant advantages to using the 16-bit versions, and that may not provide the detail one needs. So, I see no reason to forbid the PIO, but I agree that it might be unusual to have it. =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) iQCVAwUAUROwloqHRg3pndX9AQKfrgP9FiWEbpLsWyYlGEzRH70HSBFebf6rd4qf aw833qp4azTftUaqmTqsBlbEUMUQaRO6C4iHs9ZkuTM2mShrX6rCHz1/RGkCKRxB SPBheOGbyENsewbwHCYiusK7YRKm+vdt1xngIqF1h/krzCTvKIDWp2GEhVkQZBmi 409Hck/UGLk= =g/Yg -----END PGP SIGNATURE----- --=-=-=-- From abdussalambaryun@gmail.com Thu Feb 7 13:47: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 3F4B121F8BDD; Thu, 7 Feb 2013 13:47:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.289 X-Spam-Level: X-Spam-Status: No, score=-3.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 WoiEHkKV19kD; Thu, 7 Feb 2013 13:47:28 -0800 (PST) Received: from mail-wg0-f54.google.com (mail-wg0-f54.google.com [74.125.82.54]) by ietfa.amsl.com (Postfix) with ESMTP id 5667121F894E; Thu, 7 Feb 2013 13:47:18 -0800 (PST) Received: by mail-wg0-f54.google.com with SMTP id fm10so2360507wgb.33 for ; Thu, 07 Feb 2013 13:47: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=K33MWNFilKBhv8W2+UzrcG0Z5n+lo76UI8aLK4RnD2E=; b=aluhuQIyDvF7PDcrpjEplt/A6Cag63812pXQuPSwdyU81NauWucuRrbThnetEEl74M 4f+4YKfa6BC37tSZL4kYlJ5l7UVWXPd3B7Hhmz0JFNSG/5tYdFJVTRtR43+rBoISiUbM gfYE2WOD+2S6NzDI5nG8PJPA0VwcZjR9mZ5NqorkzXhh+M/m0p3geGon3DYyivWHOrvO mBzXDVvxzg2fGKWPPO1omfAJVSNCRpO60f5dBBHLRc2Ou/7KgNzXzxLEoFK4ySJErbFm TP5osOb5+Sgtqi/PGJpDV4Ijbxy6UJ5bU80rIJ851dcWT3j8cSE3xVTctx94EqUJIVIn rfaA== MIME-Version: 1.0 X-Received: by 10.194.75.196 with SMTP id e4mr5705909wjw.44.1360273637421; Thu, 07 Feb 2013 13:47:17 -0800 (PST) Received: by 10.180.101.70 with HTTP; Thu, 7 Feb 2013 13:47:17 -0800 (PST) In-Reply-To: <00c701ce0539$b07a1a70$116e4f50$@olddog.co.uk> References: <00c701ce0539$b07a1a70$116e4f50$@olddog.co.uk> Date: Thu, 7 Feb 2013 22:47:17 +0100 Message-ID: From: Abdussalam Baryun To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Cc: 6lowpan <6lowpan@ietf.org> Subject: Re: [Roll] Heads up : Last Call: (Depth-First Forwarding in Unreliable Networks (DFF)) to Experimental RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 21:47:29 -0000 I didn't understand what kind of affect it can make. This draft was not submitted to ROLL, but to IETF. Was this draft before discussed/presented in 6LowPAN or ROLL? However, IMO all drafts old and new may affect each other in IETF for progress, which is good. AB On 2/7/13, Adrian Farrel wrote: > This could affect you. > Please comment (if you want to) on the IETF list as described. > > Thanks, > Adrian > >> -----Original Message----- >> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- >> bounces@ietf.org] On Behalf Of The IESG >> Sent: 07 February 2013 13:22 >> To: IETF-Announce >> Subject: Last Call: (Depth-First Forwarding >> in >> Unreliable Networks (DFF)) to Experimental RFC >> >> >> The IESG has received a request from an individual submitter to consider >> the following document: >> - 'Depth-First Forwarding in Unreliable Networks (DFF)' >> 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-02-24. 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 the "Depth-First Forwarding" (DFF) protocol >> for IPv6 networks, a data forwarding mechanism that can increase >> reliability of data delivery in networks with dynamic topology and/or >> lossy links. The protocol operates entirely on the forwarding plane, >> but may interact with the routing plane. DFF forwards data packets >> using a mechanism similar to a "depth-first search" for the >> destination of a packet. The routing plane may be informed of >> failures to deliver a packet or loops. This document specifies the >> DFF mechanism both for IPv6 networks (as specified in RFC2460) and in >> addition also for LoWPAN "mesh-under" networks (as specified in >> RFC4944). >> >> >> >> >> The file can be obtained via >> http://datatracker.ietf.org/doc/draft-cardenas-dff/ >> >> IESG discussion can be tracked via >> http://datatracker.ietf.org/doc/draft-cardenas-dff/ballot/ >> >> >> The following IPR Declarations may be related to this I-D: >> >> http://datatracker.ietf.org/ipr/1645/ >> http://datatracker.ietf.org/ipr/1646/ >> > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From brian@innovationslab.net Thu Feb 7 14:01: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 358F121F8918; Thu, 7 Feb 2013 14:01:36 -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 01VDprAPcUAG; Thu, 7 Feb 2013 14:01:35 -0800 (PST) Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) by ietfa.amsl.com (Postfix) with ESMTP id A056921F8686; Thu, 7 Feb 2013 14:01:35 -0800 (PST) Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 7AC8188148; Thu, 7 Feb 2013 14:01:35 -0800 (PST) Received: from clemson.local (c-69-140-213-249.hsd1.md.comcast.net [69.140.213.249]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id 9238C13000C; Thu, 7 Feb 2013 14:01:34 -0800 (PST) Message-ID: <5114243D.9020607@innovationslab.net> Date: Thu, 07 Feb 2013 17:01:33 -0500 From: Brian Haberman User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Michael Richardson References: <890914225.234527.1360175848049.JavaMail.root@mail17.pantherlink.uwm.edu> <5112A446.8030105@innovationslab.net> <466.1360244886@sandelman.ca> In-Reply-To: <466.1360244886@sandelman.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: draft-ietf-roll-p2p-rpl@tools.ietf.org, roll@ietf.org, afarrel@juniper.net, The IESG , roll-chairs@tools.ietf.org Subject: Re: [Roll] use of PIO payloads in P2P DIO messages (was Re: Brian Haberman's Discuss on draft-ietf-roll-p2p-rpl-16: (with DISCUSS and COMMENT)) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Feb 2013 22:01:36 -0000 Hi Michael, On 2/7/13 8:48 AM, Michael Richardson wrote: > > I am including the WG mailing list in my reply, and fixing the subject. > This relates to: > http://datatracker.ietf.org/streams/draft-ietf-roll-p2p-rpl/history/ > > (If there is a better way to link to just Brian Haberman's comments > in the history I don't know. I don't like the pop-up, I had to play > browser tricks to get the above URL) > > see inline below. > > Brian> I am confused by the last bullet in 6.1. It states that a > Brian> P2P-mode DIO may carry a PIO option, but no where does this > Brian> document describe why (or how) that option would be used in this > Brian> approach. What benefit would including a PIO have? Where would an > Brian> arbitrary node in a RPL network get the information to include in > Brian> a PIO? > > Brian raised an interesting question, and I had to think about this. > I see this as an issue of "be liberal in what you accept", and a > question of protecting future innovation by not saying things are > illegal just because can't think what they mean right now. > > However, after read the thread, I offer how I can see using a PIO in a DIO. > >>>>>> "Brian" == Brian Haberman writes: > >> Hi Brian > >> > >> Not sure what you mean. > >> > >> In P2P-RPL, the DAG is ephemeral but not the discovered routes. > > Brian> What I mean is it does not make sense (to me) to include > Brian> information that is used to configure IPv6 addresses. > Brian> Including a PIO in a DIO means that the Source node expects > Brian> children to autoconfigure addresses using the specified > Brian> prefix. However, they already have addresses based on the > Brian> PIO that would have come down the DODAG (originated at the > Brian> root). I am trying to understand a use-case where having new > > You assume a root DODAG here, which might not (yet) exist. > And, not all DODAGs are grounded, and therefore might not even have > address space yet with which to send out PIOs. > > There might not be any root controller/LBR yet, because the factory > and/or house has not yet completed construction. > > The resulting routes could consist of link layer addresses only, so the > light switch could still discover the light bulb when the jiprock(wall) is > still not yet up. > > If one contemplates full EUI-64 based SLACC with the PIO in that DIO, > then one would be able to see in the mDNS, (or other service discovery) what > the serial number of the light bulb/socket and controller was involved. > (What bulb did you just discover?) > > While mDNS and friends can use link layer addresses, on an LLNs, there is > significant advantages to using the 16-bit versions, and that may not > provide the detail one needs. > > So, I see no reason to forbid the PIO, but I agree that it might be > unusual to have it. > The above does explain a possible use for a PIO in this approach. I do think the draft could benefit from a *brief* description of the above so that future readers have some idea of why a PIO is allowed. Regards, Brian From ulrich@herberg.name Thu Feb 7 17:31: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 949E521E8040 for ; Thu, 7 Feb 2013 17:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.407, 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 Oe8Qu4AWcSL8 for ; Thu, 7 Feb 2013 17:31:21 -0800 (PST) Received: from mail-vc0-f169.google.com (mail-vc0-f169.google.com [209.85.220.169]) by ietfa.amsl.com (Postfix) with ESMTP id 66E9321E803A for ; Thu, 7 Feb 2013 17:31:21 -0800 (PST) Received: by mail-vc0-f169.google.com with SMTP id n10so2114263vcn.28 for ; Thu, 07 Feb 2013 17:31:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=bdu2edVY97ldj2bjj0jDUKSXQFg7UN+AiuAfpUEupbc=; b=JkFMwWVdOOWBE3Uz32RtElCCu84C3eTghE5W2HrKVY0xDMxMZWBhFXeL6MLnj8nCRh E5RA7UAkT6gUCkjj8OiaFTnT0DFxOF7BO7s/1TSsz7NCUx9f9He+zv6+IMO5UaNdewHL 8SD2SbbdcAiDrubYIGbyZ63Cg43LWiML1EIRY= 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=bdu2edVY97ldj2bjj0jDUKSXQFg7UN+AiuAfpUEupbc=; b=KyZlENeG4qhYOxtDMZZ4pURP6zgITmRfBe3DEQBJhc4vJUslmkh3g4ZaS/SqDFcGFd qQZgo9XcHPT/m1kkvW71yOtnzmqrFs1tbpd4fjsSCtDPY2jJnSp9bewqXhQdkZRgpj4J kxvOujmoLUImDSZrfO2d1c0RBOhWPGRYR47NWy7Leh/GtjZVBDQCIyzrHJ3xsonwPaft ILIQ7Kg7AJ2Gvd1BiEkNORUwvtWdKRKhWCkn8IUWM796AkqmTaKUR2Vw4pNzXKVrC3CZ Y+H8W1s4P4JVKrTYI0Siaa+MUVp/ub03UtNFm/WBsbxCsdJGe6eqWDPgkTzbIZSdV6Af bJNA== MIME-Version: 1.0 X-Received: by 10.59.7.170 with SMTP id dd10mr4634056ved.2.1360287080615; Thu, 07 Feb 2013 17:31:20 -0800 (PST) Received: by 10.220.146.199 with HTTP; Thu, 7 Feb 2013 17:31:20 -0800 (PST) In-Reply-To: References: <00c701ce0539$b07a1a70$116e4f50$@olddog.co.uk> Date: Thu, 7 Feb 2013 17:31:20 -0800 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=047d7bdc98823b8fe704d52c842f X-Gm-Message-State: ALoCoQnPXybP4ESbjMqUlF7fnrrVRHbzKZz3iMLCJE3h4iz2ohC+LLw+MX+IYTj0eJiOi7BrpH7Y Cc: roll@ietf.org, 6lowpan <6lowpan@ietf.org> Subject: Re: [Roll] Heads up : Last Call: (Depth-First Forwarding in Unreliable Networks (DFF)) to Experimental RFC X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 01:31:22 -0000 --047d7bdc98823b8fe704d52c842f Content-Type: text/plain; charset=ISO-8859-1 AB, this draft is an individual draft, not going through a working group. The document specifies a data forwarding mechanism that can improve data delivery reliability, and thus is relevant in the Internet Area of the IETF, more than the Routing Area (of which ROLL is part). The 6lowpan WG does not accept any new work items. The DFF mechanism can use information from different routing protocols. There are several implementations and deployments, as described in the draft. Best regards Ulrich On Thu, Feb 7, 2013 at 1:47 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > I didn't understand what kind of affect it can make. This draft was > not submitted to ROLL, but to IETF. Was this draft before > discussed/presented in 6LowPAN or ROLL? However, IMO all drafts old > and new may affect each other in IETF for progress, which is good. > > AB > > On 2/7/13, Adrian Farrel wrote: > > This could affect you. > > Please comment (if you want to) on the IETF list as described. > > > > Thanks, > > Adrian > > > >> -----Original Message----- > >> From: ietf-announce-bounces@ietf.org [mailto:ietf-announce- > >> bounces@ietf.org] On Behalf Of The IESG > >> Sent: 07 February 2013 13:22 > >> To: IETF-Announce > >> Subject: Last Call: (Depth-First Forwarding > >> in > >> Unreliable Networks (DFF)) to Experimental RFC > >> > >> > >> The IESG has received a request from an individual submitter to consider > >> the following document: > >> - 'Depth-First Forwarding in Unreliable Networks (DFF)' > >> 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-02-24. 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 the "Depth-First Forwarding" (DFF) protocol > >> for IPv6 networks, a data forwarding mechanism that can increase > >> reliability of data delivery in networks with dynamic topology and/or > >> lossy links. The protocol operates entirely on the forwarding plane, > >> but may interact with the routing plane. DFF forwards data packets > >> using a mechanism similar to a "depth-first search" for the > >> destination of a packet. The routing plane may be informed of > >> failures to deliver a packet or loops. This document specifies the > >> DFF mechanism both for IPv6 networks (as specified in RFC2460) and in > >> addition also for LoWPAN "mesh-under" networks (as specified in > >> RFC4944). > >> > >> > >> > >> > >> The file can be obtained via > >> http://datatracker.ietf.org/doc/draft-cardenas-dff/ > >> > >> IESG discussion can be tracked via > >> http://datatracker.ietf.org/doc/draft-cardenas-dff/ballot/ > >> > >> > >> The following IPR Declarations may be related to this I-D: > >> > >> http://datatracker.ietf.org/ipr/1645/ > >> http://datatracker.ietf.org/ipr/1646/ > >> > > > > > > _______________________________________________ > > 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 > --047d7bdc98823b8fe704d52c842f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable AB,

this draft is an individual draft, not going through a working g= roup. The document specifies a data forwarding mechanism that can improve d= ata delivery reliability, and thus is relevant in the Internet Area of the = IETF, more than the Routing Area (of which ROLL is part). The 6lowpan WG do= es not accept any new work items.
The DFF mechanism can use information from different routing protocols. The= re are several implementations and deployments, as described in the draft.<= br>
Best regards
Ulrich

On Thu, Feb= 7, 2013 at 1:47 PM, Abdussalam Baryun <abdussalambaryun@gmail.co= m> wrote:
I didn't understand what kind of affect = it can make. This draft was
not submitted to ROLL, but to IETF. Was this draft before
discussed/presented in 6LowPAN or ROLL? However, IMO all drafts old
and new may affect each other in IETF for progress, which is good.

AB

On 2/7/13, Adrian Farrel <adrian@= olddog.co.uk> wrote:
> This could affect you.
> Please comment (if you want to) on the IETF list as described.
>
> Thanks,
> Adrian
>
>> -----Original Message-----
>> From: ietf-annou= nce-bounces@ietf.org [mailto:ietf-ann= ounce-
>> bounces@ietf.org] On Behal= f Of The IESG
>> Sent: 07 February 2013 13:22
>> To: IETF-Announce
>> Subject: Last Call: <draft-cardenas-dff-09.txt> (Depth-First= Forwarding
>> in
>> Unreliable Networks (DFF)) to Experimental RFC
>>
>>
>> The IESG has received a request from an individual submitter to co= nsider
>> the following document:
>> - 'Depth-First Forwarding in Unreliable Networks (DFF)' >> =A0 <draft-cardenas-dff-09.txt> as Experimental RFC
>>
>> The IESG plans to make a decision in the next few weeks, and solic= its
>> final comments on this action. Please send substantive comments to= the
>> ietf@ietf.org mailing lists b= y 2013-02-24. 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
>>
>>
>> =A0 =A0This document specifies the "Depth-First Forwarding&qu= ot; (DFF) protocol
>> =A0 =A0for IPv6 networks, a data forwarding mechanism that can inc= rease
>> =A0 =A0reliability of data delivery in networks with dynamic topol= ogy and/or
>> =A0 =A0lossy links. =A0The protocol operates entirely on the forwa= rding plane,
>> =A0 =A0but may interact with the routing plane. =A0DFF forwards da= ta packets
>> =A0 =A0using a mechanism similar to a "depth-first search&quo= t; for the
>> =A0 =A0destination of a packet. =A0The routing plane may be inform= ed of
>> =A0 =A0failures to deliver a packet or loops. =A0This document spe= cifies the
>> =A0 =A0DFF mechanism both for IPv6 networks (as specified in RFC24= 60) and in
>> =A0 =A0addition also for LoWPAN "mesh-under" networks (a= s specified in
>> =A0 =A0RFC4944).
>>
>>
>>
>>
>> The file can be obtained via
>> http://datatracker.ietf.org/doc/draft-cardenas-dff/
>>
>> IESG discussion can be tracked via
>> http://datatracker.ietf.org/doc/draft-cardenas-dff/b= allot/
>>
>>
>> The following IPR Declarations may be related to this I-D:
>>
>> =A0 =A0http://datatracker.ietf.org/ipr/1645/
>> =A0 =A0http://datatracker.ietf.org/ipr/1646/
>>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--047d7bdc98823b8fe704d52c842f-- From Anders_Brandt@sigmadesigns.com Fri Feb 8 01:56: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 B169021F85B2 for ; Fri, 8 Feb 2013 01:56:23 -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.001, 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 SKb1YZLC4gWw for ; Fri, 8 Feb 2013 01:56:22 -0800 (PST) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id F124121F859C for ; Fri, 8 Feb 2013 01:56:21 -0800 (PST) From: Anders Brandt To: Abdussalam Baryun , "robert.cragie@gridmerge.com" Thread-Topic: [Roll] Adoption of draft-brandt-roll-rpl-applicability-home-building as a new ROLL WG document Thread-Index: Ac4ERwPxNgU2iwXiS92qsW9XbB2IZwADla0AAA4lboAAB7tSAAAdPxeAAC8ChPA= Date: Fri, 8 Feb 2013 09:56:12 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0AD3CB49@cph-ex1> References: <03F31C213F2C6941BFDDBB4336E9E6CD0AD364D1@cph-ex1> <5112D246.4090703@gridmerge.com> In-Reply-To: Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.56] Content-Type: multipart/alternative; boundary="_000_03F31C213F2C6941BFDDBB4336E9E6CD0AD3CB49cphex1_" MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] Adoption of draft-brandt-roll-rpl-applicability-home-building as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 09:56:23 -0000 --_000_03F31C213F2C6941BFDDBB4336E9E6CD0AD3CB49cphex1_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Abdussalam, >I agree that it is logical *to refer* and discuss applicability of RPL-P2P= , but don't agree to change the aim >of the draft from RPL to RPL-P2P. >Do you think both protocols are similar, or do you think that RPL is not a= pplicabile for home applications, just RPL-P2P? I think that the protocols are not similar and I think that P2P-RPL is appl= icable for home applications. Restating Robert's comment, the draft in its original form was a sort of pr= oblem statement which helps nobody designing anything. The natural evolution of the draft was to describe how one could meet the r= equirements for home applications; and to the authors of the draft, P2P-RPL seems to be the best choice for home applications. I have no intention of preventing others from evaluating the applicability = of RPL for home applications. Thanks, Anders From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Abd= ussalam Baryun Sent: 7. februar 2013 12:57 To: robert.cragie@gridmerge.com Cc: roll@ietf.org Subject: Re: [Roll] Adoption of draft-brandt-roll-rpl-applicability-home-bu= ilding as a new ROLL WG document On Wed, Feb 6, 2013 at 9:59 PM, Robert Cragie > wrote: The applicability statement, when it was originally produced, identified is= sues with RPL as it stood then for applicability in home and building autom= ation. This kicked off the development of the RPL-P2P work, which is more o= r less complete. Therefore it is logical to refer to this work in the updat= ed document. I agree that it is logical *to refer* and discuss applicability of RPL-P2P,= but don't agree to change the aim of the draft from RPL to RPL-P2P. Do you= think both protocols are similar, or do you think that RPL is not applicab= ile for home applications, just RPL-P2P? AB --_000_03F31C213F2C6941BFDDBB4336E9E6CD0AD3CB49cphex1_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Abdussalam= ,

 

>I agree that it is logical = *to refer* and discuss applicability of RPL-P2P, but don't agree to ch= ange the aim

>of the draft from RPL to RP= L-P2P.

>Do you think both protocols= are similar, or do you think that RPL is not applicabile for home applicat= ions, just RPL-P2P?

 = ;

I think th= at the protocols are not similar and I think that P2P-RPL is applicable for= home applications.

Restating = Robert’s comment, the draft in its original form was a sort of proble= m statement which helps nobody designing anything.
The natural evolution of the draft was to describe how one could meet the r= equirements for home applications; and to the authors
of the draft, P2P-RPL seems to be the best choice for home applications.

 = ;

I have no = intention of preventing others from evaluating the applicability of RPL for= home applications.

 = ;

Thanks,

  And= ers

 = ;

From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Abdussalam Baryun
Sent: 7. februar 2013 12:57
To: robert.cragie@gridmerge.com
Cc: roll@ietf.org
Subject: Re: [Roll] Adoption of draft-brandt-roll-rpl-applicability-= home-building as a new ROLL WG document

 

On Wed, Feb 6, 2013 at 9:59 PM, Robert Cragie <robert.cragi= e@gridmerge.com> wrote:

The applicability sta= tement, when it was originally produced, identified issues with RPL as it s= tood then for applicability in home and building automation. This kicked of= f the development of the RPL-P2P work, which is more or less complete. Therefore it is logical to refer to this w= ork in the updated document.

 

I agree that it is logical *to refer* and discuss ap= plicability of RPL-P2P, but don't agree to change the aim of the draft= from RPL to RPL-P2P. Do you think both protocols are similar, or do you th= ink that RPL is not applicabile for home applications, just RPL-P2P?

 

AB

--_000_03F31C213F2C6941BFDDBB4336E9E6CD0AD3CB49cphex1_-- From trac+roll@trac.tools.ietf.org Fri Feb 8 02:09: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 B414421F84F3 for ; Fri, 8 Feb 2013 02:09:45 -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 eLvzwIuTe88t for ; Fri, 8 Feb 2013 02:09:45 -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 2791821F84C6 for ; Fri, 8 Feb 2013 02:09:44 -0800 (PST) Received: from localhost ([127.0.0.1]:56493 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U3ktn-0002Vm-3V; Fri, 08 Feb 2013 11:09:40 +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: Fri, 08 Feb 2013 10:09:39 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/112#comment:2 Message-ID: <078.655a5149f7d1560307798daabb1796d4@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: <20130208100945.2791821F84C6@ietfa.amsl.com> Resent-Date: Fri, 8 Feb 2013 02:09:44 -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: Fri, 08 Feb 2013 10:09:46 -0000 #112: MPL IANA request section to mention 0x0-0xFF range group ID Comment (by esko.dijk@philips.com): Update: if link-local scope FF02::ALL_MPL_FORWARDERS is never used/useful, which seems to be the case in the newest draft (v03), then this assignment in the 0x0-0xff range is not needed at all. The most efficient mode of compression of a multicast address down to 1 byte only works on FF02::X addresses. -- -------------------------+------------------------------------------------- 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 prvs=7440ad569=mukul@uwm.edu Fri Feb 8 04:56: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 C2E6221F89B3; Fri, 8 Feb 2013 04:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, 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 guRp03MWHB8e; Fri, 8 Feb 2013 04:56:22 -0800 (PST) Received: from ip4mta.uwm.edu (ip4mta.uwm.edu [129.89.7.194]) by ietfa.amsl.com (Postfix) with ESMTP id E7FB321F89AA; Fri, 8 Feb 2013 04:56:21 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAKj0FFF/AAAB/2dsb2JhbAA/BoZNulmDEgEBBSNLCwwPEQQBAQECAg0SBwJRCAYTiBEMrjSJOIkKgSOMDYMZgRMDiGaNPoEdjzWDH4IF Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 558692A0D39; Fri, 8 Feb 2013 06:56:20 -0600 (CST) X-Virus-Scanned: amavisd-new at Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6c8uH86-iSIL; Fri, 8 Feb 2013 06:56:19 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id C988F2A0D34; Fri, 8 Feb 2013 06:56:19 -0600 (CST) Date: Fri, 8 Feb 2013 06:56:19 -0600 (CST) From: Mukul Goyal To: Brian Haberman Message-ID: <464809931.259570.1360328179737.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <5114243D.9020607@innovationslab.net> 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: draft-ietf-roll-p2p-rpl@tools.ietf.org, roll@ietf.org, afarrel@juniper.net, The IESG , roll-chairs@tools.ietf.org Subject: Re: [Roll] use of PIO payloads in P2P DIO messages (was Re: Brian Haberman's Discuss on draft-ietf-roll-p2p-rpl-16: (with DISCUSS and COMMENT)) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 12:56:22 -0000 Michael Could you offer text, describing possible use of PIOs in P2P mode DIOs, that I could put in the draft? Thanks Mukul ----- Original Message ----- From: "Brian Haberman" To: "Michael Richardson" Cc: roll@ietf.org, "Mukul Goyal" , "The IESG" , draft-ietf-roll-p2p-rpl@tools.ietf.org, roll-chairs@tools.ietf.org, afarrel@juniper.net, "Anders Brandt" Sent: Thursday, February 7, 2013 4:01:33 PM Subject: Re: use of PIO payloads in P2P DIO messages (was Re: Brian Haberman's Discuss on draft-ietf-roll-p2p-rpl-16: (with DISCUSS and COMMENT)) Hi Michael, On 2/7/13 8:48 AM, Michael Richardson wrote: > > I am including the WG mailing list in my reply, and fixing the subject. > This relates to: > http://datatracker.ietf.org/streams/draft-ietf-roll-p2p-rpl/history/ > > (If there is a better way to link to just Brian Haberman's comments > in the history I don't know. I don't like the pop-up, I had to play > browser tricks to get the above URL) > > see inline below. > > Brian> I am confused by the last bullet in 6.1. It states that a > Brian> P2P-mode DIO may carry a PIO option, but no where does this > Brian> document describe why (or how) that option would be used in this > Brian> approach. What benefit would including a PIO have? Where would an > Brian> arbitrary node in a RPL network get the information to include in > Brian> a PIO? > > Brian raised an interesting question, and I had to think about this. > I see this as an issue of "be liberal in what you accept", and a > question of protecting future innovation by not saying things are > illegal just because can't think what they mean right now. > > However, after read the thread, I offer how I can see using a PIO in a DIO. > >>>>>> "Brian" == Brian Haberman writes: > >> Hi Brian > >> > >> Not sure what you mean. > >> > >> In P2P-RPL, the DAG is ephemeral but not the discovered routes. > > Brian> What I mean is it does not make sense (to me) to include > Brian> information that is used to configure IPv6 addresses. > Brian> Including a PIO in a DIO means that the Source node expects > Brian> children to autoconfigure addresses using the specified > Brian> prefix. However, they already have addresses based on the > Brian> PIO that would have come down the DODAG (originated at the > Brian> root). I am trying to understand a use-case where having new > > You assume a root DODAG here, which might not (yet) exist. > And, not all DODAGs are grounded, and therefore might not even have > address space yet with which to send out PIOs. > > There might not be any root controller/LBR yet, because the factory > and/or house has not yet completed construction. > > The resulting routes could consist of link layer addresses only, so the > light switch could still discover the light bulb when the jiprock(wall) is > still not yet up. > > If one contemplates full EUI-64 based SLACC with the PIO in that DIO, > then one would be able to see in the mDNS, (or other service discovery) what > the serial number of the light bulb/socket and controller was involved. > (What bulb did you just discover?) > > While mDNS and friends can use link layer addresses, on an LLNs, there is > significant advantages to using the 16-bit versions, and that may not > provide the detail one needs. > > So, I see no reason to forbid the PIO, but I agree that it might be > unusual to have it. > The above does explain a possible use for a PIO in this approach. I do think the draft could benefit from a *brief* description of the above so that future readers have some idea of why a PIO is allowed. Regards, Brian From rdroms.ietf@gmail.com Fri Feb 8 07: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 8A25A21F8A80; Fri, 8 Feb 2013 07:42:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.513 X-Spam-Level: X-Spam-Status: No, score=-103.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 zoU+Od+12p3T; Fri, 8 Feb 2013 07:42:02 -0800 (PST) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by ietfa.amsl.com (Postfix) with ESMTP id A71D421F8AAC; Fri, 8 Feb 2013 07:42:01 -0800 (PST) Received: by mail-ve0-f180.google.com with SMTP id jx10so3358020veb.39 for ; Fri, 08 Feb 2013 07:42:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=hjZAwEzT1XcbvLiG0hZbqaxYFgy/g1WkhRAltwL+Lc0=; b=Y/G/1yp55lWhDnCFdLd8mk2+4rYByQFk3TWoiJHPL2UGyLkBhaCtDGIeWImkd0e7/W KLpUZRuvueK/9TgR2zQMILFs2dM+BT+iSgFZIw8QJK11rs7wpaoATK04XHAagHXXmvI7 7dX+6n0dUOhC0gA3vyLrsIQWrb2fh3tFDob9tWcKABXNQEO7SmowX+hQB4LlfR/0ia/L vhxK340zvVcixI53tCvsuAczHmu8CbEGTha1Ki/fOJDA74ceG6SQTc8uLLvh2mb9bnmj 2QWcD1C7uFEMVLaIq+dn6ti/+z1mi8nH7Hj/dctXqN0IzVEvSibV5kjSNBEiRuhfCGKj GioQ== X-Received: by 10.220.205.134 with SMTP id fq6mr7046146vcb.24.1360338121076; Fri, 08 Feb 2013 07:42:01 -0800 (PST) Received: from ?IPv6:2001:420:2481:20:c9a8:311a:e6bb:eecc? ([2001:420:2481:20:c9a8:311a:e6bb:eecc]) by mx.google.com with ESMTPS id p7sm33354072vdt.2.2013.02.08.07.41.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 07:42:00 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ralph Droms In-Reply-To: <5114243D.9020607@innovationslab.net> Date: Fri, 8 Feb 2013 10:41:59 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <582BDC59-1096-4617-8609-99E2EC7639E2@gmail.com> References: <890914225.234527.1360175848049.JavaMail.root@mail17.pantherlink.uwm.edu> <5112A446.8030105@innovationslab.net> <466.1360244886@sandelman.ca> <5114243D.9020607@innovationslab.net> To: Michael Richardson X-Mailer: Apple Mail (2.1499) Cc: Haberman Brian , draft-ietf-roll-p2p-rpl@tools.ietf.org, roll@ietf.org, afarrel@juniper.net, The IESG , roll-chairs@tools.ietf.org Subject: Re: [Roll] use of PIO payloads in P2P DIO messages (was Re: Brian Haberman's Discuss on draft-ietf-roll-p2p-rpl-16: (with DISCUSS and COMMENT)) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 15:42:02 -0000 On Feb 7, 2013, at 5:01 PM 2/7/13, Brian Haberman = wrote: > Hi Michael, >=20 > On 2/7/13 8:48 AM, Michael Richardson wrote: >>=20 >> I am including the WG mailing list in my reply, and fixing the = subject. >> This relates to: >> = http://datatracker.ietf.org/streams/draft-ietf-roll-p2p-rpl/history/ >>=20 >> (If there is a better way to link to just Brian Haberman's comments >> in the history I don't know. I don't like the pop-up, I had to play >> browser tricks to get the above URL) >>=20 >> see inline below. >>=20 >> Brian> I am confused by the last bullet in 6.1. It states that a >> Brian> P2P-mode DIO may carry a PIO option, but no where does this >> Brian> document describe why (or how) that option would be used in = this >> Brian> approach. What benefit would including a PIO have? Where would = an >> Brian> arbitrary node in a RPL network get the information to include = in >> Brian> a PIO? >>=20 >> Brian raised an interesting question, and I had to think about this. >> I see this as an issue of "be liberal in what you accept", and a >> question of protecting future innovation by not saying things are >> illegal just because can't think what they mean right now. >>=20 >> However, after read the thread, I offer how I can see using a PIO in = a DIO. >>=20 >>>>>>> "Brian" =3D=3D Brian Haberman writes: >> >> Hi Brian >> >> >> >> Not sure what you mean. >> >> >> >> In P2P-RPL, the DAG is ephemeral but not the discovered = routes. >>=20 >> Brian> What I mean is it does not make sense (to me) to include >> Brian> information that is used to configure IPv6 addresses. >> Brian> Including a PIO in a DIO means that the Source node = expects >> Brian> children to autoconfigure addresses using the specified >> Brian> prefix. However, they already have addresses based on the >> Brian> PIO that would have come down the DODAG (originated at the >> Brian> root). I am trying to understand a use-case where having = new >>=20 >> You assume a root DODAG here, which might not (yet) exist. >> And, not all DODAGs are grounded, and therefore might not even have >> address space yet with which to send out PIOs. >>=20 >> There might not be any root controller/LBR yet, because the factory >> and/or house has not yet completed construction. >>=20 >> The resulting routes could consist of link layer addresses only, so = the >> light switch could still discover the light bulb when the = jiprock(wall) is >> still not yet up. >>=20 >> If one contemplates full EUI-64 based SLACC with the PIO in that DIO, >> then one would be able to see in the mDNS, (or other service = discovery) what >> the serial number of the light bulb/socket and controller was = involved. >> (What bulb did you just discover?) >>=20 >> While mDNS and friends can use link layer addresses, on an LLNs, = there is >> significant advantages to using the 16-bit versions, and that may not >> provide the detail one needs. >>=20 >> So, I see no reason to forbid the PIO, but I agree that it might be >> unusual to have it. >>=20 >=20 > The above does explain a possible use for a PIO in this approach. I = do think the draft could benefit from a *brief* description of the above = so that future readers have some idea of why a PIO is allowed. Has this use case been written down and discussed by the WG? I could see using a non-grounded DAG for this purpose as a way for a = stand-alone mesh to establish subnet communication. It seems inappropriate as a side-effect of a DAG established for = point-to-point communication between two mesh nodes. - Ralph >=20 > Regards, > Brian >=20 From mcr@sandelman.ca Fri Feb 8 09:06:00 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 D1DEF21F8B18 for ; Fri, 8 Feb 2013 09:06:00 -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 3WArsfn6HMTz for ; Fri, 8 Feb 2013 09:06:00 -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 1489A21F8B16 for ; Fri, 8 Feb 2013 09:06:00 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 25DDE20172; Fri, 8 Feb 2013 12:12:04 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id A74466376A; Fri, 8 Feb 2013 12:04:57 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 91E1063769; Fri, 8 Feb 2013 12:04:57 -0500 (EST) From: Michael Richardson To: roll@ietf.org, Mukul Goyal In-Reply-To: <5114243D.9020607@innovationslab.net> References: <890914225.234527.1360175848049.JavaMail.root@mail17.pantherlink.uwm.edu> <5112A446.8030105@innovationslab.net> <466.1360244886@sandelman.ca> <5114243D.9020607@innovationslab.net> 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: draft-ietf-roll-p2p-rpl@tools.ietf.org, Brian Haberman , roll-chairs@tools.ietf.org Subject: Re: [Roll] use of PIO payloads in P2P DIO messages (was Re: Brian Haberman's Discuss on draft-ietf-roll-p2p-rpl-16: (with DISCUSS and COMMENT)) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 17:06:00 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Suggested text, new section 9.8: 9.8 Processing of DIO options in a P2P Temporary DAG RFC6550 defines a number of DIO options. The DAG Metric (0x02), Routing Information (0x03) and DODAG Configuration (0x04).=20 The Prefix Information (0x08) would not normally be included=20 in the RPL P2P DIO messages. Any current or future DIO options are permitted in a P2P DIO message, and unknown ones should be ignored, and not cause the DIO message to be rejected as invalid.(XXX) In the specific case of Prefix Information in a DIO, this would normally cause a node to configure an address using that prefix. This is generally not desireable for the temporary DAG that P2P RPL wishes to construct. The P2P DIO SHOULD not include the Prefix Information option. A node that receives a P2P DIO with a PIO option and is a member of other DODAGs that have already provided it with Prefix Information MAY ignore the Prefix Information. The Prefix Information SHOULD be=20 copied into any DIO messages sent by this node. There is probably only a single use case for including Prefix Information into a P2P RPL. This would be the situation where a LLN is being installed, the LLN is not complete (has no border router yet) and the installers need to know if the components installed work, and more specifically if they have provisioned enough routers in the right places so that a P2P route can in fact be found. While the P2P route can consist of link-layer addresses, with the small size (16-bits) used as the MAC Address, it could be hard to relate an observed route back to actual devices involved. (XXX) - I don't think RFC6550 says what to do with options that a node does not understand. Specifically whether or not they should be copied into DIOs generated downstream by a node. I can think of arguments both ways!!! =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) iQCVAwUAURUwOYqHRg3pndX9AQI85gP+JFJW5UxFlbtiTaC7yH8OZx2TGxNx3mfS 4Uv98w1zotCbHF7uSmmTqphVqv7W2zqPULwelw24Ivc+BvNTqXqtwflTB8eAHISQ Dqhhdw5Wo0xfRBr6AcfD41q7rpEpWMY1ZOsZeCNNUOpZJRoK2CFskUH/vGi1llkW LunUYDTE7FE= =ua2P -----END PGP SIGNATURE----- --=-=-=-- From abdussalambaryun@gmail.com Fri Feb 8 09:52:08 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 6D6AD21F8A4B for ; Fri, 8 Feb 2013 09:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 QTCdTG6XfL-W for ; Fri, 8 Feb 2013 09:52:03 -0800 (PST) Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by ietfa.amsl.com (Postfix) with ESMTP id B8C5021F8A4A for ; Fri, 8 Feb 2013 09:52:01 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id hi8so1180283wib.13 for ; Fri, 08 Feb 2013 09:52: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=FjRvyAmK8FO/PRG8cWyJF6NEVHHKNAizc+0dDQDbZdo=; b=ThxSK0nDGZzzgI1tdPs/H1YrQ4Y9ugwcS4C+u9djU2smQ1ReNjlD9AoprhXEuNqhpt NPhhMz344ehvZwxKM+6G5rvI5M3oVbYBfSv+fbLMvLuYpqz499sRZOrC8NRlQn25MXRf 1nTzZokiSGdyK++Q30yEaF/LpwNZHXd+JzJMe7wJ66jR7G/C/n/UVUtJ1GzUEcWLpMsG Ug7DM8wFYN1G+Fdwo4+rl/Xu92uhV8Komx/6hj+o/QYRWX7ceQ9qQa42IpB5fgt+JfY2 SyOfpGvFNaB4yTC5u68Cj644rTdMo2zcKvKiXrL9Uk/FLqCoEqo9SNIgVkwq3nZ2QGuq KaKw== MIME-Version: 1.0 X-Received: by 10.180.77.35 with SMTP id p3mr4168666wiw.18.1360345920853; Fri, 08 Feb 2013 09:52:00 -0800 (PST) Received: by 10.180.101.70 with HTTP; Fri, 8 Feb 2013 09:52:00 -0800 (PST) In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD0AD3CB49@cph-ex1> References: <03F31C213F2C6941BFDDBB4336E9E6CD0AD364D1@cph-ex1> <5112D246.4090703@gridmerge.com> <03F31C213F2C6941BFDDBB4336E9E6CD0AD3CB49@cph-ex1> Date: Fri, 8 Feb 2013 18:52:00 +0100 Message-ID: From: Abdussalam Baryun To: Anders Brandt Content-Type: text/plain; charset=ISO-8859-1 Cc: "roll@ietf.org" Subject: Re: [Roll] Adoption of draft-brandt-roll-rpl-applicability-home-building as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 17:52:08 -0000 Hi Anders, So I understand draft change title/aim from RPL to P2P reason; the authors found that P2P-RPL is the best choice for home applications. My comments below, On 2/8/13, Anders Brandt wrote: > Abdussalam, > >>I agree that it is logical *to refer* and discuss applicability of RPL-P2P, >> but don't agree to change the aim >>of the draft from RPL to RPL-P2P. >>Do you think both protocols are similar, or do you think that RPL is not >> applicabile for home applications, just RPL-P2P? > > I think that the protocols are not similar and I think that P2P-RPL is > applicable for home applications. So I understand from your reply that you think RPL MAY NOT be applicabale for home and building application, > Restating Robert's comment, the draft in its original form was a sort of > problem statement which helps nobody designing anything. > The natural evolution of the draft was to describe how one could meet the > requirements for home applications; and to the authors > of the draft, P2P-RPL seems to be the best choice for home applications. > why it is best choice? this was not mentioned clearly in draft, > I have no intention of preventing others from evaluating the applicability > of RPL for home applications. I prefered discuss both in draft, so that RPL and RPL are protocols of ROLL and to describe how to meet the applicability for them in buildings and home, or describe P2P in this draft and leave others as P2MP and RPL in other draft if you like AB From mcr@sandelman.ca Fri Feb 8 10:06: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 52D4421F8B18; Fri, 8 Feb 2013 10:06:37 -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 kvqVg0mU29CQ; Fri, 8 Feb 2013 10:06:36 -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 C6D2621F8AD1; Fri, 8 Feb 2013 10:06:25 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id DAC652016D; Fri, 8 Feb 2013 13:12:17 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id A95B06376A; Fri, 8 Feb 2013 13:05:11 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 91CF263769; Fri, 8 Feb 2013 13:05:11 -0500 (EST) From: Michael Richardson To: Ralph Droms In-Reply-To: <582BDC59-1096-4617-8609-99E2EC7639E2@gmail.com> References: <890914225.234527.1360175848049.JavaMail.root@mail17.pantherlink.uwm.edu> <5112A446.8030105@innovationslab.net> <466.1360244886@sandelman.ca> <5114243D.9020607@innovationslab.net> <582BDC59-1096-4617-8609-99E2EC7639E2@gmail.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: Haberman Brian , draft-ietf-roll-p2p-rpl@tools.ietf.org, roll@ietf.org, afarrel@juniper.net, The IESG , roll-chairs@tools.ietf.org Subject: Re: [Roll] use of PIO payloads in P2P DIO messages (was Re: Brian Haberman's Discuss on draft-ietf-roll-p2p-rpl-16: (with DISCUSS and COMMENT)) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 18:06:37 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ralph" =3D=3D Ralph Droms writes: >>> You assume a root DODAG here, which might not (yet) exist. And, >>> not all DODAGs are grounded, and therefore might not even have >>> address space yet with which to send out PIOs. >>>=20 >>> There might not be any root controller/LBR yet, because the >>> factory and/or house has not yet completed construction. >>>=20 >>> The resulting routes could consist of link layer addresses only, >>> so the light switch could still discover the light bulb when the >>> jiprock(wall) is still not yet up. >>>=20 >>> If one contemplates full EUI-64 based SLACC with the PIO in that >>> DIO, then one would be able to see in the mDNS, (or other >>> service discovery) what the serial number of the light >>> bulb/socket and controller was involved. (What bulb did you >>> just discover?) >>>=20 >>> While mDNS and friends can use link layer addresses, on an LLNs, >>> there is significant advantages to using the 16-bit versions, >>> and that may not provide the detail one needs. >>>=20 >>> So, I see no reason to forbid the PIO, but I agree that it might >>> be unusual to have it. >>>=20 >> The above does explain a possible use for a PIO in this approach. >> I do think the draft could benefit from a *brief* description of >> the above so that future readers have some idea of why a PIO is >> allowed. Ralph> Has this use case been written down and discussed by the WG? Ralph> I could see using a non-grounded DAG for this purpose as a Ralph> way for a stand-alone mesh to establish subnet communication. Ralph> It seems inappropriate as a side-effect of a DAG established Ralph> for point-to-point communication between two mesh nodes. I hope you will read my suggested text. I agree that a piece of test equipment could create a non-grounded DAG. I think that the question is both: a) does the presence of a PIO render the DIO invalid? b) related to this, does the presence of an unknown DIO option render the DIO invalid? =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) iQCVAwUAURU+V4qHRg3pndX9AQIytgP/V2FL9MsyAZt+OXPEmwXh7vn8p6EIBcMk zOprPv5G4iHyb21m/O0yIdAO2TGBTVdMzoUjEUSYHKtNeT04iF35gE7Q8sTf4XT5 0GxqRmk97/f/w4baQP32HD9a381GwbPiNj/1/+gnPwhksl0BJCKuAMb4aBZ3/dQa YSEvDkJ9SKU= =xDuW -----END PGP SIGNATURE----- --=-=-=-- From rdroms.ietf@gmail.com Fri Feb 8 10:14: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 52AD921F8B85; Fri, 8 Feb 2013 10:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dX3Jkw8C0Mmu; Fri, 8 Feb 2013 10:14:22 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id D970F21F8B84; Fri, 8 Feb 2013 10:14:21 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fr13so2513646vbb.17 for ; Fri, 08 Feb 2013 10:14:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=yhbI10hWp31GZxxtYOLYh5IUoU2GQ5y8QkK1D6iY3fA=; b=EQIian6NePE/JTMJbjFviBoQtDJO8S52BqHtcoqQ3o7kHFQFTHU0JmAeYPdQkZ81Wu HYULhPY0b4IN6dgvCYIJaRO97IC1q/YG36Gm3XnZqQKkigd6gGB7raJYxHBmJhnbrKI1 cxFGsVLInBBTFmoZOuE4qhX5pgyUCJk7ddkWRT1skIxcrKK5mUDwYrkNt0fb9AdMwXUl 1m6G3Aen6aOsrOPO10YI3pH2tzHDqT1bPoYCQVYQW7DDwYvIrHetyNO+bXggNXA9aeLV xjtsTxFQX2nE4DGSlQY9Dd8iyFhVCq+jCr5K7XjVLkJHMH44dfkv8D550olgx6klOQaN 1jKQ== X-Received: by 10.52.67.105 with SMTP id m9mr6912323vdt.128.1360347261310; Fri, 08 Feb 2013 10:14:21 -0800 (PST) Received: from rtp-rdroms-89113.cisco.com (rtp-isp-nat1.cisco.com. [64.102.254.33]) by mx.google.com with ESMTPS id cd16sm45002188vdb.0.2013.02.08.10.14.19 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Feb 2013 10:14:20 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ralph Droms In-Reply-To: <4180.1360346711@sandelman.ca> Date: Fri, 8 Feb 2013 13:14:17 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <3E461F98-B6E5-4A73-ACA4-32D1AE989BEF@gmail.com> References: <890914225.234527.1360175848049.JavaMail.root@mail17.pantherlink.uwm.edu> <5112A446.8030105@innovationslab.net> <466.1360244886@sandelman.ca> <5114243D.9020607@innovationslab.net> <582BDC59-1096-4617-8609-99E2EC7639E2@gmail.com> <4180.1360346711@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1499) Cc: Haberman Brian , draft-ietf-roll-p2p-rpl@tools.ietf.org, roll@ietf.org, afarrel@juniper.net, The IESG , roll-chairs@tools.ietf.org Subject: Re: [Roll] use of PIO payloads in P2P DIO messages (was Re: Brian Haberman's Discuss on draft-ietf-roll-p2p-rpl-16: (with DISCUSS and COMMENT)) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 18:14:23 -0000 On Feb 8, 2013, at 1:05 PM 2/8/13, Michael Richardson = wrote: >=20 >>>>>> "Ralph" =3D=3D Ralph Droms writes: >>>> You assume a root DODAG here, which might not (yet) exist. And, >>>> not all DODAGs are grounded, and therefore might not even have >>>> address space yet with which to send out PIOs. >>>>=20 >>>> There might not be any root controller/LBR yet, because the >>>> factory and/or house has not yet completed construction. >>>>=20 >>>> The resulting routes could consist of link layer addresses only, >>>> so the light switch could still discover the light bulb when the >>>> jiprock(wall) is still not yet up. >>>>=20 >>>> If one contemplates full EUI-64 based SLACC with the PIO in that >>>> DIO, then one would be able to see in the mDNS, (or other >>>> service discovery) what the serial number of the light >>>> bulb/socket and controller was involved. (What bulb did you >>>> just discover?) >>>>=20 >>>> While mDNS and friends can use link layer addresses, on an LLNs, >>>> there is significant advantages to using the 16-bit versions, >>>> and that may not provide the detail one needs. >>>>=20 >>>> So, I see no reason to forbid the PIO, but I agree that it might >>>> be unusual to have it. >>>>=20 >>> The above does explain a possible use for a PIO in this approach. >>> I do think the draft could benefit from a *brief* description of >>> the above so that future readers have some idea of why a PIO is >>> allowed. >=20 > Ralph> Has this use case been written down and discussed by the WG? >=20 > Ralph> I could see using a non-grounded DAG for this purpose as a > Ralph> way for a stand-alone mesh to establish subnet communication. >=20 > Ralph> It seems inappropriate as a side-effect of a DAG established > Ralph> for point-to-point communication between two mesh nodes. >=20 > I hope you will read my suggested text. > I agree that a piece of test equipment could create a non-grounded = DAG. > I think that the question is both: > a) does the presence of a PIO render the DIO invalid? > b) related to this, does the presence of an unknown DIO option > render the DIO invalid? I did read your text, but your questions are predicated on a premise I = disagreed with in my previous answer, so I didn't comment on your text. I don't think there is ever a justification for a PIO in a P2P-RPL DIO. = Enabling mesh communication as a side-effect of forming a P2P DAG is = inappropriate. Use a non-grounded DAG for your use case. - Ralph >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh = networks [=20 > ] Michael Richardson, Sandelman Software Works | network = architect [=20 > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [=20 > =09 From prvs=7440ad569=mukul@uwm.edu Fri Feb 8 11:16: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 5D5A721F8BD1; Fri, 8 Feb 2013 11:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 qVIoyVRj-I4j; Fri, 8 Feb 2013 11:16:31 -0800 (PST) Received: from ip4mta.uwm.edu (ip4mta.uwm.edu [129.89.7.194]) by ietfa.amsl.com (Postfix) with ESMTP id 17C8521F8B81; Fri, 8 Feb 2013 11:16:30 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAOhNFVF/AAAB/2dsb2JhbAA/BoZNulSDEgEBBSNWDA8RBAEBAwINEgcCIy4IBhOHfwMPrFOIUA1MiQqBI4pzgRqDGYETA4hmi2WBWYtAhRODH4FHJBo Received: from localhost (localhost.localdomain [127.0.0.1]) by mta01.pantherlink.uwm.edu (Postfix) with ESMTP id 28DF01210B2; Fri, 8 Feb 2013 13:16:30 -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 v4UeDenk1cBC; Fri, 8 Feb 2013 13:16:29 -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 92F7F1210A7; Fri, 8 Feb 2013 13:16:29 -0600 (CST) Date: Fri, 8 Feb 2013 13:16:29 -0600 (CST) From: Mukul Goyal To: Michael Richardson Message-ID: <1809255242.265198.1360350989633.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <4180.1360346711@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - SAF3 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: Haberman Brian , draft-ietf-roll-p2p-rpl@tools.ietf.org, roll@ietf.org, afarrel@juniper.net, The IESG , roll-chairs@tools.ietf.org Subject: Re: [Roll] use of PIO payloads in P2P DIO messages (was Re: Brian Haberman's Discuss on draft-ietf-roll-p2p-rpl-16: (with DISCUSS and COMMENT)) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Feb 2013 19:16:32 -0000 I realized that some of the folks on this message might not have received Michael's text. So, here it is: Suggested text, new section 9.8: 9.8 Processing of DIO options in a P2P Temporary DAG RFC6550 defines a number of DIO options. The DAG Metric (0x02), Routing Information (0x03) and DODAG Configuration (0x04). The Prefix Information (0x08) would not normally be included in the RPL P2P DIO messages. Any current or future DIO options are permitted in a P2P DIO message, and unknown ones should be ignored, and not cause the DIO message to be rejected as invalid.(XXX) In the specific case of Prefix Information in a DIO, this would normally cause a node to configure an address using that prefix. This is generally not desireable for the temporary DAG that P2P RPL wishes to construct. The P2P DIO SHOULD not include the Prefix Information option. A node that receives a P2P DIO with a PIO option and is a member of other DODAGs that have already provided it with Prefix Information MAY ignore the Prefix Information. The Prefix Information SHOULD be copied into any DIO messages sent by this node. There is probably only a single use case for including Prefix Information into a P2P RPL. This would be the situation where a LLN is being installed, the LLN is not complete (has no border router yet) and the installers need to know if the components installed work, and more specifically if they have provisioned enough routers in the right places so that a P2P route can in fact be found. While the P2P route can consist of link-layer addresses, with the small size (16-bits) used as the MAC Address, it could be hard to relate an observed route back to actual devices involved. (XXX) - I don't think RFC6550 says what to do with options that a node does not understand. Specifically whether or not they should be copied into DIOs generated downstream by a node. I can think of arguments both ways!!! Thanks Mukul ----- Original Message ----- From: "Michael Richardson" To: "Ralph Droms" Cc: "Mukul Goyal" , "Anders Brandt" , draft-ietf-roll-p2p-rpl@tools.ietf.org, roll@ietf.org, afarrel@juniper.net, "The IESG" , "Haberman Brian" , roll-chairs@tools.ietf.org Sent: Friday, February 8, 2013 12:05:11 PM Subject: Re: use of PIO payloads in P2P DIO messages (was Re: Brian Haberman's Discuss on draft-ietf-roll-p2p-rpl-16: (with DISCUSS and COMMENT)) >>>>> "Ralph" == Ralph Droms writes: >>> You assume a root DODAG here, which might not (yet) exist. And, >>> not all DODAGs are grounded, and therefore might not even have >>> address space yet with which to send out PIOs. >>> >>> There might not be any root controller/LBR yet, because the >>> factory and/or house has not yet completed construction. >>> >>> The resulting routes could consist of link layer addresses only, >>> so the light switch could still discover the light bulb when the >>> jiprock(wall) is still not yet up. >>> >>> If one contemplates full EUI-64 based SLACC with the PIO in that >>> DIO, then one would be able to see in the mDNS, (or other >>> service discovery) what the serial number of the light >>> bulb/socket and controller was involved. (What bulb did you >>> just discover?) >>> >>> While mDNS and friends can use link layer addresses, on an LLNs, >>> there is significant advantages to using the 16-bit versions, >>> and that may not provide the detail one needs. >>> >>> So, I see no reason to forbid the PIO, but I agree that it might >>> be unusual to have it. >>> >> The above does explain a possible use for a PIO in this approach. >> I do think the draft could benefit from a *brief* description of >> the above so that future readers have some idea of why a PIO is >> allowed. Ralph> Has this use case been written down and discussed by the WG? Ralph> I could see using a non-grounded DAG for this purpose as a Ralph> way for a stand-alone mesh to establish subnet communication. Ralph> It seems inappropriate as a side-effect of a DAG established Ralph> for point-to-point communication between two mesh nodes. I hope you will read my suggested text. I agree that a piece of test equipment could create a non-grounded DAG. I think that the question is both: a) does the presence of a PIO render the DIO invalid? b) related to this, does the presence of an unknown DIO option render the DIO invalid? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From jvasseur@cisco.com Mon Feb 11 05:59: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 927E321F871F for ; Mon, 11 Feb 2013 05:59:36 -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=[AWL=0.000, 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 JRIUOTOsPGc6 for ; Mon, 11 Feb 2013 05:59:36 -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 0432921F86D9 for ; Mon, 11 Feb 2013 05:59:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=156; q=dns/txt; s=iport; t=1360591176; x=1361800776; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=OX+9oe1k54ITnMgOKGgJNt0fW3IshP/50+RFqEafALY=; b=LHxKFABbLJdvDgGJZmTFXyqrD2fK+09uP+vY2RFctUm67d3zLowNzieM yMiu1r0LrSMGzZx5LAmpnAsRqMJxPK9egjyTD+kkRYvSHFeEjkhgGR2+8 x37+QKrEICLKo9LIAj1S9K8IKx4ruMXhTC8HMSFx7RtmOPqW7JS+tr1Ac M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At8KAFv4GFGtJV2d/2dsb2JhbABEwBMBAwEDfRZzgiEBBDo/EgEqFEInBA4NiAq/Y5EsYQOmd4MGgiQ X-IronPort-AV: E=Sophos;i="4.84,643,1355097600"; d="scan'208";a="175694573" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 11 Feb 2013 13:59:35 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1BDxZ4T024682 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 11 Feb 2013 13:59:35 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.47]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0328.009; Mon, 11 Feb 2013 07:59:35 -0600 From: "JP Vasseur (jvasseur)" To: roll WG Thread-Topic: Agenda IETF-86 Thread-Index: AQHOCGAGluWBVSwKd0G0vcehJZbcKg== Date: Mon, 11 Feb 2013 13:59:35 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77232A3F3C@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.232] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Michael Richardson Subject: [Roll] Agenda IETF-86 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 13:59:36 -0000 Dear all, Please let us know by Feb 18th noon ET if you would like to have a "slot" a= t the next IETF ROLL WG meeting. Thanks. JP and Michael.= From stokcons@xs4all.nl Mon Feb 11 06:07:12 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 AB51A21F8891 for ; Mon, 11 Feb 2013 06:07:12 -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 c1C2av0vf-qB for ; Mon, 11 Feb 2013 06:07:10 -0800 (PST) Received: from smtp-vbr12.xs4all.nl (smtp-vbr12.xs4all.nl [194.109.24.32]) by ietfa.amsl.com (Postfix) with ESMTP id 2402A21F8B81 for ; Mon, 11 Feb 2013 06:07:08 -0800 (PST) Received: from roundcube.xs4all.nl (roundcube5.xs4all.net [194.109.20.203]) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id r1BE737k026977 for ; Mon, 11 Feb 2013 15:07:03 +0100 (CET) (envelope-from stokcons@xs4all.nl) Received: from AMontpellier-654-1-221-34.w109-210.abo.wanadoo.fr ([109.210.220.34]) by roundcube.xs4all.nl with HTTP (HTTP/1.1 POST); Mon, 11 Feb 2013 15:07:02 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Mon, 11 Feb 2013 15:07:02 +0100 From: peter van der Stok To: Organization: vanderstok consultancy Mail-Reply-To: In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD0AD364D1@cph-ex1> References: <03F31C213F2C6941BFDDBB4336E9E6CD0AD364D1@cph-ex1> Message-ID: <34f92a2622dfbe34506170a2cbfafca8@xs4all.nl> X-Sender: stokcons@xs4all.nl (/5jqwMGNimlbkFe8y0jsHiPGd3mChv5f) User-Agent: XS4ALL Webmail X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: [Roll] Adoption of draft-brandt-roll-rpl-applicability-home-building as a new ROLL WG document 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, 11 Feb 2013 14:07:12 -0000 Hi Anders, I do miss a discussion on the reliability of the P2P communication coupled to timeliness. LLN have the property that links are lost during unknown periods. The path using the link is unusable during that period. It takes some time before alternative paths are found and established. Using multiple paths avoiding link duplication is essential to provide reliability with timeliness. A simple frequently occurring example is the one-hop path from A to B. The link can fail during seconds. Having an alternative two hop path routing a copy "simultaneously" will make quite a difference. I understood that P2P routing includes multipath routing, and hope you will put some more emphasis on this aspect. Greetings, peter Anders Brandt schreef op 2013-02-06 09:52: > Dear WG, > > The applicability statement document for home and building has been > updated: > http://tools.ietf.org/html/draft-brandt-roll-rpl-applicability-home-building-03 > > At this time, the authors would like to ask that the document as > adopted as a working group document. > > Thanks, > Anders Brandt > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Mon Feb 11 09:05: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 E64E421F86DD for ; Mon, 11 Feb 2013 09:05:03 -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 4X8CWEOlVF3T for ; Mon, 11 Feb 2013 09:05:03 -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 30F6721F8694 for ; Mon, 11 Feb 2013 09:05:02 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id DCA9C2016D for ; Mon, 11 Feb 2013 12:11:14 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 5D8C96376A; Mon, 11 Feb 2013 12:03:56 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4C4E2636C5 for ; Mon, 11 Feb 2013 12:03:56 -0500 (EST) From: Michael Richardson To: roll WG In-Reply-To: <03B78081B371D44390ED6E7BADBB4A77232A3F3C@xmb-rcd-x02.cisco.com> References: <03B78081B371D44390ED6E7BADBB4A77232A3F3C@xmb-rcd-x02.cisco.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] Agenda IETF-86 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2013 17:05:04 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Please be aware that WG meeting time is for resolving open issues in current documents. This is not in general a time for presentations. If you have new work that you think the WG should know about, then: 1) please make sure that there is a draft-foobar- submitted before the deadline. See http://www.ietf.org/meeting/cutoff-dates-2013.html#IETF86 so that means that -00 documents must be in by Feb. 18.=20 THAT IS NEXT WEEK. =20=20 2) if you plan to use slides, I need to get them Monday Feb. 25. Slides will not be accepted at the last minute. The reason to have the slides early is so that we can be sure that your work belongs in the ROLL WG. Many people download the slides to follow along either because they are participating remotely, and they are also very valuable for non-native-english speakers. 3) we will judge interest to the WG by existence of discussion on IETF lists. =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) iQCVAwUAURkkfIqHRg3pndX9AQJ+xQP/V8ttWDttG3QraAij5tLEuDcY9RroSQz2 QSt9CwL2ofuQggyig6LdofL3sBtNXMuHsG8e7ihIhipEJf5bLfVszcNuX2p0M6to RWluaEFhjRHrxzzhVzzpAFfkWqLJAm/5hUQcjyqvMtxMUSeTn4eEkjL5r9G5LnNm iABsxb5GiaE= =06Ft -----END PGP SIGNATURE----- --=-=-=-- From vallati@cng1.iet.unipi.it Wed Feb 13 01:47: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 A861121F8826 for ; Wed, 13 Feb 2013 01:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.955 X-Spam-Level: X-Spam-Status: No, score=0.955 tagged_above=-999 required=5 tests=[AWL=-0.185, BAYES_20=-0.74, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wVta6dOD4GyC for ; Wed, 13 Feb 2013 01:47:40 -0800 (PST) Received: from cng1.iet.unipi.it (cng1.iet.unipi.it [131.114.58.243]) by ietfa.amsl.com (Postfix) with ESMTP id 3256D21F8820 for ; Wed, 13 Feb 2013 01:47:40 -0800 (PST) Received: from [10.114.228.2] (unknown [10.114.228.2]) by cng1.iet.unipi.it (Postfix) with ESMTPS id E318D5E1A4F for ; Wed, 13 Feb 2013 09:47:49 +0000 (UTC) Message-ID: <511B613B.7080508@cng1.iet.unipi.it> Date: Wed, 13 Feb 2013 10:47:39 +0100 From: Carlo Vallati User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: [Roll] IEEE IoT-SoS 2013 - Call for papers X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2013 09:53:14 -0000 ------------------------------------------------------------------------ - Our apologies if you receive multiple copies of this CFP - ------------------------------------------------------------------------ ***** PAPER SUBMISSION DEADLINE ***** FEBRUARY 28, 2013 (11:59pm EST) ------------------------------------------------------------------------ CALL FOR PAPERS IoT-SoS 2013 Second IEEE Workshop on the Internet of Things: Smart Objects and Services http://www.ing.unipi.it/iot-sos2013 co-located with IEEE WoWMoM 2013 sponsored by IEEE, IEEE Computer Society June 4, 2013 Madrid, Spain ------------------------------------------------------------------------ The Internet of Things (IoT) is a novel paradigm which is shaping the evolution of the future Internet. According to the vision underlying the IoT, the next step in increasing the ubiquity of the Internet, after connecting people anytime and everywhere, is to connect inanimate objects. By providing objects with embedded communication capabilities and a common addressing scheme, a highly distributed and ubiquitous network of seamlessly connected heterogeneous devices is formed, which can be fully integrated into the current Internet and mobile networks, thus allowing for the development of new intelligent services available anytime, anywhere, by anyone and anything. Such a vision is also becoming known under the name of Machine-to-Machine (M2M), where the absence of human interaction in the system dynamics is further stressed. Many applications with high social and business impact fall under the IoT/M2M umbrella, including personal healthcare, smart grid, surveillance, home automation, intelligent transportation, while it is expected that new ones will emerge once the enabling technologies reach a stable state. At the moment, two of the most important challenges are: i) the definition of architectures, protocols and algorithms for an efficient interconnection of smart objects, both between themselves and with the (Future) Internet; and ii) the creation of value-added services, esp. open and interoperable, enabled by the interconnection of things / machines / smart objects, in such a way that they can be integrated with current and new business and development processes. The aim of this workshop is to bring together practitioners and researchers from both academia and industry in order to have a forum for discussion and technical presentations on the recent advances in theory, application and implementation of the Internet of Things concept: technologies, protocols, algorithms, and services. Topics of interest include, but are not limited to: - System architectures for the IoT/M2M - Communication protocols for the IoT/M2M - Service platforms for the IoT/M2M - Enabling technologies and standards for the IoT/M2M - Mobility management - Context awareness - Sustainable design - Location-based services and geographic information systems - Experimental prototypes and large-scale testbed infrastructures - Performance evaluation of IoT/M2M solutions - Convergence with the Internet of Services - Applications, including: eHealth/mHealth; Smart Grid/Smart Metering; connected consumer; fleet management; surveillance; Intelligent Transportation Systems; Smart House/Neighborhood/City - Business development and processes - Industrial use cases showing gaps to be filled by future research PAPER SUBMISSION AND PUBLICATION All submissions must describe original research, not published or currently under review for another workshop, conference, or journal. Papers must be submitted electronically to EDAS by February 28, 2013, 11:59pm EST. You can find detailed submission instructions at http://www.ing.unipi.it/iot-sos2013/submission.shtml. Submission implies the willingness of at least one author to attend the workshop and present the paper. Accepted papers will be included in the main proceedings of IEEE WoWMoM 2013 and published by IEEE. IMPORTANT DATES Manuscripts Due: February 28, 2013. Acceptance Notification: March 25, 2013. Camera-ready Submission: April 8, 2013. WORKSHOP CHAIR Susana Sargento, University of Aveiro, Portugal WORKSHOP VICE-CHAIR Carlo Vallati, University of Pisa, Italy STEERING COMMITEE Jaudelice Cavalcante de Oliveira, Drexel University, PA, USA. Claudio Cicconetti, INTECS, Italy. Xiaohua Jia, City University of Hong Kong, Hong Kong. Enzo Mingozzi, University of Pisa, Italy. TECHNICAL PROGRAM COMMITTEE Ana Aguiar, University of Porto, Portugal Baris Atakan, Georgia Institute of Technology, USA Luigi Atzori, University of Cagliari, Italy Angelo Castellani, University of Padova, Italy Biao Chen, University of Macau, Macao Huang Chuanhe, Whuhan University, P.R. China Hongwei Du, Harbin Institute of Technology Shenzhen Graduate School, P.R. China Andrzej Duda, Grenoble Institute of Technology, France Mukul Goyal, University of Wisconsin - Milwaukee, USA Burhan Gulbahar, Koc University, Turkey Yuan Guo, Wilson, Ham & Holman, USA Antonio Iera, University Mediterranea of Reggio Calabria, Italy Alessandro Mamelli, Hewlett-Packard, Italy Belén Martínez, Tecnalia, Spain Francisco Javier Nieto De-Santos, ATOS, Spain Kostas Pentikousis, Huawei Technologies, Germany Dirk Pesch, Cork Institute of Technology, Ireland Kay Römer, University of Lübeck, Germany Jean-Philippe Vasseur, Cisco Systems, USA Serdar Vural, University of Surrey, UK Dexiang Wang, University of Florida, USA Yan Zhang, Simula Research Laboratory and University of Oslo, Norway -- ------------------------------------- Carlo Vallati, PhD Post Doc Researcher Computer Networking Group Dipartimento di Ingegneria dell'Informazione Università di Pisa Via Diotisalvi 2, 56122 Pisa - Italy Ph. : (+39) 050-2217.572 (direct) .599 (switch) Fax : (+39) 050-2217.600 Skype: warner83 E-mail: carlo.vallati@iet.unipi.it http://cng1.iet.unipi.it/~vallati/ ----------------------------------------------- From trac+roll@trac.tools.ietf.org Fri Feb 15 08:43: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 A9FC621F8893 for ; Fri, 15 Feb 2013 08:43:04 -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 4BaRa+50Mea1 for ; Fri, 15 Feb 2013 08:43:02 -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 5D4DA21F8869 for ; Fri, 15 Feb 2013 08:43:01 -0800 (PST) Received: from localhost ([127.0.0.1]:58911 helo=grenache.tools.ietf.org ident=www-data) by grenache.tools.ietf.org with esmtp (Exim 4.80) (envelope-from ) id 1U6ONE-0002g3-48; Fri, 15 Feb 2013 17:42:56 +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: Fri, 15 Feb 2013 16:42:56 -0000 X-URL: http://tools.ietf.org/wg/roll/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/roll/trac/ticket/113 Message-ID: <068.911b32936c333d1785fb02055eb8148d@trac.tools.ietf.org> X-Trac-Ticket-ID: 113 X-SA-Exim-Connect-IP: 127.0.0.1 X-SA-Exim-Rcpt-To: abdussalambaryun@gmail.com, draft-ietf-roll-trickle-mcast@tools.ietf.org, 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: <20130215164301.5D4DA21F8869@ietfa.amsl.com> Resent-Date: Fri, 15 Feb 2013 08:43:01 -0800 (PST) Resent-From: trac+roll@trac.tools.ietf.org Cc: roll@ietf.org, draft-ietf-roll-trickle-mcast@tools.ietf.org Subject: [Roll] [roll] #113: MPL Processing Section X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Reply-To: roll@ietf.org List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2013 16:43:04 -0000 #113: MPL Processing Section I found how the protocol is processing messages but not sure about the processing of MPL. I think that one important section should be clear about the protocol function (section 4 is not enough and not specific its an overview), Is the MPL protocol processing only about the processing of its messages? AB -- ----------------------------------------+---------------------------------- Reporter: abdussalambaryun@gmail.com | Owner: Abdussalam Baryun Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: trickle-mcast | Version: 1.0 Severity: Active WG Document | Keywords: Multicast, RPL, | Trickle ----------------------------------------+---------------------------------- Ticket URL: roll From abdussalambaryun@gmail.com Fri Feb 15 18:42:00 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 6F3A321F8461; Fri, 15 Feb 2013 18:41:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.021, 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 TahHawXAINwO; Fri, 15 Feb 2013 18:41:50 -0800 (PST) Received: from mail-wi0-x229.google.com (wi-in-x0229.1e100.net [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6DA1F21F81FF; Fri, 15 Feb 2013 18:41:28 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id l13so2034160wie.0 for ; Fri, 15 Feb 2013 18:40: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=7TwCseVVEvyEY9AFTq/vUsCm8XV5mrRoXwNBseiS+mo=; b=Hujak3I/uHbiAwyOHZPh726CLtYMbJTv4PitQh3zhXkfDvNXvTr/BAJ+Iu2Uu9cOHQ OaFSXGkqYchD25675JKvJT5DWg/9UnNymaXGWpWW+koEXnmdfRfUSPnmr9r6ApZruRww rYO5uRqnbHWlwP1TRTSpN6sVDCjdc32mFReNutyziRH118HFgQBWLXgVVab8nyHC0cTZ +O3U1o+UMn9Pycz8/w66ftR9ZPbI1kV1vxHYS+Fr+IyWsApz5UwwRBKMYQyvrqUEAI7v Yq+3qSjXWJRZsPwph+YB/ZzgaWvW6VyhUTbenzmGMUZmpFMasYeRu95/6d2LHiqadxHP BhPg== MIME-Version: 1.0 X-Received: by 10.180.94.69 with SMTP id da5mr9296723wib.30.1360981813712; Fri, 15 Feb 2013 18:30:13 -0800 (PST) Received: by 10.180.101.70 with HTTP; Fri, 15 Feb 2013 18:30:13 -0800 (PST) Date: Sat, 16 Feb 2013 03:30:13 +0100 Message-ID: From: Abdussalam Baryun To: "its@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Cc: roll Subject: [Roll] Using ROLL technique in ITS X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Feb 2013 02:42:01 -0000 I think it is reasonable to include applications of the ROLL efforts into ITS, not only to consider Mobile-IP. On 2/15/13, Alexandru Petrescu wrote: > Intelligent Transportation Systems (ITS) are composed of mobile and > fixed computing and communicating equipment. The fixed access points > are deployed along terrestrial roads (e.g. Road-Side Units), shores > along water paths; alternatively, mobile or fixed access points may be > deployed above ground; they all offer wireless access to equipment > deployed in mobile vehicles (e.g. On-Board Units). The entire system > is connected to the Internet through one or several IP paths. In this > system, disjoint and heterogeneous radio systems are used (e.g. a > vehicle uses two different radios). I will try to amend; Intelligent Transportation Systems (ITS) are composed of interconnected systems of machines; vehicles, mobile devices and fixed embedded devices (actuator and sensors). These machines communicate with fixed access points which are are deployed along terrestrial roads (e.g. Road-Side Units), shores along water paths; alternatively, mobile or fixed access points may be deployed above ground; they all offer wireless access to equipment deployed in mobile vehicles (e.g. On-Board Units). The entire system is connected to the Internet through one or several IP paths. In this system, disjoint and heterogeneous radio systems are used (e.g. a vehicle uses two different radios). AB From jvasseur@cisco.com Sat Feb 16 01:28: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 63D7F21F8536 for ; Sat, 16 Feb 2013 01:28:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.086 X-Spam-Level: X-Spam-Status: No, score=-9.086 tagged_above=-999 required=5 tests=[AWL=-0.908, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_GIF_ATTACH=1.42] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52Ve-kCmbrQd for ; Sat, 16 Feb 2013 01:28:40 -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 81F1F21F852C for ; Sat, 16 Feb 2013 01:28:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11007; q=dns/txt; s=iport; t=1361006920; x=1362216520; h=from:to:subject:date:message-id:mime-version; bh=qMV97T8DVA1asuLGJNnWks/Un7plex4gr8xkZ5JJAQg=; b=S3j7++LEFJaxuiqV9Sfi2yBykX6d994lwjRiBUW7RinCOgEb7W76GZNX GoZxa0NVK0Z2RM6bmEdZbuGgjwa2NQ7TmqZHTPaEIZOPf0Pbkgl78tyx9 zhyMX4HoWhQluwou9LSdTzcnNPtLCWSs6WHus+Ylqey+3dCcmxVMfLKkD A=; X-Files: color-palette-4x4.gif : 102 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEFABpQH1GtJXHA/2dsb2JhbABEgkOsDIktAYgffBZzgiEBBAVfJwElAQICJgUQAQUJDCcEEgEGAgaIBAycIKBYjXGBDy2CamEDjQqDNIcLjzuDB4In X-IronPort-AV: E=Sophos;i="4.84,678,1355097600"; d="gif'147?scan'147,208,217,147";a="177876606" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-4.cisco.com with ESMTP; 16 Feb 2013 09:28: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 r1G9SYhq009765 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 16 Feb 2013 09:28:34 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.47]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Sat, 16 Feb 2013 03:28:34 -0600 From: "JP Vasseur (jvasseur)" To: roll WG Thread-Topic: ROLL WG Meeting IETF 86 Thread-Index: AQHODCf9yoWhBGRoZU+pTrKyCX+MgQ== Date: Sat, 16 Feb 2013 09:28:33 +0000 Message-ID: <03B78081B371D44390ED6E7BADBB4A77232BD66C@xmb-rcd-x02.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.60.114.233] Content-Type: multipart/related; boundary="_004_03B78081B371D44390ED6E7BADBB4A77232BD66Cxmbrcdx02ciscoc_"; type="multipart/alternative" MIME-Version: 1.0 Subject: [Roll] ROLL WG Meeting IETF 86 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 16 Feb 2013 09:28:41 -0000 --_004_03B78081B371D44390ED6E7BADBB4A77232BD66Cxmbrcdx02ciscoc_ Content-Type: multipart/alternative; boundary="_000_03B78081B371D44390ED6E7BADBB4A77232BD66Cxmbrcdx02ciscoc_" --_000_03B78081B371D44390ED6E7BADBB4A77232BD66Cxmbrcdx02ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 0900-1020 Tuesday Morning Session I Caribbean 3 RAI rtcweb [cid:D89A0331-30D2-40C3-A19C-B0D4262F103D@cisco.com] Real-Time Communi= cation in WEB-browsers Caribbean 4 INT intarea [cid:D89A0331-30D2-40C3-A19C-B0D4262F103D@cisco.com] Internet Area Wor= king Group Caribbean 5 RTG pwe3 = [cid:D89A0331-30D2-40C3-A19C-B0D4262F103D@cisco.com] Pseudowire Emulat= ion Edge to Edge Caribbean 2 RTG roll = [cid:D89A0331-30D2-40C3-A19C-B0D4262F103D@cisco.com] Routing Over Low = power and Lossy networks Caribbean 1 APP aggsrv [cid:D89A0331-30D2-40C3-A19C-B0D4262F103D@cisco.com]= Aggregated Service Discovery BOF Caribbean 6 TSV tcpm = [cid:D89A0331-30D2-40C3-A19C-B0D4262F103D@cisco.com] TCP Maintenance a= nd Minor Extensions Boca 2 O= PS bmwg [cid= :D89A0331-30D2-40C3-A19C-B0D4262F103D@cisco.com] Benchmarking Methodology Boca 1 S= EC ipsecme [cid= :D89A0331-30D2-40C3-A19C-B0D4262F103D@cisco.com] IP Security Maintenance a= nd Extensions --_000_03B78081B371D44390ED6E7BADBB4A77232BD66Cxmbrcdx02ciscoc_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable 0900-1020
Tuesday Morning Session I<= /td>
Caribbean 3 RAI rtcweb 3D"" Real-Time Communication in WEB-browsers
Caribbean 4 INT intarea 3D"" Internet Area Working Group
Caribbean 5 RTG pwe3 3D"" Pseudowire Emulation Edge to Edge
Caribbean 2 RTG roll 3D"" Routing Over Low power and Lossy networks
Caribbean 1 APP aggsrv 3D"" Aggregated Service Discovery BOF
Caribbean 6 TSV tcpm 3D"" TCP Maintenance and Minor Extensions
Boca 2 OPS bmwg 3D"" Benchmarking Methodology
Boca 1 SEC ipsecme 3D"" IP Security Maintenance and Extensions

--_000_03B78081B371D44390ED6E7BADBB4A77232BD66Cxmbrcdx02ciscoc_-- --_004_03B78081B371D44390ED6E7BADBB4A77232BD66Cxmbrcdx02ciscoc_ Content-Type: image/gif; name="color-palette-4x4.gif" Content-Description: color-palette-4x4.gif Content-Disposition: inline; filename="color-palette-4x4.gif"; size=102; creation-date="Sat, 16 Feb 2013 09:28:33 GMT"; modification-date="Sat, 16 Feb 2013 09:28:33 GMT" Content-ID: Content-Transfer-Encoding: base64 R0lGODlhEAAQAMIDAAAA//8AAP//AP///6CgoP///////////yH5BAEKAAcALAAAAAAQABAAAAMr eLrc/jA6Qmm4d1aCc9tcp1VdMFpiA6yr4LoO275CLNO1etM2i0vAoLCRAAA7 --_004_03B78081B371D44390ED6E7BADBB4A77232BD66Cxmbrcdx02ciscoc_-- From jeonggil.ko@gmail.com Sat Feb 16 22:27: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 2D8CF21F88DB for ; Sat, 16 Feb 2013 22:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_TOOL=2.3, 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 dtKRvp7Mt-iD for ; Sat, 16 Feb 2013 22:27:00 -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 A8BA921F86B3 for ; Sat, 16 Feb 2013 22:27:00 -0800 (PST) Received: by mail-da0-f42.google.com with SMTP id z17so2033368dal.15 for ; Sat, 16 Feb 2013 22:27:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=UMQM6Q8gSih0hu3YVGa3FHMLVRftK/TfITkeHRMdlns=; b=rNrL6iXpv1g7gytkLpjLzOScBRBrIn9I+banJ+BwsI90NJaHwWmKRMznt7s0AIYDlJ 5ram7dNKppFotkQVnNU2OO01LizkaJYInGXGXn1eqzISoepJWrE1tmqg/m713JH/BJ2x ChhEGcx/KzvpGgWmJz3iLiv4aRSp04O3uRgYY5bdBDVVHl4ZxYy1wP3773J58mzm8sOX 3o4tiXGxXUp/vhkDZg/OwL0OodT6CJps91Wc236RhJPMWbEmCNChqE5PqgwOXZ2nsRnU EpG3HC4F1MEJ85Ohl+XBN7UuQCuP5Nm/IG+wtO14IlU7hjTMR2zBmPMs8A7CHMka64EV zZ2A== X-Received: by 10.68.41.229 with SMTP id i5mr19530861pbl.62.1361082420510; Sat, 16 Feb 2013 22:27:00 -0800 (PST) Received: from [10.211.10.10] ([129.254.38.231]) by mx.google.com with ESMTPS id k7sm86031130paz.13.2013.02.16.22.26.57 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Feb 2013 22:26:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: JeongGil Ko Date: Sun, 17 Feb 2013 15:26:57 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <433A2C5A-D8FC-4E85-B716-D8EE29613CBC@gmail.com> References: <20130217061648.13969.27807.idtracker@ietfa.amsl.com> To: roll WG X-Mailer: Apple Mail (2.1499) Cc: JeongGil Ko Subject: [Roll] Fwd: New Version Notification for draft-ko-roll-mix-network-pathology-02.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, 17 Feb 2013 06:27:01 -0000 WG and Chairs, A new version of ID draft-ko-roll-mix-network-pathology has been = uploaded. Please take a look and let me know of any comments you may = have. Compared to -01, -02 addresses the issues discussed at the previous = meeting in Atlanta such as how a RPL network of mixed storing and = non-storing mode nodes react to parent set changes (e.g., routing state = management). I would like to receive comments here on the mailing list and also = request for a slot at the Orlando meeting next month for further = discussions. Thanks! -John=20 Begin forwarded message: > From: > Subject: New Version Notification for = draft-ko-roll-mix-network-pathology-02.txt > Date: February 17, 2013 3:16:48 PM GMT+09:00 > To: > Cc: , , , = , >=20 >=20 >=20 > A new version of I-D, draft-ko-roll-mix-network-pathology-02.txt > has been successfully submitted by JeongGil Ko and posted to the > IETF repository. >=20 > Filename: draft-ko-roll-mix-network-pathology > Revision: 02 > Title: RPL Routing Pathology In a Network With a Mix = of Nodes Operating in Storing and Non-Storing Modes > Creation date: 2013-02-15 > Group: Individual Submission > Number of pages: 9 > URL: = http://www.ietf.org/internet-drafts/draft-ko-roll-mix-network-pathology-02= .txt > Status: = http://datatracker.ietf.org/doc/draft-ko-roll-mix-network-pathology > Htmlized: = http://tools.ietf.org/html/draft-ko-roll-mix-network-pathology-02 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ko-roll-mix-network-pathology-02 >=20 > Abstract: > The RPL specification allows nodes running with storing or non- > storing modes to operate in the same network. We describe how such = a > mix can result in network partitioning even when there are plenty of > physical links available in the network. The partitioning affects > both upwards (nodes to root) and downwards (root to leaf) traffic. > This routing pathology stems from a recommendation made in the RPL > specification forcing nodes with different modes of operation to = join > the RPL network as leaf nodes only. We propose a solution that > modifies RPL by mandating that all the nodes parse and interpret > source routing headers and storing mode nodes to sometimes act like = a > non-storing mode root by attaching source routing headers. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From Anders_Brandt@sigmadesigns.com Sun Feb 17 23:51: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 E245A21F8BC9 for ; Sun, 17 Feb 2013 23:51:23 -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 ycMghosAaGIP for ; Sun, 17 Feb 2013 23:51:23 -0800 (PST) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2F021F8BAF for ; Sun, 17 Feb 2013 23:51:22 -0800 (PST) From: Anders Brandt To: "consultancy@vanderstok.org" , "roll@ietf.org" Thread-Topic: [Roll] Adoption of draft-brandt-roll-rpl-applicability-home-building as a new ROLL WG document Thread-Index: Ac4ERwPxNgU2iwXiS92qsW9XbB2IZwEEaqsAAVTxlsA= Date: Mon, 18 Feb 2013 07:51:19 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0AD3EF24@cph-ex1> References: <03F31C213F2C6941BFDDBB4336E9E6CD0AD364D1@cph-ex1> <34f92a2622dfbe34506170a2cbfafca8@xs4all.nl> In-Reply-To: <34f92a2622dfbe34506170a2cbfafca8@xs4all.nl> Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] Adoption of draft-brandt-roll-rpl-applicability-home-building as a new ROLL WG document X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 18 Feb 2013 07:51:24 -0000 Hi Peter > I understood that P2P routing includes multipath routing, and hope you wi= ll put some more emphasis on this aspect. Thanks for the input - Good point! I will make sure to get that into the next version. - Anders -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of pet= er van der Stok Sent: 11. februar 2013 15:07 To: roll@ietf.org Subject: Re: [Roll] Adoption of draft-brandt-roll-rpl-applicability-home-bu= ilding as a new ROLL WG document Hi Anders, I do miss a discussion on the reliability of the P2P communication coupled = to timeliness. LLN have the property that links are lost during unknown periods. The path = using the link is unusable during that period. It takes some time before alternative paths are found and established. Using multiple paths avoiding link duplication is essential to provide reli= ability with timeliness. A simple frequently occurring example is the one-hop path from A to B. The link can fail during seconds. Having an alternative two hop path routin= g a copy "simultaneously" will make quite a difference. I understood that P2P routing includes multipath routing, and hope you will= put some more emphasis on this aspect. Greetings, peter Anders Brandt schreef op 2013-02-06 09:52: > Dear WG, >=20 > The applicability statement document for home and building has been > updated: > http://tools.ietf.org/html/draft-brandt-roll-rpl-applicability-home-bu > ilding-03 >=20 > At this time, the authors would like to ask that the document as=20 > adopted as a working group document. >=20 > Thanks, > Anders Brandt >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From internet-drafts@ietf.org Wed Feb 20 08:51: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 B1F6021F88B0; Wed, 20 Feb 2013 08:51: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 nW7+756S68Yt; Wed, 20 Feb 2013 08:51:38 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C36E421E803D; Wed, 20 Feb 2013 08:51: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.40 Message-ID: <20130220165137.23382.57792.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2013 08:51:37 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-terminology-11.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 16:51:38 -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-11.txt Pages : 8 Date : 2013-02-18 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-11 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-terminology-11 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From mcr@sandelman.ca Wed Feb 20 10:59:25 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 738B821F87E1 for ; Wed, 20 Feb 2013 10:59:25 -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 HEBPuzp+d5+r for ; Wed, 20 Feb 2013 10:59:25 -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 EA88521F8780 for ; Wed, 20 Feb 2013 10:59:24 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 2A7E220168 for ; Wed, 20 Feb 2013 14:06:11 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id EC4486376B; Wed, 20 Feb 2013 13:58:16 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id DDECD6376A for ; Wed, 20 Feb 2013 13:58:16 -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] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Wed, 20 Feb 2013 18:59:25 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable This is to start a 1 week WG call on adopting=20 Applicability Statement: The use of RPL-P2P in Home and Building Control draft-brandt-roll-rpl-applicability-home-building-03 as a WG document.=20=20 Please, if you have objection to this document as a starting document towards use of RPL in Home and Building LLN networks, please speak by=20 2013-02-28. =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) iQCVAwUAUSUcyIqHRg3pndX9AQJH+QP+O2spyIv7FliWMeGaBMKP61a5Q3cM2vuO sP09sXlPYDIR4BLTKDGQkMTJd8+0b6Nc4wnkKQcjfSORJUqisPA5uEFO6CF5VxT9 DMbeVMe8gGGvsW0TO0IXR5au0xuwpVqF8xOP5M1gOREBJFTqhAJm7u6ADC/hPN1d U0qyYkZL4J4= =QbX9 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Wed Feb 20 11:04: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 7005A21F88E3 for ; Wed, 20 Feb 2013 11:04:15 -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 5MhVOQvN12Rz for ; Wed, 20 Feb 2013 11:04:15 -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 DF6B821F88C7 for ; Wed, 20 Feb 2013 11:04:14 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9924A20168 for ; Wed, 20 Feb 2013 14:11:00 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 608886376B; Wed, 20 Feb 2013 14:03:06 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 50AC26376A for ; Wed, 20 Feb 2013 14:03:06 -0500 (EST) From: Michael Richardson To: roll@ietf.org X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Wed, 20 Feb 2013 14:03:06 -0500 Message-ID: <17078.1361386986@sandelman.ca> Sender: mcr@sandelman.ca Subject: [Roll] WG call to adopt draft-phinney-roll-rpl-industrial-applicability-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 20 Feb 2013 19:04:15 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable This is to start a 1 week WG call on adopting RPL applicability in industrial networks draft-phinney-roll-rpl-industrial-applicability-01 Abstract The wide deployment of wireless devices, with their low installed cost (compared to wired devices), will significantly improve the productivity and safety of industrial plants. It will simultaneously increase the efficiency and safety of the plant's workers, by extending and making more timely the information set available about plant operations. The new Routing Protocol for Low Power and Lossy Networks (RPL) defines a Distance Vector protocol that is designed for such networks. The aim of this document is to analyze the applicability of that routing protocol in industrial LLNs formed of as a WG document. This is part of satisfying the ROLL Charter. Please, if you have objection to this document as a starting document towards use of RPL in Industrial Control networks please speak by 2013-02-28. =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) iQCVAwUAUSUd6oqHRg3pndX9AQKKoAQA74E362sP8FGtwva5MgsfM2OwQHhKCqPa 9VJpfV5+nxprUvvuANYw94UdJFbfEtbvaVwRTs/OzbBXYM8zzFTfxe/CGRN+44il Zr6c4kUetIodydLQSq8x1iB0kHzDLcU0vY4mYUWGL/mvDSFrqF61AlcEqZKIG8VU a3HDUGHAu7M= =8Rg/ -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Wed Feb 20 12:20: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 2EE0021F88CC for ; Wed, 20 Feb 2013 12:20: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 WBMokpsnMtWe for ; Wed, 20 Feb 2013 12:20:21 -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 E955721F874F for ; Wed, 20 Feb 2013 12:20:20 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id CD4C520168 for ; Wed, 20 Feb 2013 15:27:07 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 5E852102B4; Wed, 20 Feb 2013 15:19:13 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4B5E61FFE6 for ; Wed, 20 Feb 2013 15:19:13 -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] Publication request for draft-ietf-roll-terminology-11.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2013 20:20:22 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Q> (1) What type of RFC is being requested (BCP, Proposed Standard, Q> Internet Standard, Informational, Experimental, or Historic)? Why is Q> this the proper type of RFC? Is this type of RFC indicated in the Q> title page header? Informational. Q> (2) The IESG approval announcement includes a Document Announcement Q> Write-Up. Please provide such a Document Announcement Write-Up. Rece= nt Q> examples can be found in the "Action" announcements for approved Q> documents. The approval announcement contains the following sections: Q> Technical Summary: Low power And Lossy Networks (LLN) are used in a wide scope of application areas, 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 documents defines a set of common terminology. Q> Working Group Summary: No concerns, the document had good support.=20=20 =20 Q> Document Quality: There was good support in the working group towards getting the definitions precise enough to be useful, but not overly specific. Q> Who is the Document Shepherd? Who is the Responsible Area Director? Document Shepherd: Michael Richardson Responsible AD: Adrian Farrel Q> (3) Briefly describe the review of this document that was performed = by Q> the Document Shepherd. If this version of the document is not ready Q> for publication, please explain why the document is being forwarded = to Q> the IESG. A WGLC for the document was issued and a number of definitions were adjuste= d. This document should have been published at the same time as RFC6550 but fe= ll by the wayside. Q> (4) Does the document Shepherd have any concerns about the depth or Q> breadth of the reviews that have been performed? None. Q> (5) Do portions of the document need review from a particular or from Q> broader perspective, e.g., security, operational complexity, AAA, DN= S, Q> DHCP, XML, or internationalization? If so, describe the review that Q> took place. None. Q> (6) Describe any specific concerns or issues that the Document Q> Shepherd has with this document that the Responsible Area Director Q> and/or the IESG should be aware of? For example, perhaps he or she is Q> uncomfortable with certain parts of the document, or has concerns Q> whether there really is a need for it. In any event, if the WG has Q> discussed those issues and has indicated that it still wishes to Q> advance the document, detail those concerns here. None. Q> (7) Has each author confirmed that any and all appropriate IPR Q> disclosures required for full conformance with the provisions of BCP Q> 78 and BCP 79 have already been filed. If not, explain why? Yes. Q> (8) Has an IPR disclosure been filed that references this document? = If Q> so, summarize any WG discussion and conclusion regarding the IPR Q> disclosures. Yes. Q> (9) How solid is the WG consensus behind this document? Does it Q> represent the strong concurrence of a few individuals, with others Q> being silent, or does the WG as a whole understand and agree with it? The document was forgotten and revived, and so recent discussion does not reflect historical involvement. When questions were asked, the WG responded favourable, and was able to quickly come to consensus on the changes. Q> (10) Has anyone threatened an appeal or otherwise indicated extreme Q> discontent? If so, please summarise the areas of conflict in separate Q> email messages to the Responsible Area Director. (It should be in a Q> separate email because this questionnaire is publicly available.) no. Q> (11) Identify any ID nits the Document Shepherd has found in this Q> document. (See http://www.ietf.org/tools/idnits/ and the Q> Internet-Drafts Checklist). Boilerplate checks are not enough; this Q> check needs to be thorough. none. Q> (12) Describe how the document meets any required formal review Q> criteria, such as the MIB Doctor, media type, and URI type reviews. none Q> (13) Have all references within this document been identified as Q> either normative or informative? yes. Q> (14) Are there normative references to documents that are not ready Q> for advancement or are otherwise in an unclear state? If such Q> normative references exist, what is the plan for their completion? none Q> (15) Are there downward normative references references (see RFC Q> 3967)? If so, list these downward references to support the Area Q> Director in the Last Call procedure. none Q> (16) Will publication of this document change the status of any Q> existing RFCs? Are those RFCs listed on the title page header, listed Q> in the abstract, and discussed in the introduction? If the RFCs are Q> not listed in the Abstract and Introduction, explain why, and point = to Q> the part of the document where the relationship of this document to Q> the other RFCs is discussed. If this information is not in the Q> document, explain why the WG considers it unnecessary. no. Q> (17) Describe the Document Shepherd's review of the IANA Q> considerations section, especially with regard to its consistency wi= th Q> the body of the document. Confirm that all protocol extensions that Q> the document makes are associated with the appropriate reservations = in Q> IANA registries. Confirm that any referenced IANA registries have be= en Q> clearly identified. Confirm that newly created IANA registries inclu= de Q> a detailed specification of the initial contents for the registry, Q> that allocations procedures for future registrations are defined, and Q> a reasonable name for the new registry has been suggested (see RFC Q> 5226). No IANA considerations. Q> (18) List any new IANA registries that require Expert Review for Q> future allocations. Provide any public guidance that the IESG would Q> find useful in selecting the IANA Experts for these new registries. None. Q> (19) Describe reviews and automated checks performed by the Document Q> Shepherd to validate sections of the document written in a formal Q> language, such as Q> XML code, BNF rules, MIB definitions, etc. none. =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) iQCVAwUAUSUvwIqHRg3pndX9AQIYPAQAw2RiphfQeT2OBUsR0v9oVx2lcd72UI7x 2xPSix7at+4cRnA7IK3RHBgcsrFJSq540GRsvSRamaQcUPu6UM1ydnYwtoJDcAFH ZsfHhNCedJVRgOayT8ANQbVvxzuc4sKXAfhE7FcDtXfJCgGzWYw93GuCD3QDBU1Q TBuEMcKx0io= =TThp -----END PGP SIGNATURE----- --=-=-=-- From abdussalambaryun@gmail.com Wed Feb 20 16:21: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 3AC2F21E8056 for ; Wed, 20 Feb 2013 16:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.526 X-Spam-Level: X-Spam-Status: No, score=-3.526 tagged_above=-999 required=5 tests=[AWL=0.073, 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 WJDdMvw1CJA9 for ; Wed, 20 Feb 2013 16:21:21 -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 9166B21E804D for ; Wed, 20 Feb 2013 16:21:21 -0800 (PST) Received: by mail-pb0-f47.google.com with SMTP id rp2so3161345pbb.6 for ; Wed, 20 Feb 2013 16:21: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=RycVeuZJAfxxf03iNR4N+aEgeznQp5IJ1R0qcuTslis=; b=PTmfuuj3d1KkePBqOMX2idk6+PKIgeKMTptqq/FaRERVVnxWiph4sggxSa7P//rhO4 Dh9oqa4FzbpnYJ6PCpISUCNszvlcnvm8woXxojb159Qgn2MPsDQ86HGgDOV0fTVr0Bf1 8udBuadRNFkK59nHwDqv4B/foqRSAZRLjheUCCICgPraoNruKjesWl5qMUuJOsKyHYSx g0KzMIRBh97nVUa+KaDdZUSgostnm7f6mzr/yQg5zPtJFDjCEbrtZJZDjohMKsEfNEZ4 aUSIpKumg9+ktuo/nallli0as0u3wbZX6Kkt93AxicxF8snPMwngipDiG5nO8EjkDWDN xywA== MIME-Version: 1.0 X-Received: by 10.66.220.227 with SMTP id pz3mr5282395pac.190.1361406079103; Wed, 20 Feb 2013 16:21:19 -0800 (PST) Received: by 10.68.33.132 with HTTP; Wed, 20 Feb 2013 16:21:18 -0800 (PST) In-Reply-To: <16172.1361386696@sandelman.ca> References: <16172.1361386696@sandelman.ca> Date: Thu, 21 Feb 2013 01:21:18 +0100 Message-ID: From: Abdussalam Baryun To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 00:21:22 -0000 Hi Michael, I wanted to have discussion before this call. I still waiting the reply from authors for the discussion related, my last message was as below; http://www.ietf.org/mail-archive/web/roll/current/msg07740.html AB On 2/20/13, Michael Richardson wrote: > > This is to start a 1 week WG call on adopting > > Applicability Statement: The use of RPL-P2P in Home and Building Control > draft-brandt-roll-rpl-applicability-home-building-03 > > as a WG document. > > Please, if you have objection to this document as a starting document > towards use of RPL in Home and Building LLN networks, please speak by > 2013-02-28. > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > From abdussalambaryun@gmail.com Wed Feb 20 16:43: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 9F44C21F8C48 for ; Wed, 20 Feb 2013 16:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.528 X-Spam-Level: X-Spam-Status: No, score=-3.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 n+O293l7-8DN for ; Wed, 20 Feb 2013 16:43:24 -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 1BEE421F8BEA for ; Wed, 20 Feb 2013 16:43:24 -0800 (PST) Received: by mail-da0-f46.google.com with SMTP id p5so3813455dak.33 for ; Wed, 20 Feb 2013 16:43: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:content-type; bh=U8SOcBiSUePF/Bqi0Qf4sDNAVLauq45FCZphSkM1it8=; b=VShJZ5zbOFk4kb6ydTpe8R1UnF+nLJSHfvs6JhPojFdff0xTCXp6xIJq2IsVsKhFrz OSfECB/ZI0zTaKryi2iZUNvL2ZH0luE6WN0GX2aDlkLQmO9dLT+hnQ2EhPwQIkkpI2I6 CbVp7FovWNTTwy9apfR6OksDM5fcPGy1A/WS/Yr95FbNS51FPk78H6+zrWr4HQri5D1U bnAW+CaVoWGk2G+rOrVQLxkDPZsJaJrXYW6k5ci+hGP6rdEi2VHY9yRkjo7u94sXGgFS eEjIbJOwiJqMPC6o3RLAUD8Bf6gp9CXWEiOnTcagRdkdDJ2BNqSBybehnMBCQcy39/Q3 41OQ== MIME-Version: 1.0 X-Received: by 10.68.153.97 with SMTP id vf1mr52177061pbb.93.1361407403801; Wed, 20 Feb 2013 16:43:23 -0800 (PST) Received: by 10.68.33.132 with HTTP; Wed, 20 Feb 2013 16:43:23 -0800 (PST) In-Reply-To: <17078.1361386986@sandelman.ca> References: <17078.1361386986@sandelman.ca> Date: Thu, 21 Feb 2013 01:43:23 +0100 Message-ID: From: Abdussalam Baryun To: roll@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [Roll] WG call to adopt draft-phinney-roll-rpl-industrial-applicability-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2013 00:43:24 -0000 +1 AB On 2/20/13, Michael Richardson wrote: > > This is to start a 1 week WG call on adopting > > RPL applicability in industrial networks > draft-phinney-roll-rpl-industrial-applicability-01 > > Abstract > > The wide deployment of wireless devices, with their low installed > cost (compared to wired devices), will significantly improve the > productivity and safety of industrial plants. It will simultaneously > increase the efficiency and safety of the plant's workers, by > extending and making more timely the information set available about > plant operations. The new Routing Protocol for Low Power and Lossy > Networks (RPL) defines a Distance Vector protocol that is designed > for such networks. The aim of this document is to analyze the > applicability of that routing protocol in industrial LLNs formed of > > as a WG document. > > This is part of satisfying the ROLL Charter. > > Please, if you have objection to this document as a starting document > towards use of RPL in Industrial Control networks please speak by > 2013-02-28. > > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > From internet-drafts@ietf.org Wed Feb 20 20:58: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 9699221E8090; Wed, 20 Feb 2013 20:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.542 X-Spam-Level: X-Spam-Status: No, score=-102.542 tagged_above=-999 required=5 tests=[AWL=0.057, 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 CL0lBjjbfRB5; Wed, 20 Feb 2013 20:58:47 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7AEE21E809B; Wed, 20 Feb 2013 20:58:46 -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.40 Message-ID: <20130221045846.27013.60320.idtracker@ietfa.amsl.com> Date: Wed, 20 Feb 2013 20:58:46 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-richardson-roll-applicability-template-02.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, 21 Feb 2013 04:58:47 -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-02.txt Pages : 15 Date : 2013-02-20 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-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-richardson-roll-applicability-temp= late-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From Anders_Brandt@sigmadesigns.com Wed Feb 20 23:49: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 930EF21F8E14 for ; Wed, 20 Feb 2013 23:49:43 -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 Fox5z9RbMzcn for ; Wed, 20 Feb 2013 23:49:43 -0800 (PST) Received: from maildk.sigmadesigns.com (maildk.sigmadesigns.com [195.215.56.173]) by ietfa.amsl.com (Postfix) with ESMTP id A5E5021F8DCD for ; Wed, 20 Feb 2013 23:49:42 -0800 (PST) From: Anders Brandt To: Abdussalam Baryun , Michael Richardson Thread-Topic: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-03 Thread-Index: AQHOD5xrjuTD6BKgS0e3SrRVcsyRrZiDYr8AgACKaLA= Date: Thu, 21 Feb 2013 07:49:35 +0000 Message-ID: <03F31C213F2C6941BFDDBB4336E9E6CD0AD4045B@cph-ex1> References: <16172.1361386696@sandelman.ca> In-Reply-To: Accept-Language: en-US, da-DK Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.10.56] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 07:49:43 -0000 Abdussalam Baryun wrote: > I still waiting the reply from authors for the discussion related, my las= t message was as below; > >http://www.ietf.org/mail-archive/web/roll/current/msg07740.html Responding inline: > So I understand from your reply that you think RPL MAY NOT be > applicabale for home and building application, To the authors of the draft, P2P-RPL seems to be the best choice for home a= pplications. RPL may be applicable as well. > why it is best choice? this was not mentioned clearly in draft, The purpose of an applicability document is to describe the applicability o= f an invention, i.e. how one should configure host and routing protocol parameters to make the i= nvention work in a given setting; in this case, P2P-RPL in home and building environments= . A similar document may be created for RPL in home and building environments= . One day, when there also exists an RPL home & building applicability docume= nt, one _could_ draft an evaluation document; comparing the applicability of the two protoc= ols. > or describe P2P in this draft and leave others as P2MP and RPL in > other draft if you like Exactly. - Anders -----Original Message----- From: roll-bounces@ietf.org [mailto:roll-bounces@ietf.org] On Behalf Of Abd= ussalam Baryun Sent: 21. februar 2013 01:21 To: Michael Richardson Cc: roll@ietf.org Subject: Re: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-ho= me-building-03 Hi Michael, I wanted to have discussion before this call. I still waiting the reply fro= m authors for the discussion related, my last message was as below; http://www.ietf.org/mail-archive/web/roll/current/msg07740.html AB On 2/20/13, Michael Richardson wrote: > > This is to start a 1 week WG call on adopting > > Applicability Statement: The use of RPL-P2P in Home and Building Contro= l > draft-brandt-roll-rpl-applicability-home-building-03 > > as a WG document. > > Please, if you have objection to this document as a starting document=20 > towards use of RPL in Home and Building LLN networks, please speak by=20 > 2013-02-28. > > -- > 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 mcr@sandelman.ca Thu Feb 21 07:41: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 1A69121F8EBC for ; Thu, 21 Feb 2013 07:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 UWW1CS-k4f5K for ; Thu, 21 Feb 2013 07:41:30 -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 96CEF21F8EB7 for ; Thu, 21 Feb 2013 07:41:30 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 411912016D for ; Thu, 21 Feb 2013 10:48:19 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 84C6C6387D; Thu, 21 Feb 2013 10:40:21 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 740AA63765 for ; Thu, 21 Feb 2013 10:40:21 -0500 (EST) From: Michael Richardson To: "roll@ietf.org" In-Reply-To: <03F31C213F2C6941BFDDBB4336E9E6CD0AD4045B@cph-ex1> References: <16172.1361386696@sandelman.ca> <03F31C213F2C6941BFDDBB4336E9E6CD0AD4045B@cph-ex1> 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] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 15:41:32 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Anders" =3D=3D Anders Brandt writes: Anders> To the authors of the draft, P2P-RPL seems to be the best choic= e for home applications. Anders> RPL may be applicable as well. >> why it is best choice? this was not mentioned clearly in draft, Anders> The purpose of an applicability document is to describe the app= licability of an invention, i.e. Anders> how one should configure host and routing protocol parameters t= o make the invention work Anders> in a given setting; in this case, P2P-RPL in home and building = environments. Anders> A similar document may be created for RPL in home and building = environments. Anders> One day, when there also exists an RPL home & building applicab= ility document, one _could_ Anders> draft an evaluation document; comparing the applicability of Anders> the two protocols. Based upon recent clarifications to P2P-RPL, it seems that it is not possible to use P2P-RPL without prior using rooted RPL, so your document must explain how RPL will be used in the home, in order that P2P may then be used. =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) iQCVAwUAUSY/5YqHRg3pndX9AQJCMQP+MIT3itmDGSJAZRddjtnur8m26VoZKEeB gkz9D8kKwCK9umfsWAUboSYEpa3hZIoRVNSvpzzeHn0Aw3i1VS6TlJieRAvN56cN FWR8Bfo09PEqOwKZ4Pn0fHvXvKx6/2Y7d/QSK2bHw+zLnupL6Dxzs2zn/IjH88L8 P8/X+hloplo= =KxZ9 -----END PGP SIGNATURE----- --=-=-=-- From rdroms.ietf@gmail.com Thu Feb 21 07:50: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 A6F4B21F8E97 for ; Thu, 21 Feb 2013 07:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.546 X-Spam-Level: X-Spam-Status: No, score=-103.546 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 D+cihufLnpDK for ; Thu, 21 Feb 2013 07:50:19 -0800 (PST) Received: from mail-vb0-f46.google.com (mail-vb0-f46.google.com [209.85.212.46]) by ietfa.amsl.com (Postfix) with ESMTP id F045D21F88DB for ; Thu, 21 Feb 2013 07:50:18 -0800 (PST) Received: by mail-vb0-f46.google.com with SMTP id b13so5763169vby.5 for ; Thu, 21 Feb 2013 07:50:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=X5mbbJy5gWqWOS/pNpaWqrDwnLJN07/cP9polaYhzA0=; b=uN2zGzl+mL33oHN653XkLZuiWF50Omq3ADFVhQKuQ6p8AhOtbgPwzFbYvwkjII5k7h 5VQH5JC72gHLV5e4NZ3BHxc7HrtwzS8OvfdxabN/0JEkgs1/E+8Jq3aNZ24F8IRBQghD xGB98z5QZDbFgF2ohMsiEADlz88Ug5ZEWIw8/utOQSXl+e62DWGYOrkHGo2sU4mmgbNf huD0Vq4pNrjj56D6OrXOX+ycVCBUHzXaJmRfBJyntaNv5pcNjgE8Y/jKLts9WRELeah0 eIc72mbDDPyTkIWLZ5vaL0/N2pOZFoWJsxiEYF9wXWA6Y2pUqD1ty04fclmS9f5vna+4 P8vg== X-Received: by 10.220.222.8 with SMTP id ie8mr25207029vcb.27.1361461424398; Thu, 21 Feb 2013 07:43:44 -0800 (PST) Received: from ?IPv6:2001:420:2c51:1311:e123:1b78:f56b:cf9c? ([2001:420:2c51:1311:e123:1b78:f56b:cf9c]) by mx.google.com with ESMTPS id yu12sm97272392vec.6.2013.02.21.07.43.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 07:43:43 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ralph Droms In-Reply-To: <29348.1361461221@sandelman.ca> Date: Thu, 21 Feb 2013 10:43:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2696EF02-C90C-484C-854D-D860E5B92627@gmail.com> References: <16172.1361386696@sandelman.ca> <03F31C213F2C6941BFDDBB4336E9E6CD0AD4045B@cph-ex1> <29348.1361461221@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1499) Cc: roll@ietf.org Subject: Re: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 15:50:19 -0000 On Feb 21, 2013, at 10:40 AM 2/21/13, Michael Richardson = wrote: >=20 >>>>>> "Anders" =3D=3D Anders Brandt = writes: > Anders> To the authors of the draft, P2P-RPL seems to be the best = choice for home applications. > Anders> RPL may be applicable as well. >=20 >>> why it is best choice? this was not mentioned clearly in draft, >=20 > Anders> The purpose of an applicability document is to describe the = applicability of an invention, i.e. > Anders> how one should configure host and routing protocol = parameters to make the invention work > Anders> in a given setting; in this case, P2P-RPL in home and = building environments. > Anders> A similar document may be created for RPL in home and = building environments. >=20 > Anders> One day, when there also exists an RPL home & building = applicability document, one _could_ > Anders> draft an evaluation document; comparing the applicability = of > Anders> the two protocols. >=20 > Based upon recent clarifications to P2P-RPL, it seems that it is not > possible to use P2P-RPL without prior using rooted RPL, How so? - Ralph > so your document > must explain how RPL will be used in the home, in order that P2P may > then be used. >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh = networks [=20 > ] Michael Richardson, Sandelman Software Works | network = architect [=20 > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [=20 > =09 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From mcr@sandelman.ca Thu Feb 21 09:42:25 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 EA67121F8F56 for ; Thu, 21 Feb 2013 09:42:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 LSjge52YDpk5 for ; Thu, 21 Feb 2013 09:42:24 -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 A671F21F8F55 for ; Thu, 21 Feb 2013 09:42:24 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 4BBD82016D; Thu, 21 Feb 2013 12:49:14 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 1BE996387F; Thu, 21 Feb 2013 12:41:16 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 057FA6387D; Thu, 21 Feb 2013 12:41:15 -0500 (EST) From: Michael Richardson To: Ralph Droms In-Reply-To: <2696EF02-C90C-484C-854D-D860E5B92627@gmail.com> References: <16172.1361386696@sandelman.ca> <03F31C213F2C6941BFDDBB4336E9E6CD0AD4045B@cph-ex1> <29348.1361461221@sandelman.ca> <2696EF02-C90C-484C-854D-D860E5B92627@gmail.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] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 17:42:26 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ralph" =3D=3D Ralph Droms writes: Anders> One day, when there also exists an RPL home & building Anders> applicability document, one _could_ draft an evaluation Anders> document; comparing the applicability of the two protocols. >> Based upon recent clarifications to P2P-RPL, it seems that it is >> not possible to use P2P-RPL without prior using rooted RPL, Ralph> How so? 1) we said that LL addressees are not permitted in the P2P's DRO. 2) we said that P2P can not have a PIO, so the P2P process can not=20 number the nodes. Therefore, in order to use P2P RPL, there must first have been an RPL that provided stable addresses to all nodes. (I wrote "rooted", intending to mean grounded, but probably that's too much) =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) iQCVAwUAUSZcO4qHRg3pndX9AQJhdgQAlgjMzc6bVwFEek3nHFbijmEeHG5x2nVL lS8e/bcgSxkdgreRhwpPyWkYR9dyam0luEN4gyWZdSqTO8ujImiSMcDUAW0GQHYt emIujjnyav/nBFfZOcBrM6rnTXVQRS6Tu2hgaz8hsJ7oTbyFE/rEpt2LOY9pEQKy NiXMo4bwCMc= =OefR -----END PGP SIGNATURE----- --=-=-=-- From rdroms.ietf@gmail.com Thu Feb 21 09:45: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 5BA7821F8F56 for ; Thu, 21 Feb 2013 09:45:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.545 X-Spam-Level: X-Spam-Status: No, score=-103.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 B6MBM1Up84wN for ; Thu, 21 Feb 2013 09:45:55 -0800 (PST) Received: from mail-vb0-f42.google.com (mail-vb0-f42.google.com [209.85.212.42]) by ietfa.amsl.com (Postfix) with ESMTP id 715B321F8EBC for ; Thu, 21 Feb 2013 09:45:55 -0800 (PST) Received: by mail-vb0-f42.google.com with SMTP id ff1so2794772vbb.15 for ; Thu, 21 Feb 2013 09:45:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=/s9MGdXJ+vHV0XHEF52veMve0VNJZb1TKWZD+xI81L0=; b=p9xnPD8+ziXEnhk3oNEKRIBzAK0Ef13UdxfEJgW4YtSJrsIIgrT3bBrUNQ7aoKKSgW A5kPUupq8lEQKHebg54At5RkX79WD2hPX4rx389h8CgDalfkHQQBvjAKoTAyl6NzxqWX KXFFZrxd7WaDZ0BJ1Nz6ASW822IFWuiFdXFS+4GbE4R0WTS+zQTqi/NjAauD2JqGAT8E tKk8GPkySP4rYWnZppFLDn7GO+tz/d1KRnqFSC+87lAESXlOmG8RPhTK9eIB5t90ayOR ClUDlV1R8O1rGyTUpjwNQscwZAIzwHKxgLtkHnOCkb4wB3epg5XIPD+KvjiT+IWuch+R p6Hw== X-Received: by 10.52.24.98 with SMTP id t2mr28259711vdf.69.1361468754899; Thu, 21 Feb 2013 09:45:54 -0800 (PST) Received: from ?IPv6:2001:420:2c51:1311:e123:1b78:f56b:cf9c? ([2001:420:2c51:1311:e123:1b78:f56b:cf9c]) by mx.google.com with ESMTPS id l5sm6145345vdi.4.2013.02.21.09.45.52 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 09:45:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ralph Droms In-Reply-To: <19733.1361468475@sandelman.ca> Date: Thu, 21 Feb 2013 12:45:50 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <98EE8664-A9D9-4E6D-8A97-D3D2391A3650@gmail.com> References: <16172.1361386696@sandelman.ca> <03F31C213F2C6941BFDDBB4336E9E6CD0AD4045B@cph-ex1> <29348.1361461221@sandelman.ca> <2696EF02-C90C-484C-854D-D860E5B92627@gmail.com> <19733.1361468475@sandelman.ca> To: Michael Richardson X-Mailer: Apple Mail (2.1499) Cc: roll@ietf.org Subject: Re: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 17:45:56 -0000 On Feb 21, 2013, at 12:41 PM 2/21/13, Michael Richardson = wrote: >=20 >>>>>> "Ralph" =3D=3D Ralph Droms writes: > Anders> One day, when there also exists an RPL home & building > Anders> applicability document, one _could_ draft an evaluation > Anders> document; comparing the applicability of the two protocols. >=20 >>> Based upon recent clarifications to P2P-RPL, it seems that it is >>> not possible to use P2P-RPL without prior using rooted RPL, >=20 > Ralph> How so? >=20 > 1) we said that LL addressees are not permitted in the P2P's DRO. > 2) we said that P2P can not have a PIO, so the P2P process can not=20 > number the nodes. >=20 > Therefore, in order to use P2P RPL, there must first have been an RPL > that provided stable addresses to all nodes. (I wrote "rooted", > intending to mean grounded, but probably that's too much) Why is RPL needed for address assignment? - Ralph >=20 > --=20 > ] Never tell me the odds! | ipv6 mesh = networks [=20 > ] Michael Richardson, Sandelman Software Works | network = architect [=20 > ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [=20 > =09 >=20 From rdroms.ietf@gmail.com Thu Feb 21 10:12: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 E073121F8F2B for ; Thu, 21 Feb 2013 10:12:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.547 X-Spam-Level: X-Spam-Status: No, score=-103.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 qq29+Xxb+Aze for ; Thu, 21 Feb 2013 10:12:23 -0800 (PST) Received: from mail-vc0-f179.google.com (mail-vc0-f179.google.com [209.85.220.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2080021F8F08 for ; Thu, 21 Feb 2013 10:12:23 -0800 (PST) Received: by mail-vc0-f179.google.com with SMTP id gb23so5881953vcb.38 for ; Thu, 21 Feb 2013 10:12:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:content-transfer-encoding:message-id:references:to:x-mailer; bh=J7Kdiq4pWH0MNxJ44enwZ1Fm9yHdeV3YqUlWPiGwKg0=; b=awf/RZs7uaEmDgduNrQV5dv/58AfHSiZXaeMzLpqsaE+lS5/ZboqvYlurub4xI8k+6 q40+ppqUCEKfr222eAZR7T6x/qeu16zslkyGNVg94GPAM7zCpDULxS67lxzXQOqIrcCt vM6by3JLgSyN/EpVgaODVrTbmL8wC6sUrzjLe/X6wH5pgLHJv0KCFWwNAANG95dhAKZD UElOrArqqcisMvhVCRpwk8wAXT+QjK0jmCEOlyeLxHJ67ZguK0EYDUIAM3Xkw0aFi+Vg AECri39qEMfR72qCRwvo6ZWccAg6q8trdmdOzz8LWQJWeSkvv5XT49HXGZ3QkrUcbtb0 HIXw== X-Received: by 10.52.19.65 with SMTP id c1mr28679265vde.36.1361470337501; Thu, 21 Feb 2013 10:12:17 -0800 (PST) Received: from ?IPv6:2001:420:2c51:1311:e123:1b78:f56b:cf9c? ([2001:420:2c51:1311:e123:1b78:f56b:cf9c]) by mx.google.com with ESMTPS id kn18sm114131169veb.5.2013.02.21.10.12.14 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Feb 2013 10:12:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ralph Droms In-Reply-To: <98EE8664-A9D9-4E6D-8A97-D3D2391A3650@gmail.com> Date: Thu, 21 Feb 2013 13:12:13 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <16172.1361386696@sandelman.ca> <03F31C213F2C6941BFDDBB4336E9E6CD0AD4045B@cph-ex1> <29348.1361461221@sandelman.ca> <2696EF02-C90C-484C-854D-D860E5B92627@gmail.com> <19733.1361468475@sandelman.ca> <98EE8664-A9D9-4E6D-8A97-D3D2391A3650@gmail.com> To: Michael Richardson X-Mailer: Apple Mail (2.1499) Cc: roll@ietf.org Subject: Re: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 18:12:24 -0000 On Feb 21, 2013, at 12:45 PM 2/21/13, Ralph Droms = wrote: >=20 > On Feb 21, 2013, at 12:41 PM 2/21/13, Michael Richardson = wrote: >=20 >>=20 >>>>>>> "Ralph" =3D=3D Ralph Droms writes: >> Anders> One day, when there also exists an RPL home & building >> Anders> applicability document, one _could_ draft an evaluation >> Anders> document; comparing the applicability of the two protocols. >>=20 >>>> Based upon recent clarifications to P2P-RPL, it seems that it is >>>> not possible to use P2P-RPL without prior using rooted RPL, >>=20 >> Ralph> How so? >>=20 >> 1) we said that LL addressees are not permitted in the P2P's DRO. >> 2) we said that P2P can not have a PIO, so the P2P process can not=20 >> number the nodes. >>=20 >> Therefore, in order to use P2P RPL, there must first have been an RPL >> that provided stable addresses to all nodes. (I wrote "rooted", >> intending to mean grounded, but probably that's too much) >=20 > Why is RPL needed for address assignment? E.g., RFC 6775 w/ DHCPv6 would provide address assignment without RPL, = right? - Ralph >=20 > - Ralph >=20 >>=20 >> --=20 >> ] Never tell me the odds! | ipv6 mesh = networks [=20 >> ] Michael Richardson, Sandelman Software Works | network = architect [=20 >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on = rails [=20 >> =09 >>=20 >=20 From mcr@sandelman.ca Thu Feb 21 10:17: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 D7FA421F8EF4 for ; Thu, 21 Feb 2013 10:17:29 -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 J79Xe+J6-hrf for ; Thu, 21 Feb 2013 10:17:29 -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 C526421F8E87 for ; Thu, 21 Feb 2013 10:17:28 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E059E2016D; Thu, 21 Feb 2013 13:24:12 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id C4A9D6387F; Thu, 21 Feb 2013 13:16:14 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id B5CA16387D; Thu, 21 Feb 2013 13:16:14 -0500 (EST) From: Michael Richardson To: Ralph Droms In-Reply-To: <98EE8664-A9D9-4E6D-8A97-D3D2391A3650@gmail.com> References: <16172.1361386696@sandelman.ca> <03F31C213F2C6941BFDDBB4336E9E6CD0AD4045B@cph-ex1> <29348.1361461221@sandelman.ca> <2696EF02-C90C-484C-854D-D860E5B92627@gmail.com> <19733.1361468475@sandelman.ca> <98EE8664-A9D9-4E6D-8A97-D3D2391A3650@gmail.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] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 18:17:30 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Ralph" =3D=3D Ralph Droms writes: >> Therefore, in order to use P2P RPL, there must first have been an >> RPL that provided stable addresses to all nodes. (I wrote >> "rooted", intending to mean grounded, but probably that's too >> much) Ralph> Why is RPL needed for address assignment? On a number of media, I guess that it isn't. On the media where classic RA/ND or DHCPv6 works, you don't need it. On those media, you might not need P2P RPL either. On some 6LowPAN mesh under systems, we have an RA/ND that does work. As far as I can tell, none of these are the situation contemplated by rpl-applicability-home-building.=20=20=20 (And this is why I want our applicability statements to be very very narrow in their scope, because these are questions that need to be answered if we are going to have interoperability between muyltiple vendors without resorting to yet another level of vendor forums) =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) iQCVAwUAUSZkboqHRg3pndX9AQLRmQP/XahsizoBIUoOw15NS6LAYFQ2sQB1fSTD Ot2pOBDPmlYVt74kTsgX1uFURMx0yTVCSw6k2wANQelcxv7whiFHcnrlyU73Pk2V ISkklcvdJucm6LxsvgZsQvEQPOeoh+pqjAwhBjPF/YB8Zp2iqtVhg45Yvo+V7sfS BYf61eJ0zZs= =uioT -----END PGP SIGNATURE----- --=-=-=-- From d.sturek@att.net Thu Feb 21 10:25: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 555F021F8F48 for ; Thu, 21 Feb 2013 10:25: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 SSumA9g+qiqa for ; Thu, 21 Feb 2013 10:25:40 -0800 (PST) Received: from nm30.access.bullet.mail.mud.yahoo.com (nm30.access.bullet.mail.mud.yahoo.com [66.94.237.95]) by ietfa.amsl.com (Postfix) with ESMTP id 6AD8421F8F42 for ; Thu, 21 Feb 2013 10:25:40 -0800 (PST) Received: from [66.94.237.195] by nm30.access.bullet.mail.mud.yahoo.com with NNFMP; 21 Feb 2013 18:25:39 -0000 Received: from [68.142.198.204] by tm6.access.bullet.mail.mud.yahoo.com with NNFMP; 21 Feb 2013 18:25:39 -0000 Received: from [127.0.0.1] by smtp105.sbc.mail.mud.yahoo.com with NNFMP; 21 Feb 2013 18:25:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1361471139; bh=vE9qZqTp1KuGbpwoC0Ity1t4iYHPPEkiG9H1GpcpqiM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=Bs+hc1b0lbUp7FOPKpN4SqeCAIIbzvO7Tmzpa6fwquyNwrNN+Vg93YWE0VjT6cCokSyV2hzUTgJKNENjGDbRUs8WoLa18aqT0Qc91F5RAhoeQ988PZR5RP1jPzriR64RAtKME4YXRRTpN7Jt5ttmRr9biefmJG5yl6XIpmhfmPM= X-Yahoo-Newman-Id: 614239.88964.bm@smtp105.sbc.mail.mud.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: oiaQDPkVM1l1r1d66g2QYXGRnf.VJivjElErZ5HJQEK1fYV 916601016Z031QIRxjR5YATXjvaolLMkAoS.6INDl3m4IEQpFxoN.PvoqwCW wc4NyGpzFInAXJ7cXfX9nzDVOCMt4e04L47WmYJDLEsBGwqMwUNOk5POyXHz pZkK3KPXaNbf5MUqD6SNrRKEk2WAFroXElaZIXnnqdMr8aFivbzWU0h6Gflm 6aqyHVQ18Drelin4yBi9pLepRc2NoUrAZBN4aFeC26tKwKXOrWk3dsyUhc0_ XIZFFObYQ7pTQuGeyo8JKtrrp7XQNB7KkOi0sbPcX8_CUkZIrd5xum7ugNjo sRE5sTHZWufcmpVr6bW2OREvGxrMjDFkw8TELlEAVcnrY5WtTc6BhNe.FPoT Tcfsy.CrACWpjTBynj3gk9EzN1mElRUchs.1IYqdku1ininpUg3Fxhywvgrx N1r_DOKzkXWtYSxXZSG10PZohemqaXXspTg_r X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.199] (d.sturek@67.124.203.71 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 21 Feb 2013 10:25:39 -0800 PST User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Thu, 21 Feb 2013 10:25:35 -0800 From: Don Sturek To: Michael Richardson , Ralph Droms Message-ID: Thread-Topic: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-03 In-Reply-To: <26596.1361470574@sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 18:25:41 -0000 Hi Michael, Having implemented and certified 6 vendor solutions using ROLL RPL in ZigBee IP, I doubt very seriously that this is true: "......because these are questions that need to be answered if we are going to have interoperability between muyltiple vendors without resorting to yet another level of vendor forums)" It would be best to keep the scope of the applicability statement to just RPL P2P, not add assumptions on the use of outside RFCs/drafts and let commercial groups complete certification by choosing configuration parameters that address their needs. I would doubt we are going to get to a place where an ad hoc group of vendors are going to pick up 6LoWPAN, 6LoWPAN-ND, ROLL RPL, ROLL RPL P2P, ROLL Mr. HOF, etc. .... , implement all these and find their solutions are all interoperable. Just looking at all the configuration options in these various drafts, it is unlikely for interoperability to just happen (ignoring for a minute the security bootstrapping topic which has its own set of complications) Don On 2/21/13 10:16 AM, "Michael Richardson" wrote: > >>>>>> "Ralph" == Ralph Droms writes: > >> Therefore, in order to use P2P RPL, there must first have been an > >> RPL that provided stable addresses to all nodes. (I wrote > >> "rooted", intending to mean grounded, but probably that's too > >> much) > > Ralph> Why is RPL needed for address assignment? > >On a number of media, I guess that it isn't. >On the media where classic RA/ND or DHCPv6 works, you don't need it. >On those media, you might not need P2P RPL either. > >On some 6LowPAN mesh under systems, we have an RA/ND that does work. > >As far as I can tell, none of these are the situation contemplated by >rpl-applicability-home-building. > >(And this is why I want our applicability statements to be very very >narrow in their scope, because these are questions that need to be >answered if we are going to have interoperability between muyltiple >vendors without resorting to yet another level of vendor forums) > >-- >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 Feb 21 11:32: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 CD4C221F8984 for ; Thu, 21 Feb 2013 11:32:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.543 X-Spam-Level: X-Spam-Status: No, score=-3.543 tagged_above=-999 required=5 tests=[AWL=0.056, 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 8mc1yvcq1kaA for ; Thu, 21 Feb 2013 11:32:07 -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 61A3121F88EF for ; Thu, 21 Feb 2013 11:32:07 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id fa11so2156pad.9 for ; Thu, 21 Feb 2013 11:32:07 -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=lhq2SqMNhgj0++GGAq8yO7aq7+a2Dpl8Mfp3n4ACmOc=; b=nqkjEi+J1nBSXfiGtFfBO0fv4Qd5uLxY9bhjg+NQAsu38KHj/kv3te8PuYgEjXKFfI gsSYNTkDnmG71dRPoRUWn9SxorQ84BakV80TUk0vj7/e5YoOokNGAfZE3K8pQ/6eZeb4 cSPC7sEin/B80cIYm23j2kjk0XJ3ND/rFv+V0/dG4aDaacbCKwBoD4rTopW4s6lx+Qc8 LV3w8ekUmhqlXXEasdW1+LnLKngyPPD6rSotwQGSzJvNPF0tX42sk2yXEpLrh3SJ577x 0rW0b/3PX2sifPMxz6iNG3aN1t1bldIqY/FarFLpMmOTZ927eS20tfX2GymOhfGCnpNl RgaA== MIME-Version: 1.0 X-Received: by 10.68.143.40 with SMTP id sb8mr10015450pbb.202.1361475126991; Thu, 21 Feb 2013 11:32:06 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 21 Feb 2013 11:32:06 -0800 (PST) In-Reply-To: <2696EF02-C90C-484C-854D-D860E5B92627@gmail.com> References: <16172.1361386696@sandelman.ca> <03F31C213F2C6941BFDDBB4336E9E6CD0AD4045B@cph-ex1> <29348.1361461221@sandelman.ca> <2696EF02-C90C-484C-854D-D860E5B92627@gmail.com> Date: Thu, 21 Feb 2013 20:32:06 +0100 Message-ID: From: Abdussalam Baryun To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 19:32:07 -0000 On 2/21/13, Ralph Droms wrote: > > On Feb 21, 2013, at 10:40 AM 2/21/13, Michael Richardson > wrote: > > How so? > The P2P-RPL is route discovery, the I-D already mentions that it is an extension of RPL, so the P2P-RPL core routing function is similar to RPL, I agree that the both protocols are not very similar in performance, but in this applicability draft I think both can be used in similar ways, or users may use them in similar ways. The draft can advise where is the need for different way of use. AB From abdussalambaryun@gmail.com Thu Feb 21 11:37: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 1B8B521F8F23 for ; Thu, 21 Feb 2013 11:37:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.544 X-Spam-Level: X-Spam-Status: No, score=-3.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 miRSyNrE24fu for ; Thu, 21 Feb 2013 11:37:57 -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 9532E21F8F13 for ; Thu, 21 Feb 2013 11:37:57 -0800 (PST) Received: by mail-da0-f46.google.com with SMTP id p5so4243200dak.19 for ; Thu, 21 Feb 2013 11:37:57 -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=J0Wo6cBOjmjeI8FoSKEOS95ZN8DxKmnaFnxM0s/igcU=; b=DG+TznEwhUO2BwrVJwpd2EIbh6x2Dx/3pbKprj76oggXY2+Y0IUgIMjgHw2c5n11Ne 7y+LJy1rSrh2e6Lr/HRK03mzHDIWprSpinL96BKmP1OlAb24eE5/X0hpofbLTeZVnfli W7TU+q7EMO20zyllvorunHc9cZUXYGcLVz1pQ5rPJgkLcZiUMf6odh8TlM5tn602cinf TJAGtN5DA4bPRXcka7roECUU6Jfr3FwEGIni4oWUcTjspoRJp7asycFbdXiKIsdN/w4t GZ674iYng7WLfnzWtwRZXC+8GT+y1GWIrM3nLBQpS6KVZ7UQQpHafWl2DGW6AUG+xgwY mD8g== MIME-Version: 1.0 X-Received: by 10.68.28.194 with SMTP id d2mr9767396pbh.215.1361475477389; Thu, 21 Feb 2013 11:37:57 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 21 Feb 2013 11:37:57 -0800 (PST) In-Reply-To: References: <26596.1361470574@sandelman.ca> Date: Thu, 21 Feb 2013 20:37:57 +0100 Message-ID: From: Abdussalam Baryun To: Don Sturek Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 19:37:58 -0000 Hi Don, IMHO, I don't think the draft is about interoperability, nor commercial issues. The draft is an applicability draft, it helps users to use the protocol in such environment or applications, AB On 2/21/13, Don Sturek wrote: > Hi Michael, > > Having implemented and certified 6 vendor solutions using ROLL RPL in > ZigBee IP, I doubt very seriously that this is true: > > "......because these are questions that need to be > answered if we are going to have interoperability between muyltiple > vendors without resorting to yet another level of vendor forums)" > > It would be best to keep the scope of the applicability statement to just > RPL P2P, not add assumptions on the use of outside RFCs/drafts and let > commercial groups complete certification by choosing configuration > parameters that address their needs. > > I would doubt we are going to get to a place where an ad hoc group of > vendors are going to pick up 6LoWPAN, 6LoWPAN-ND, ROLL RPL, ROLL RPL P2P, > ROLL Mr. HOF, etc. .... , implement all these and find their solutions > are all interoperable. Just looking at all the configuration options in > these various drafts, it is unlikely for interoperability to just happen > (ignoring for a minute the security bootstrapping topic which has its own > set of complications) > > Don From mcr@sandelman.ca Thu Feb 21 12:13: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 3028C21F8F5A for ; Thu, 21 Feb 2013 12:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 nkZzuYT8wGcq for ; Thu, 21 Feb 2013 12:13:55 -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 BC14421F8F1D for ; Thu, 21 Feb 2013 12:13:54 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id B97C72016D; Thu, 21 Feb 2013 15:20:41 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 91AF56387F; Thu, 21 Feb 2013 15:12:42 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6E4366387D; Thu, 21 Feb 2013 15:12:42 -0500 (EST) From: Michael Richardson To: Don Sturek In-Reply-To: References: X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) 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] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 20:13:56 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Don" =3D=3D Don Sturek writes: Don> Having implemented and certified 6 vendor solutions using ROLL Don> RPL in ZigBee IP, I doubt very seriously that this is true: Don> "......because these are questions that need to be answered if Don> we are going to have interoperability between muyltiple vendors Don> without resorting to yet another level of vendor forums)" Don> It would be best to keep the scope of the applicability Don> statement to just RPL P2P, not add assumptions on the use of Don> outside RFCs/drafts and let commercial groups complete Don> certification by choosing configuration parameters that address Don> their needs. Don, are you offering to take the Home and Building Applicability statement to a vendor forum, and produce a document which a *building architect* (not a member of said vendor forum) can list on a NAFTA Article 10-compliant RFP, and which will tell an implementor (also not a member of said vendor forum) what pieces need to be implemented in order to interoperate?=20 Because, that's the situation for all other IETF (routing) specifications. =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) iQCVAwUAUSZ/uoqHRg3pndX9AQLvSAP/RdO9hEq8iFdIk9BtoyIzyx847U4SvtEC Khsl8sFNqXeD9FnDTLABQbZtzz1qkNhXq5JmmfiOOTFXDtnzEUlrBeX/x3M4ZT7y LCnKHZJX7Dr3BpgK5q2VeNiVHjZTvJoCxGU23jZZ0ChJJzbaZDKU82sn3vGRzj6L 2vyuDPS43E8= =KAJK -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Feb 21 12:44:50 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 0C3C021F8F41 for ; Thu, 21 Feb 2013 12:44:50 -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 iS-q2hnewEdK for ; Thu, 21 Feb 2013 12:44:49 -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 5199821F8F14 for ; Thu, 21 Feb 2013 12:44:49 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 0A9D82016D; Thu, 21 Feb 2013 15:51:39 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 7FFC86387F; Thu, 21 Feb 2013 15:43:40 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6EF266387D; Thu, 21 Feb 2013 15:43:40 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: References: <26596.1361470574@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] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 20:44:50 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Abdussalam" =3D=3D Abdussalam Baryun wr= ites: Abdussalam> IMHO, I don't think the draft is about interoperability, Abdussalam> nor commercial issues. The draft is an applicability Abdussalam> draft, it helps users to use the protocol in such Abdussalam> environment or applications, If there is anything in the document which is not essential for interoperability then it can be removed from the document. RFC6550 and friends (including the 6lowpan and 6man things) have given us palette of options. The purpose of this document is how to apply=20 those options to a specific situation. This document *MUST* explain what options *MUST* be present in a device in order to interoperate=20 in the situation. Given the real constraints in the devices involved, they can be manufactured with every available feature of the protocol, nor can we assume that we can turn them all on at the same time, and create as much state (=3D=3Dmemory) as we want. =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) iQCVAwUAUSaG/IqHRg3pndX9AQKUUwQAvomNCS5bcydH9kujnAS+uYeX88GXvnE5 da5eVkvFzo5tronnaFE3b9u0b1PYzEI0vuX9mYJ6Jk8kERGrZsc5TcuomYFqKFs+ E3q1C7PXGTbaMH5lohMhVo36XPoN5FaWqZGrCEj6C+HRjGxc4lyO2p7otNF38fIt ozO77oaFx1o= =zwJv -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Feb 21 13:00: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 5115121F8EE9 for ; Thu, 21 Feb 2013 13:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 rbs3ERM0Yd3m for ; Thu, 21 Feb 2013 13:00:29 -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 AC48321F8F54 for ; Thu, 21 Feb 2013 13:00:29 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 344032016D for ; Thu, 21 Feb 2013 16:07:20 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id A4E2F6387F; Thu, 21 Feb 2013 15:59:21 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 930F66387D for ; Thu, 21 Feb 2013 15:59:21 -0500 (EST) From: Michael Richardson to: roll@ietf.org In-Reply-To: <21952.1361479420@sandelman.ca> References: <26596.1361470574@sandelman.ca> <21952.1361479420@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] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 21:00:30 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Michael" =3D=3D Michael Richardson writes: Michael> *MUST* be present in a device in order to interoperate in Michael> the situation. Given the real constraints in the devices Michael> involved, they can be manufactured with every available Michael> feature of the protocol, nor can we assume that we can turn Michael> them all on at the same time, and create as much state Michael> (=3D=3Dmemory) as we want. Forgive me for missing a key "not" in that sentence. > Given the real constraints in the devices involved, they can **NOT** be > manufactured with every available feature of the protocol, nor can we > assume that we can turn ... =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) iQCVAwUAUSaKqYqHRg3pndX9AQIPygQAlG3AL9yqUKzozCqBEgzerm7t81vhf2qq 9PNvbIhkyewPSbr2BI8cH+KBB7ReeB4HJMCMX/Emuj9UEWsB4bnahyQeNiCGz5CN 1U9C/JYAC6A5UQJLxYTMuaTWtrZ86mNgHkNFshIuo51xv3uNtxCrJo1ozoN9IK/k U7+0fy/+uQI= =yEV5 -----END PGP SIGNATURE----- --=-=-=-- From d.sturek@att.net Thu Feb 21 13:39: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 8007221E8039 for ; Thu, 21 Feb 2013 13:39:14 -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 2xw5BUMmAUOh for ; Thu, 21 Feb 2013 13:39:13 -0800 (PST) Received: from nm22.access.bullet.mail.mud.yahoo.com (nm22.access.bullet.mail.mud.yahoo.com [66.94.237.223]) by ietfa.amsl.com (Postfix) with ESMTP id B1A2721E8047 for ; Thu, 21 Feb 2013 13:39:13 -0800 (PST) Received: from [66.94.237.195] by nm22.access.bullet.mail.mud.yahoo.com with NNFMP; 21 Feb 2013 21:39:13 -0000 Received: from [68.142.198.204] by tm6.access.bullet.mail.mud.yahoo.com with NNFMP; 21 Feb 2013 21:39:13 -0000 Received: from [127.0.0.1] by smtp105.sbc.mail.mud.yahoo.com with NNFMP; 21 Feb 2013 21:39:13 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1361482753; bh=G8Ts1SCrUgAPpZ5b6N1xJobhG+VLRN4/GrR6FDXLopM=; h=X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:CC:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=uGsS+08z1cCxLdUbfNdRuFfNFYn6SvU08iV1EpuxGg1RW/SrEr/nNbA0xRb7Bt6RKdwXArY9BBY944sm0T7MZvDWDpIdzc0YUQRaV5nI0BjG0r9vDpwuOTJ6DRtJ2gOWEGMs68Gwr68Jm5Wbfh/CUmoGq9G4YHtoiE7rMNYYcw0= X-Yahoo-Newman-Id: 69835.17230.bm@smtp105.sbc.mail.mud.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: xSHZu30VM1l7nhCGA5fRjlvqRdttT6tYgJTyiBv4UTKY9QG 4VnEAxwQQlt96eF6Xcr0GKGtb6XKLIWp_Ssi7EkKIscLZ.UxCeIBfQfXvEtI l.ms0DLs43wZzwgxRO_F3sZZ9vv3nj7mkx_EvghbUs9NSHVJRA5uDwG1Ca3I UOJ_3NfiRaTbXCeDScf1BKKDAE_hipl1HT5RPw0qI6J5GZYClgvwkaugtI2L 1oWyAdLFOLCIQCwgdUc1PDQjufDOp1p4.GfHooE1ii2_258F_yi_4rEIQotg NeibIWhJfWHxWMGQL5EXoc7i_Lkvkbi.p5t.UYkpSTZlBs_tn57QCOHq36zk LrBigHGyKckvewWXYCzx4CykUUyGHIfT4Wbw0j_Gt0Q9LbtQldMOs7SeVWhZ EcTxqtpnJr6oxeW0p1MELy.S4rutO7veRSgUeUfohWMSVHlkohgL4_ozXZ1B lxSTg8N656gBHkw7Je7zhFGgqzC9dUTmXX58X2Q-- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [192.168.0.199] (d.sturek@67.124.203.226 with login) by smtp105.sbc.mail.mud.yahoo.com with SMTP; 21 Feb 2013 13:39:12 -0800 PST User-Agent: Microsoft-MacOutlook/14.3.1.130117 Date: Thu, 21 Feb 2013 13:37:55 -0800 From: Don Sturek To: Michael Richardson Message-ID: Thread-Topic: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-03 In-Reply-To: <16168.1361477562@sandelman.ca> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: roll@ietf.org Subject: Re: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 21:39:14 -0000 Hi Michael, No, however, I was hoping the applicability statement would outline the list of features of the protocol that map to solving home and building automation issues. I do, however, expect that the applicability statement by itself is insufficient to build interoperable vendor solutions (plus the IETF does not create certification programs). So the main purpose is to provide a document to groups like: Z-Wave, ZigBee, CABA, ASHRAE, BACnet, etc. where they can begin to define protocols that fit their use cases. Don On 2/21/13 12:12 PM, "Michael Richardson" wrote: > >>>>>> "Don" == Don Sturek writes: > Don> Having implemented and certified 6 vendor solutions using ROLL > Don> RPL in ZigBee IP, I doubt very seriously that this is true: > > Don> "......because these are questions that need to be answered if > Don> we are going to have interoperability between muyltiple vendors > Don> without resorting to yet another level of vendor forums)" > > Don> It would be best to keep the scope of the applicability > Don> statement to just RPL P2P, not add assumptions on the use of > Don> outside RFCs/drafts and let commercial groups complete > Don> certification by choosing configuration parameters that address > Don> their needs. > >Don, are you offering to take the Home and Building Applicability >statement to a vendor forum, and produce a document which a *building >architect* (not a member of said vendor forum) can list on a NAFTA >Article 10-compliant RFP, and which will tell an implementor (also not a >member of said vendor forum) what pieces need to be implemented in order >to interoperate? > >Because, that's the situation for all other IETF (routing) specifications. > >-- >] Never tell me the odds! | ipv6 mesh >networks [ >] Michael Richardson, Sandelman Software Works | network >architect [ >] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails > [ > > From abdussalambaryun@gmail.com Thu Feb 21 14:51: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 8EBF221E803F for ; Thu, 21 Feb 2013 14:51:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.545 X-Spam-Level: X-Spam-Status: No, score=-3.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 NBn0Q3mB4bpO for ; Thu, 21 Feb 2013 14:51:05 -0800 (PST) Received: from mail-pb0-f54.google.com (mail-pb0-f54.google.com [209.85.160.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0C84C21E803D for ; Thu, 21 Feb 2013 14:51:02 -0800 (PST) Received: by mail-pb0-f54.google.com with SMTP id rr4so28299pbb.13 for ; Thu, 21 Feb 2013 14:51: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=4W0LDr9J7Q2ltv8FH6XmC8YvzypBuRrrL0ql3ds0IEo=; b=hX/Ro5zlIYO4m7/NGgHhMe+//h9XTHCLhHX3MltwZ7U9SFAfRmjsrPQYnJVGu+NAUD iTB4BI6fX3sNac3FpDki2jyn5+WwrjjlOgqqq5/EME4ZYnXSzEDJ6yQIbMEnuKz41r+r NLEbwVePZfCYB1LSA74WyyFjNGNnlx4NNL3Ho0H1+tTbPvlhhkbx6kvTj/XgpoJHLRVh w4wCj7yDe43yBcoDJyTLhmJBCZi9zeObcYahj3qmiCNbNizKgHlGrUUaNa0aXKdMccPo HpdLehyUq/ine5MOzxjiBpC19YgpbRJdsVtDLv6N00os/ute8smK+dv63tQH6XiaIA6u ZBlg== MIME-Version: 1.0 X-Received: by 10.66.220.227 with SMTP id pz3mr535805pac.190.1361487061872; Thu, 21 Feb 2013 14:51:01 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 21 Feb 2013 14:51:01 -0800 (PST) In-Reply-To: <21952.1361479420@sandelman.ca> References: <26596.1361470574@sandelman.ca> <21952.1361479420@sandelman.ca> Date: Thu, 21 Feb 2013 23:51:01 +0100 Message-ID: From: Abdussalam Baryun To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 22:51:16 -0000 I agree with situation interoperability for the doc as you state in your message, however, I ment that the interoperability among different implemetation of the protocol. Will you include that in draft as well? AB On 2/21/13, Michael Richardson wrote: > >>>>>> "Abdussalam" == Abdussalam Baryun >>>>>> writes: > Abdussalam> IMHO, I don't think the draft is about interoperability, > Abdussalam> nor commercial issues. The draft is an applicability > Abdussalam> draft, it helps users to use the protocol in such > Abdussalam> environment or applications, > > If there is anything in the document which is not essential for > interoperability then it can be removed from the document. > > RFC6550 and friends (including the 6lowpan and 6man things) have given > us palette of options. The purpose of this document is how to apply > those options to a specific situation. This document *MUST* explain > what options *MUST* be present in a device in order to interoperate > in the situation. Given the real constraints in the devices involved, > they can be manufactured with every available feature of the protocol, > nor can we assume that we can turn them all on at the same time, and > create as much state (==memory) as we want. > > -- > Michael Richardson , Sandelman Software Works > IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ > > From abdussalambaryun@gmail.com Thu Feb 21 14:53: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 43FB321E803D for ; Thu, 21 Feb 2013 14:53:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.547 X-Spam-Level: X-Spam-Status: No, score=-3.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 HtDotlPgwHuQ for ; Thu, 21 Feb 2013 14:53:42 -0800 (PST) Received: from mail-pb0-f42.google.com (mail-pb0-f42.google.com [209.85.160.42]) by ietfa.amsl.com (Postfix) with ESMTP id C84A221E8039 for ; Thu, 21 Feb 2013 14:53:42 -0800 (PST) Received: by mail-pb0-f42.google.com with SMTP id xb4so30280pbc.1 for ; Thu, 21 Feb 2013 14:53:42 -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=7Mqc5K3yviUVuZD4RM3OLG87WAhUmHyvTCc8PzbHbt4=; b=gpaFDuk3QHXjM1L0nbUQw0YfesR6RIDVKz0eJacX4eI09lL5AxejdqZK9+L8DnyyTV ZcgypqHZ18qBYEInXZ6BJUNETMFBFUwkf1JXd+CFEVUgOSxMSgeVVdOuZT10VySFTqMj gsjXlnjU1ioMkzkWpkZguudI6LE5Zw2L8mitMnGlYKjVLnNCfAMEZe/rzL4fyz1grIdu fnWgp8O1W+Mv6Fl8S02y2Ff8gGR7yQsxwl9KXXruFfnvxLm3bpzvXnX94yiwwc9cEEC5 VYxDtKv6RhXJzskCxZfqMptr0s21pC5hFxw4InMldmIMp5guwBeKed8+ENz8aMPlE2lP o+pQ== MIME-Version: 1.0 X-Received: by 10.68.217.2 with SMTP id ou2mr57390764pbc.6.1361487222570; Thu, 21 Feb 2013 14:53:42 -0800 (PST) Received: by 10.68.33.132 with HTTP; Thu, 21 Feb 2013 14:53:42 -0800 (PST) In-Reply-To: References: <26596.1361470574@sandelman.ca> <21952.1361479420@sandelman.ca> Date: Thu, 21 Feb 2013 23:53:42 +0100 Message-ID: From: Abdussalam Baryun To: Michael Richardson Content-Type: text/plain; charset=ISO-8859-1 Cc: roll@ietf.org Subject: Re: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 21 Feb 2013 22:53:43 -0000 I ment not to include the interoperability among different implemetation of the protocol in the draft proposed. If I misunderstood please advise, AB > > On 2/21/13, Michael Richardson wrote: >> >>>>>>> "Abdussalam" == Abdussalam Baryun >>>>>>> writes: >> Abdussalam> IMHO, I don't think the draft is about interoperability, >> Abdussalam> nor commercial issues. The draft is an applicability >> Abdussalam> draft, it helps users to use the protocol in such >> Abdussalam> environment or applications, >> >> If there is anything in the document which is not essential for >> interoperability then it can be removed from the document. >> >> RFC6550 and friends (including the 6lowpan and 6man things) have given >> us palette of options. The purpose of this document is how to apply >> those options to a specific situation. This document *MUST* explain >> what options *MUST* be present in a device in order to interoperate >> in the situation. Given the real constraints in the devices involved, >> they can be manufactured with every available feature of the protocol, >> nor can we assume that we can turn them all on at the same time, and >> create as much state (==memory) as we want. >> >> -- >> Michael Richardson , Sandelman Software Works >> IETF ROLL WG co-chair. http://datatracker.ietf.org/wg/roll/charter/ >> >> > From prvs=758cb3005=mukul@uwm.edu Thu Feb 21 18:01: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 64E5B21F87B3 for ; Thu, 21 Feb 2013 18:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 8xRAnfEWKHKA for ; Thu, 21 Feb 2013 18:01:54 -0800 (PST) Received: from ip4mta.uwm.edu (ip4mta.uwm.edu [129.89.7.194]) by ietfa.amsl.com (Postfix) with ESMTP id B08AB21E8039 for ; Thu, 21 Feb 2013 18:01:53 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap8EADPQJlF/AAAB/2dsb2JhbABFhk66S4EfgxIBAQEDAQEBASBLCxsaAg0ZAikwBhOIDAYMrR2JFoh/gSONNzQHgi2BEwOIaYoNg0CQXoFSgVSCCA Received: from localhost (localhost.localdomain [127.0.0.1]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id ABFEA2A1457; Thu, 21 Feb 2013 20:01:52 -0600 (CST) X-Virus-Scanned: amavisd-new at Received: from mta04.pantherlink.uwm.edu ([127.0.0.1]) by localhost (mta04.pantherlink.uwm.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HXykU5SDYaqH; Thu, 21 Feb 2013 20:01:52 -0600 (CST) Received: from mail17.pantherlink.uwm.edu (mail17.pantherlink.uwm.edu [129.89.7.177]) by mta04.pantherlink.uwm.edu (Postfix) with ESMTP id 4B8042A1456; Thu, 21 Feb 2013 20:01:52 -0600 (CST) Date: Thu, 21 Feb 2013 20:01:52 -0600 (CST) From: Mukul Goyal To: Michael Richardson Message-ID: <1528685551.439964.1361498512224.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <19733.1361468475@sandelman.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - SAF3 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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, 22 Feb 2013 02:01:55 -0000 >> Based upon recent clarifications to P2P-RPL, it seems that it is >> not possible to use P2P-RPL without prior using rooted RPL, Ralph> How so? [MCR] 1) we said that LL addressees are not permitted in the P2P's DRO. 2) we said that P2P can not have a PIO, so the P2P process can not number the nodes. Therefore, in order to use P2P RPL, there must first have been an RPL that provided stable addresses to all nodes. (I wrote "rooted", intending to mean grounded, but probably that's too much) [MG] But, P2P-RPL allows elision of the prefix. So, why can't a router (in a home LLN) participate in P2P-RPL using just link identifier as the address? Why does it need to know the prefix if it is understood that there is only one prefix and that prefix can be elided? Mukul -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=758cb3005=mukul@uwm.edu Thu Feb 21 18:05: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 4DD8F21E8044 for ; Thu, 21 Feb 2013 18:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTvZuNs7NkNa for ; Thu, 21 Feb 2013 18:05:19 -0800 (PST) Received: from ip4mta.uwm.edu (ip4mta.uwm.edu [129.89.7.194]) by ietfa.amsl.com (Postfix) with ESMTP id 5F88E21E803A for ; Thu, 21 Feb 2013 18:05:15 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqAEAEnRJlF/AAAB/2dsb2JhbABFhk66S4EfgxIBAQEDAQEBASBLCwwPEQQBAQMCDRkCKSgIBhOIDAYMrR6JFoh/gSONNzQHBoIngRMDiGmKDYNAkF6BUoFUggg Received: from localhost (localhost.localdomain [127.0.0.1]) by mta02.pantherlink.uwm.edu (Postfix) with ESMTP id CB6802E142A; Thu, 21 Feb 2013 20:05:14 -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 sDKED8iYimrQ; Thu, 21 Feb 2013 20:05:14 -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 7F5C72E141E; Thu, 21 Feb 2013 20:05:14 -0600 (CST) Date: Thu, 21 Feb 2013 20:05:14 -0600 (CST) From: Mukul Goyal To: Michael Richardson Message-ID: <1635992928.439981.1361498714457.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <1528685551.439964.1361498512224.JavaMail.root@mail17.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - SAF3 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll@ietf.org Subject: Re: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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, 22 Feb 2013 02:05:21 -0000 I meant interface identifier (not link identifier). ----- Original Message ----- From: "Mukul Goyal" To: "Michael Richardson" Cc: roll@ietf.org Sent: Thursday, February 21, 2013 8:01:52 PM Subject: Re: [Roll] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-03 >> Based upon recent clarifications to P2P-RPL, it seems that it is >> not possible to use P2P-RPL without prior using rooted RPL, Ralph> How so? [MCR] 1) we said that LL addressees are not permitted in the P2P's DRO. 2) we said that P2P can not have a PIO, so the P2P process can not number the nodes. Therefore, in order to use P2P RPL, there must first have been an RPL that provided stable addresses to all nodes. (I wrote "rooted", intending to mean grounded, but probably that's too much) [MG] But, P2P-RPL allows elision of the prefix. So, why can't a router (in a home LLN) participate in P2P-RPL using just link identifier as the address? Why does it need to know the prefix if it is understood that there is only one prefix and that prefix can be elided? Mukul -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From prvs=758cb3005=mukul@uwm.edu Thu Feb 21 18:43: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 B65AB21E803D for ; Thu, 21 Feb 2013 18:43:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, 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 7fGHzbqYF5mS for ; Thu, 21 Feb 2013 18:43:13 -0800 (PST) Received: from ip4mta.uwm.edu (ip4mta.uwm.edu [129.89.7.194]) by ietfa.amsl.com (Postfix) with ESMTP id 4097F21E803C for ; Thu, 21 Feb 2013 18:43:13 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ap4EAMDaJlF/AAAB/2dsb2JhbABFhk66S4EfgxkjVikMAg0ZAlkGiCWtJIkXiQKBI403NAeCLYETA4hpjU2QXoMmggg Received: from localhost (localhost.localdomain [127.0.0.1]) by mta03.pantherlink.uwm.edu (Postfix) with ESMTP id EA64512130A; Thu, 21 Feb 2013 20:43:07 -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 qDkiFRIFG80n; Thu, 21 Feb 2013 20:43:07 -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 C61E1121308; Thu, 21 Feb 2013 20:43:07 -0600 (CST) Date: Thu, 21 Feb 2013 20:43:07 -0600 (CST) From: Mukul Goyal To: Michael Richardson Message-ID: <1118069084.440293.1361500987731.JavaMail.root@mail17.pantherlink.uwm.edu> In-Reply-To: <1370723398.440283.1361500934446.JavaMail.root@mail17.pantherlink.uwm.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [99.20.249.193] X-Mailer: Zimbra 6.0.15_GA_2995 (ZimbraWebClient - SAF3 (Win)/6.0.15_GA_2995) X-Authenticated-User: mukul@uwm.edu Cc: roll Subject: [Roll] Address configuration in Applicability statements X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 02:43:13 -0000 Michael Should you add IPv6 Address Configuration to the list in ROLL Applicability Statement Template? Thanks Mukul From mcr@sandelman.ca Fri Feb 22 06:03: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 04B0F21F8472 for ; Fri, 22 Feb 2013 06:03:45 -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 QW5cd-EW6zOB for ; Fri, 22 Feb 2013 06:03: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 2D7BF21F8473 for ; Fri, 22 Feb 2013 06:03:44 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id E0A202016D; Fri, 22 Feb 2013 09:10:36 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 760B06387F; Fri, 22 Feb 2013 09:02:35 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6AD3A63765; Fri, 22 Feb 2013 09:02:35 -0500 (EST) From: Michael Richardson To: Mukul Goyal In-Reply-To: <1528685551.439964.1361498512224.JavaMail.root@mail17.pantherlink.uwm.edu> References: <1528685551.439964.1361498512224.JavaMail.root@mail17.pantherlink.uwm.edu> 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] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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, 22 Feb 2013 14:03:45 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mukul" =3D=3D Mukul Goyal writes: Mukul> But, P2P-RPL allows elision of the prefix. So, why can't a Mukul> router (in a home LLN) participate in P2P-RPL using just link Mukul> identifier as the address? Why does it need to know the Mukul> prefix if it is understood that there is only one prefix and Mukul> that prefix can be elided? Perhaps I don't understand this part. =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) iQCVAwUAUSd6e4qHRg3pndX9AQJ3kAQAnJt1uKcGB1t4ZpBAgj0OmkVtSL7Yzlyv zpB7++RCfGVOKhKoVFpRji2XAV+2uIdmjyg7A9oC2NTXsgGOAQUcZFkNs5921Mzx UeCLkg0axq37x3DusoSrW7kCbwvBrhcIC17cS8WEQA4s739GgAjzS2tyTmnoqui+ W1sGCEwFEys= =CQS2 -----END PGP SIGNATURE----- --=-=-=-- From rdroms.ietf@gmail.com Fri Feb 22 06: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 96D2E21F8EC1 for ; Fri, 22 Feb 2013 06:26:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.55 X-Spam-Level: X-Spam-Status: No, score=-103.55 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, 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 K8GflzJs5nYA for ; Fri, 22 Feb 2013 06:26:18 -0800 (PST) Received: from mail-vc0-f178.google.com (mail-vc0-f178.google.com [209.85.220.178]) by ietfa.amsl.com (Postfix) with ESMTP id 167B921F8472 for ; Fri, 22 Feb 2013 06:26:18 -0800 (PST) Received: by mail-vc0-f178.google.com with SMTP id m8so430206vcd.37 for ; Fri, 22 Feb 2013 06:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=EAKTbR3dm2MBZzUrElADs22nyj+Y2pPabDIwXapGYR0=; b=dBHRyi/G5lxHQRdbh1LB0+BFFig+J64pa+DpU8FdGYz0BXdFl5ilwSCAce2pziAB0+ PcAJRUxJApjDaAZ71dg/DfnNtDwFfhB5rFqVL/t9lTeuIq2+/dLM+To18XwXj+weMQYA 93i0r+RiyEVLEcSAHQCZxE/t8pX+SNVimZpEzziP2GFjdRogWLsxj80jAD7nBcdY9HJP XTuCirwZc338JnwtoQpePO5pQDD2/+xFycXYw6SnIuLay4SLCyAojEMSFRGWGPbHPBbF sNIjOwdMAlwMD8N0W6bhG1IWvqp1HoPTF13E5zJNZNUR+ycCvuGhUUJ6aXEvKjtmJ+f7 qZ7A== X-Received: by 10.58.213.37 with SMTP id np5mr2709020vec.54.1361543177440; Fri, 22 Feb 2013 06:26:17 -0800 (PST) Received: from ?IPv6:2001:420:2481:20:b1d6:2d09:fcb3:235d? ([2001:420:2481:20:b1d6:2d09:fcb3:235d]) by mx.google.com with ESMTPS id kn18sm3680252veb.5.2013.02.22.06.26.15 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Feb 2013 06:26:16 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ralph Droms In-Reply-To: <00c701ce0539$b07a1a70$116e4f50$@olddog.co.uk> Date: Fri, 22 Feb 2013 09:26:12 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <00c701ce0539$b07a1a70$116e4f50$@olddog.co.uk> To: "roll@ietf.org" X-Mailer: Apple Mail (2.1499) Subject: Re: [Roll] Heads up : Last Call: to Experimental RFC (Reminder) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:26:18 -0000 Following up on Adrian's announcement of Feb 7... draft-cardenas-dff is under consideration for publication as an = AD-sponsored individual submission Experimental RFC. I agreed to = sponsor it for publication because it doesn't really fit in any existing = working groups and the requested publication status is Experimental. As = part of the review process, the document is in a 2-week IETF last call. = To ensure the quality of the document, it would be helpful to get = reviews from roll WG participants (posted to the ietf@ietf.org = discussion list). Expressions of an opinion about whether or not to publish the document, = in addition to technical input to the authors, would be useful. Thanks. - Ralph From mcr@sandelman.ca Fri Feb 22 06:29: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 1C02F21F8E22 for ; Fri, 22 Feb 2013 06:29:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 MvgXSMMSv8yZ for ; Fri, 22 Feb 2013 06:29: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 EC95321F8E17 for ; Fri, 22 Feb 2013 06:29:11 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 269872016D; Fri, 22 Feb 2013 09:36:01 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 2EE346387F; Fri, 22 Feb 2013 09:27:59 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 200EA63765; Fri, 22 Feb 2013 09:27:59 -0500 (EST) From: Michael Richardson To: roll In-Reply-To: <1118069084.440293.1361500987731.JavaMail.root@mail17.pantherlink.uwm.edu> References: <1118069084.440293.1361500987731.JavaMail.root@mail17.pantherlink.uwm.edu> 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] Address configuration in Applicability statements X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2013 14:29:13 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable >>>>> "Mukul" =3D=3D Mukul Goyal writes: Mukul> Should you add IPv6 Address Configuration to the list in ROLL Mukul> Applicability Statement Template? Yes, I guess so. I think it goes under the RPL Profile, RPL Features section. I'd like to put it first, but I also don't want to needlessly renumber things, so I'll put it last. =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) iQCVAwUAUSeAb4qHRg3pndX9AQJ22wQA6bfByo5bJ1+GzTnJ7yVx+ipv8d6QtU0G Arh0t9sKDF3ZHgn5gmDuhrIjkQp41YBFj7zYTt0qvgk7PzljRjLQpPioUxQIkRii fWpQgN9+bTJJfqpszCVrfDgPO8QJuP8hemuT3jr4hnAcuJIWyif29RBo8JrKYHKc 53XSt+KgLvM= =0POA -----END PGP SIGNATURE----- --=-=-=-- From abdussalambaryun@gmail.com Sun Feb 24 22:05:42 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 CEF9B21F917B for ; Sun, 24 Feb 2013 22:05:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 HBzFO77fIaCV for ; Sun, 24 Feb 2013 22:05:42 -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 CC48F21F914F for ; Sun, 24 Feb 2013 22:05:41 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id um15so1489276pbc.28 for ; Sun, 24 Feb 2013 22:05: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=8H85OqDgL031a+hzUt6/zrS1NJ3ZuSwrSdtM3y5Vhf0=; b=zQFZO1P/1rpaIM3wkB24u8dw1N69Wd8j3Lcz0jqYLGdal4oau4JnVu2qIAIBh2EP7i dQQF01GJZn/2aw6lsRUn20bTaYHvOWcCqX5Xo092YbnBSy7eAJ3ZIYiyfg3H2Wi6ixr2 adD0BeSvrBoZF0dvEI0QkmREqnLyD4sES3GPlJIILtc5vuzoZif0k93mtndyQerQ5yAO 4UeIRb6VgOAFhr8a3FwaVpATs2r9otaByRt5UiVdf2ZY0gXYAU66m3s4Qa5z4XYI/MXX rdi2fl6Sd/m/ZDMIBvzh9DSqIgmeGOIW8lQz4+ZsRRAJIL1o6S6lGL3Y0HPe8ScPkdMF QuPQ== MIME-Version: 1.0 X-Received: by 10.66.220.227 with SMTP id pz3mr17004955pac.190.1361772341633; Sun, 24 Feb 2013 22:05:41 -0800 (PST) Received: by 10.68.33.132 with HTTP; Sun, 24 Feb 2013 22:05:41 -0800 (PST) In-Reply-To: References: <00c701ce0539$b07a1a70$116e4f50$@olddog.co.uk> Date: Mon, 25 Feb 2013 07:05:41 +0100 Message-ID: From: Abdussalam Baryun To: Ralph Droms Content-Type: text/plain; charset=ISO-8859-1 Cc: "roll@ietf.org" Subject: Re: [Roll] Heads up : Last Call: to Experimental RFC (Reminder) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Feb 2013 06:05:43 -0000 Hi Ralph, I ended my comments today with the last input, hope that is ok, because it mention 24 Feb and today is 25 Feb, however, thanks for reminder, AB On 2/22/13, Ralph Droms wrote: > Following up on Adrian's announcement of Feb 7... > > draft-cardenas-dff is under consideration for publication as an AD-sponsored > individual submission Experimental RFC. I agreed to sponsor it for > publication because it doesn't really fit in any existing working groups and > the requested publication status is Experimental. As part of the review > process, the document is in a 2-week IETF last call. To ensure the quality > of the document, it would be helpful to get reviews from roll WG > participants (posted to the ietf@ietf.org discussion list). > > Expressions of an opinion about whether or not to publish the document, in > addition to technical input to the authors, would be useful. > > Thanks. > > - Ralph > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From ulrich@herberg.name Sun Feb 24 23:15: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 C840621F9221 for ; Sun, 24 Feb 2013 23:15:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=0.090, 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 eDbrQNyApwbU for ; Sun, 24 Feb 2013 23:15:14 -0800 (PST) Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id A43BE21F8F71 for ; Sun, 24 Feb 2013 23:15:13 -0800 (PST) Received: by mail-vb0-f44.google.com with SMTP id fr13so1523679vbb.31 for ; Sun, 24 Feb 2013 23:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herberg.name; s=dkim; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=zUE9cjiewdngIaD1atXo4Pfc81V8iZ7VIstJrLVxmkM=; b=MsMcObXtnYzpL8ZIc/+i5GBTt7U7nLDxi5J3qCIbX5MnZL0b4RmCoBkrxk8NsOm8Bp rLOFFYkHV8NBhAFskNIb0ty0q2k8/u2xW0ecTCGhv/BwbZYm8f4vFeE1rNqIBQxo8N2C OERTg2E/GLrOpK4zyIQnMy3XJgZKJxOBpSkkY= 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=zUE9cjiewdngIaD1atXo4Pfc81V8iZ7VIstJrLVxmkM=; b=BJATUiYl1hLOuWIispcY4LvfI1NGJSXSy1N2SyGY/GxbnrryMnSHSDLzIdchx3eFh/ vuxgK5a+S8Hud5BJF4exh5u18zkwVVajtw6yHhMMzulFhDgNf4eCdY/8+azXXKzBEAMF o/XXbJCzzbrkflmg6/vuh3AnQPCMoluKelGMsbqz97dKvcbxK0BN+KEvBQ2x69uDvE60 sSWl+y2c43QEtfRnag6OVmXtLF8MB6XJkh/Gfwp7XHy36USPUgWVe5DBRShdNw+O/qa+ OsAWTcc459b84dGLtHNFeXNQsnaB3vkMCQbJEZQ/vAW9cNpOrgrxv50xE45urpbQs8DD /hSQ== MIME-Version: 1.0 X-Received: by 10.59.4.101 with SMTP id cd5mr330616ved.14.1361776512989; Sun, 24 Feb 2013 23:15:12 -0800 (PST) Received: by 10.220.107.7 with HTTP; Sun, 24 Feb 2013 23:15:12 -0800 (PST) In-Reply-To: References: <00c701ce0539$b07a1a70$116e4f50$@olddog.co.uk> Date: Sun, 24 Feb 2013 23:15:12 -0800 Message-ID: From: Ulrich Herberg To: Abdussalam Baryun Content-Type: multipart/alternative; boundary=089e01160c4e52166804d6874d21 X-Gm-Message-State: ALoCoQled4tVVDb3iVqNfVfNdn1xJOJY3h3bAWrhV5zlh3cfZ0+b4VdlfGWCgIIv5KzAx8UaL/w0 Cc: "roll@ietf.org" Subject: Re: [Roll] Heads up : Last Call: to Experimental RFC (Reminder) X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Feb 2013 07:15:14 -0000 --089e01160c4e52166804d6874d21 Content-Type: text/plain; charset=ISO-8859-1 AB, I have received the comments and will reply to all comments (and update the draft where necessary) starting next week. I apologize for the delay, but I am currently on a business trip outside the country. Regards Ulrich On Sun, Feb 24, 2013 at 10:05 PM, Abdussalam Baryun < abdussalambaryun@gmail.com> wrote: > Hi Ralph, > > I ended my comments today with the last input, hope that is ok, > because it mention 24 Feb and today is 25 Feb, however, thanks for > reminder, > > AB > > On 2/22/13, Ralph Droms wrote: > > Following up on Adrian's announcement of Feb 7... > > > > draft-cardenas-dff is under consideration for publication as an > AD-sponsored > > individual submission Experimental RFC. I agreed to sponsor it for > > publication because it doesn't really fit in any existing working groups > and > > the requested publication status is Experimental. As part of the review > > process, the document is in a 2-week IETF last call. To ensure the > quality > > of the document, it would be helpful to get reviews from roll WG > > participants (posted to the ietf@ietf.org discussion list). > > > > Expressions of an opinion about whether or not to publish the document, > in > > addition to technical input to the authors, would be useful. > > > > Thanks. > > > > - Ralph > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --089e01160c4e52166804d6874d21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable AB,

I have received the comments and will reply to all comments (and= update the draft where necessary) starting next week. I apologize for the = delay, but I am currently on a business trip outside the country.

Regards
Ulrich

On Sun, Feb 24, 2013 at= 10:05 PM, Abdussalam Baryun <abdussalambaryun@gmail.com><= /span> wrote:
Hi Ralph,

I ended my comments today with the last input, hope that is ok,
because it mention 24 Feb and today is 25 Feb, however, thanks for
reminder,

AB

On 2/22/13, Ralph Droms <rdroms= .ietf@gmail.com> wrote:
> Following up on Adrian's announcement of Feb 7...
>
> draft-cardenas-dff is under consideration for publication as an AD-spo= nsored
> individual submission Experimental RFC. =A0I agreed to sponsor it for<= br> > publication because it doesn't really fit in any existing working = groups and
> the requested publication status is Experimental. =A0As part of the re= view
> process, the document is in a 2-week IETF last call. =A0To ensure the = quality
> of the document, it would be helpful to get reviews from roll WG
> participants (posted to the ietf@ietf= .org discussion list).
>
> Expressions of an opinion about whether or not to publish the document= , in
> addition to technical input to the authors, would be useful.
>
> Thanks.
>
> - Ralph
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
_______________________________________________
Roll mailing list
Roll@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/roll

--089e01160c4e52166804d6874d21-- From pthubert@cisco.com Mon Feb 25 02:58: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 4E1E821F9099 for ; Mon, 25 Feb 2013 02:58:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[AWL=0.447, 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 ZBHUZR30eX4G for ; Mon, 25 Feb 2013 02:58:44 -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 60A6621F9016 for ; Mon, 25 Feb 2013 02:58:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3758; q=dns/txt; s=iport; t=1361789922; x=1362999522; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=zG91zV8C1oo4DOssRZT0kDsN9Wi2ZzmVqPxv+Srgswo=; b=Bq6czZdmABV+HHrzmz7q4Gk9H6+pGmc8kDYwWJvOhFdJ+TevIfa+xNU9 1xmj92drSoaaTr1U9dN6GfHBUHCDcPVLDG7Yi4JWHaYZyMEZ7N0wivSxY fPznM/4ZN0fbQGzal4LRrCGR67JDmZ4YktO7TAOna1ppzNjESw4cHUHZj w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFALdCK1GtJXHB/2dsb2JhbABFg3iCV7sEDXcWc4IfAQEBBCMRQw4GARkEAQEDAgYdAwIEMBQBCAkBBBMIAYgKBwWeAo5VkVaBI4wkgRYmGIInMmEDknyEXo9IgweBaQIeBhg X-IronPort-AV: E=Sophos;i="4.84,733,1355097600"; d="scan'208";a="180771214" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 25 Feb 2013 10:58:41 +0000 Received: from xhc-rcd-x06.cisco.com (xhc-rcd-x06.cisco.com [173.37.183.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1PAwfuD008367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Feb 2013 10:58:41 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.89]) by xhc-rcd-x06.cisco.com ([173.37.183.80]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 04:58:41 -0600 From: "Pascal Thubert (pthubert)" To: "roll@ietf.org" Thread-Topic: New Version Notification for draft-thubert-roll-forwarding-frags-01.txt Thread-Index: Ac4TRt1lRn7yWP4fSC6poc/BQIBG4g== Date: Mon, 25 Feb 2013 10:58:41 +0000 Deferred-Delivery: Mon, 25 Feb 2013 10:58:00 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.88.253] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: [Roll] New Version Notification for draft-thubert-roll-forwarding-frags-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, 25 Feb 2013 10:58:45 -0000 RGVhciBXRzoNCg0KQXMgeW91IGtub3cgd2VsbCwgNkxvV1BBTiB3aWxsIGZyYWdtZW50IHBhY2tl dHMgdGhhdCBhcmUgdG9vIHdpZGUgZm9yIHRoZSBNVFUsIHdoaWNoIGlzIGxpa2VseSB0byBoYXBw ZW4gaW4gYSBudW1iZXIgb2YgY2FzZXMsIHVubGVzcyB0aGUgODAyLjE1LjRnIE1BQyBpcyB1c2Vk Lg0KDQpBcyBhIGNvbnNlcXVlbmNlLCBpbiBhIHJvdXRlLW92ZXIgUlBMIHN1Ym5ldCwgYSBsYXJn ZSBwYWNrZXQgbXVzdCBiZSByZWFzc2VtYmxlZCBhdCBlYWNoIGhvcCB0byBiZSByb3V0ZWQgYW5k IGZyYWdtZW50ZWQgYWdhaW4uIA0KDQpTdHJlYW1saW5pbmcgdGhlIGZyYWdtZW50cyB3aWxsIGlt cHJvdmUgbGF0ZW5jeSwgYW5kIHdpbGwgc2F2ZSBtZW1vcnkgYW5kIENQVSBpbiB0aGUgaW50ZXJt ZWRpYXRlIG5vZGVzLg0KDQpUaGlzIGRyYWZ0IGVuYWJsZXMgdGhlIGZvcndhcmRpbmcgb2YgZnJh Z21lbnRzLCB3aGljaCBzZWxlY3RpdmUgYWNrbm93bGVkZ2VtZW50IGFuZCBmbG93IGNvbnRyb2wg Y2FwYWJpbGl0aWVzLCBlbmQgdG8gZW5kIG92ZXIgdGhlIExMTi4NCg0KVXBvbiBhIHByaXZhdGUg cmVxdWVzdCwgSSByZXN1Ym1pdHRlZCB0aGUgZHJhZnQgd2l0aCBhIHNpbXBsaWZpY2F0aW9uLCB0 aGF0IGlzIHRoZSByZW1vdmFsIG9mIGVuIGVuY29kaW5nIHRoYXQgd291bGQgY29tcHJlc3MgdGhl IGFja25vd2xlZGdlbWVudCBiaXRtYXAuDQoNCkkgYWxzbyByZXN0b3JlZCBzb21lIHRleHQgYWJv dXQgQ29uZ2VzdGlvbiBub3RpZmljYXRpb24sIGluIG9yZGVyIHRvIHZhbGlkYXRlIHRoZSBuZWVk IHdpdGggdGhlIGdyb3VwLg0KDQpQbGVhc2UgbGV0IHRoZSBhdXRob3JzIGtub3cgaWYgeW91IGhh dmUgaW50ZXJlc3QgaW4gcHVyc3VpbmcgdGhpcyB3b3JrLCANCg0KUGFzY2FsDQoNCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFp bHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBsdW5kaSAyNSBmw6l2cmllciAy MDEzIDExOjQyDQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KQ0KQ2M6IEpvbmF0aGFuIEh1 aSAoam9odWkpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LXRo dWJlcnQtcm9sbC1mb3J3YXJkaW5nLWZyYWdzLTAxLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2Yg SS1ELCBkcmFmdC10aHViZXJ0LXJvbGwtZm9yd2FyZGluZy1mcmFncy0wMS50eHQNCmhhcyBiZWVu IHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgUGFzY2FsIFRodWJlcnQgYW5kIHBvc3RlZCB0byB0 aGUgSUVURiByZXBvc2l0b3J5Lg0KDQpGaWxlbmFtZToJIGRyYWZ0LXRodWJlcnQtcm9sbC1mb3J3 YXJkaW5nLWZyYWdzDQpSZXZpc2lvbjoJIDAxDQpUaXRsZToJCSBMTE4gRnJhZ21lbnQgRm9yd2Fy ZGluZyBhbmQgUmVjb3ZlcnkNCkNyZWF0aW9uIGRhdGU6CSAyMDEzLTAyLTI1DQpHcm91cDoJCSBJ bmRpdmlkdWFsIFN1Ym1pc3Npb24NCk51bWJlciBvZiBwYWdlczogMTYNClVSTDogICAgICAgICAg ICAgaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdGh1YmVydC1yb2xs LWZvcndhcmRpbmctZnJhZ3MtMDEudHh0DQpTdGF0dXM6ICAgICAgICAgIGh0dHA6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtdGh1YmVydC1yb2xsLWZvcndhcmRpbmctZnJhZ3MNCkh0 bWxpemVkOiAgICAgICAgaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtdGh1YmVydC1y b2xsLWZvcndhcmRpbmctZnJhZ3MtMDENCkRpZmY6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRm Lm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtdGh1YmVydC1yb2xsLWZvcndhcmRpbmctZnJhZ3MtMDEN Cg0KQWJzdHJhY3Q6DQogICBJbiBvcmRlciB0byBiZSByb3V0ZWQsIGEgZnJhZ21lbnRlZCBwYWNr ZXQgbXVzdCBiZSByZWFzc2VtYmxlZCBhdA0KICAgZXZlcnkgaG9wIG9mIGEgbXVsdGlob3AgbGlu ayB3aGVyZSBsb3dlciBsYXllciBmcmFnbWVudGF0aW9uIG9jY3Vycy4NCiAgIENvbnNpZGVyaW5n IHRoYXQgdGhlIElQdjYgbWluaW11bSBNVFUgaXMgMTI4MCBieXRlcyBhbmQgdGhhdCBhbiBhbg0K ICAgODAyLjE1LjQgZnJhbWUgY2FuIGhhdmUgYSBwYXlsb2FkIGxpbWl0ZWQgdG8gNzQgYnl0ZXMg aW4gdGhlIHdvcnN0DQogICBjYXNlLCBhIHBhY2tldCBtaWdodCBlbmQgdXAgZnJhZ21lbnRlZCBp bnRvIGFzIG1hbnkgYXMgMTggZnJhZ21lbnRzDQogICBhdCB0aGUgNkxvV1BBTiBzaGltIGxheWVy LiAgSWYgYSBzaW5nbGUgb25lIG9mIHRob3NlIGZyYWdtZW50cyBpcw0KICAgbG9zdCBpbiB0cmFu c21pc3Npb24sIGFsbCBmcmFnbWVudHMgbXVzdCBiZSByZXNlbnQsIGZ1cnRoZXINCiAgIGNvbnRy aWJ1dGluZyB0byB0aGUgY29uZ2VzdGlvbiB0aGF0IG1pZ2h0IGhhdmUgY2F1c2VkIHRoZSBpbml0 aWFsDQogICBwYWNrZXQgbG9zcy4gIFRoaXMgZHJhZnQgaW50cm9kdWNlcyBhIHNpbXBsZSBwcm90 b2NvbCB0byBmb3J3YXJkIGFuZA0KICAgcmVjb3ZlciBpbmRpdmlkdWFsIGZyYWdtZW50cyB0aGF0 IG1pZ2h0IGJlIGxvc3Qgb3ZlciBtdWx0aXBsZSBob3BzDQogICBiZXR3ZWVuIDZMb1dQQU4gZW5k cG9pbnRzLg0KDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KVGhlIElFVEYgU2VjcmV0 YXJpYXQNCg0K From abdussalambaryun@gmail.com Mon Feb 25 07:03: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 CED8C21F9321 for ; Mon, 25 Feb 2013 07:03:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.558 X-Spam-Level: X-Spam-Status: No, score=-3.558 tagged_above=-999 required=5 tests=[AWL=0.040, 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 XCbJ1QgKcPCs for ; Mon, 25 Feb 2013 07:03:21 -0800 (PST) Received: from mail-pa0-f44.google.com (mail-pa0-f44.google.com [209.85.220.44]) by ietfa.amsl.com (Postfix) with ESMTP id 144B921F92B5 for ; Mon, 25 Feb 2013 07:03:21 -0800 (PST) Received: by mail-pa0-f44.google.com with SMTP id kp1so1803096pab.3 for ; Mon, 25 Feb 2013 07:03: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=VLLhPc7kRE2C5uxjN7ZPl7Of7BD+3JuX4khODb7KZaQ=; b=b6IwuvEXTV0QzBR3uxMbrJ1xVQnNaZ5Hwi0RSKUcJM9wb3OJyY8o/LCjf/Pzn2gdW2 /8CjfYifSq8uVqV7NraW9/itAB21CGGJe8OowxyWkt4SUv/ZLGRnFKppnuYfyikTN/MI XQZZvn+6iHCkNjwTalbn9KG9K9vQ5ICnBhxNMtUwSwFGBvgRlJrU+OSsAu2nyNtH2tvp wk81prFYiRmz9Y0kvTGDIHLMlH6ulr0UTn5j9a7Dg+9stDpdlL0Fhp4Lor55sLn8NBCX wai3nbuoKR5gMfiGfZQoXN3Nf9muLTs35iYjFLdzALINzagQDSnKRSuvgW/0R7cPqNet 2IfA== MIME-Version: 1.0 X-Received: by 10.67.5.193 with SMTP id co1mr19531873pad.6.1361804600861; Mon, 25 Feb 2013 07:03:20 -0800 (PST) Received: by 10.68.33.132 with HTTP; Mon, 25 Feb 2013 07:03:20 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Feb 2013 15:03:20 +0000 Message-ID: From: Abdussalam Baryun To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=047d7b15a5a37ce36f04d68dd7e5 Cc: "roll@ietf.org" Subject: Re: [Roll] New Version Notification for draft-thubert-roll-forwarding-frags-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, 25 Feb 2013 15:03:21 -0000 --047d7b15a5a37ce36f04d68dd7e5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Pascal, I may need to discuss to know my interest, or to understand. Does this protocol have interact with RPL or its information? The title is LLN forwarding but the content is about 6LowPan, is this work better fitted in 6LoWPAN WG than ROLL? AB On Mon, Feb 25, 2013 at 10:58 AM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Dear WG: > > As you know well, 6LoWPAN will fragment packets that are too wide for the > MTU, which is likely to happen in a number of cases, unless the 802.15.4g > MAC is used. > > As a consequence, in a route-over RPL subnet, a large packet must be > reassembled at each hop to be routed and fragmented again. > > Streamlining the fragments will improve latency, and will save memory and > CPU in the intermediate nodes. > > This draft enables the forwarding of fragments, which selective > acknowledgement and flow control capabilities, end to end over the LLN. > > Upon a private request, I resubmitted the draft with a simplification, > that is the removal of en encoding that would compress the acknowledgemen= t > bitmap. > > I also restored some text about Congestion notification, in order to > validate the need with the group. > > Please let the authors know if you have interest in pursuing this work, > > Pascal > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: lundi 25 f=E9vrier 2013 11:42 > To: Pascal Thubert (pthubert) > Cc: Jonathan Hui (johui) > Subject: New Version Notification for > draft-thubert-roll-forwarding-frags-01.txt > > > A new version of I-D, draft-thubert-roll-forwarding-frags-01.txt > has been successfully submitted by Pascal Thubert and posted to the IETF > repository. > > Filename: draft-thubert-roll-forwarding-frags > Revision: 01 > Title: LLN Fragment Forwarding and Recovery > Creation date: 2013-02-25 > Group: Individual Submission > Number of pages: 16 > URL: > http://www.ietf.org/internet-drafts/draft-thubert-roll-forwarding-frags-0= 1.txt > Status: > http://datatracker.ietf.org/doc/draft-thubert-roll-forwarding-frags > Htmlized: > http://tools.ietf.org/html/draft-thubert-roll-forwarding-frags-01 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-thubert-roll-forwarding-frags-01 > > Abstract: > In order to be routed, a fragmented packet must be reassembled at > every hop of a multihop link where lower layer fragmentation occurs. > Considering that the IPv6 minimum MTU is 1280 bytes and that an an > 802.15.4 frame can have a payload limited to 74 bytes in the worst > case, a packet might end up fragmented into as many as 18 fragments > at the 6LoWPAN shim layer. If a single one of those fragments is > lost in transmission, all fragments must be resent, further > contributing to the congestion that might have caused the initial > packet loss. This draft introduces a simple protocol to forward and > recover individual fragments that might be lost over multiple hops > between 6LoWPAN endpoints. > > > > > The IETF Secretariat > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --047d7b15a5a37ce36f04d68dd7e5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Pascal,
=A0
I may need to discuss to know my in= terest, or=A0to understand. Does this protocol have interact with RPL or it= s information? The title is=A0LLN forwarding but the content is about 6LowP= an, is this work better fitted in 6LoWPAN WG than ROLL?
=A0
AB

On Mon, Feb 2= 5, 2013 at 10:58 AM, Pascal Thubert (pthubert) <pthubert@cisco.com>= ; wrote:
Dear WG:

As you know well, 6LoWPAN will fragment packets that are too wide for the M= TU, which is likely to happen in a number of cases, unless the 802.15.4g MA= C is used.

As a consequence, in a route-over RPL subnet, a large packet must be reasse= mbled at each hop to be routed and fragmented again.

Streamlining the fragments will improve latency, and will save memory and C= PU in the intermediate nodes.

This draft enables the forwarding of fragments, which selective acknowledge= ment and flow control capabilities, end to end over the LLN.

Upon a private request, I resubmitted the draft with a simplification, that= is the removal of en encoding that would compress the acknowledgement bitm= ap.

I also restored some text about Congestion notification, in order to valida= te the need with the group.

Please let the authors know if you have interest in pursuing this work,

Pascal


-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: lundi 25 f=E9vrier 2013 11:42
To: Pascal Thubert (pthubert)
Cc: Jonathan Hui (johui)
Subject: New Version Notification for draft-thubert-roll-forwarding-frags-0= 1.txt


A new version of I-D, draft-thubert-roll-forwarding-frags-01.txt
has been successfully submitted by Pascal Thubert and posted to the IETF re= pository.

Filename: =A0 =A0 =A0 =A0draft-thubert-roll-forwarding-frags
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 LLN Fragment Forwarding and Recovery
Creation date: =A0 2013-02-25
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 16
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.i= etf.org/internet-drafts/draft-thubert-roll-forwarding-frags-01.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.o= rg/doc/draft-thubert-roll-forwarding-frags
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/dr= aft-thubert-roll-forwarding-frags-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.o= rg/rfcdiff?url2=3Ddraft-thubert-roll-forwarding-frags-01

Abstract:
=A0 =A0In order to be routed, a fragmented packet must be reassembled at =A0 =A0every hop of a multihop link where lower layer fragmentation occurs.=
=A0 =A0Considering that the IPv6 minimum MTU is 1280 bytes and that an an =A0 =A0802.15.4 frame can have a payload limited to 74 bytes in the worst =A0 =A0case, a packet might end up fragmented into as many as 18 fragments<= br> =A0 =A0at the 6LoWPAN shim layer. =A0If a single one of those fragments is<= br> =A0 =A0lost in transmission, all fragments must be resent, further
=A0 =A0contributing to the congestion that might have caused the initial =A0 =A0packet loss. =A0This draft introduces a simple protocol to forward a= nd
=A0 =A0recover individual fragments that might be lost over multiple hops =A0 =A0between 6LoWPAN endpoints.




The IETF Secretariat

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

--047d7b15a5a37ce36f04d68dd7e5-- From cabo@tzi.org Mon Feb 25 07:07: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 C616721F9470 for ; Mon, 25 Feb 2013 07:07:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.126 X-Spam-Level: X-Spam-Status: No, score=-106.126 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, 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 OYxYFjn+LEfo for ; Mon, 25 Feb 2013 07:07:27 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id CCC1B21F9325 for ; Mon, 25 Feb 2013 07:07:26 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.3/8.14.3) with ESMTP id r1PF7GhI029722; Mon, 25 Feb 2013 16:07:16 +0100 (CET) Received: from [10.0.1.4] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 9FA923808; Mon, 25 Feb 2013 16:07:16 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Mon, 25 Feb 2013 16:07:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5674DD97-6DE8-425F-B40B-5AB52941E094@tzi.org> References: To: "Pascal Thubert (pthubert)" X-Mailer: Apple Mail (2.1499) Cc: "roll@ietf.org" Subject: Re: [Roll] New Version Notification for draft-thubert-roll-forwarding-frags-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, 25 Feb 2013 15:07:27 -0000 Hi Pascal, On Feb 25, 2013, at 11:58, "Pascal Thubert (pthubert)" = wrote: > a large packet must be reassembled at each hop I thought we had debunked that idea in 2008. (For people who weren't = there then: Read more about it in the 6lowpan book.) Gr=FC=DFe, Carsten From pthubert@cisco.com Mon Feb 25 08:10: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 7A63621F94AD for ; Mon, 25 Feb 2013 08:10:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.486 X-Spam-Level: X-Spam-Status: No, score=-10.486 tagged_above=-999 required=5 tests=[AWL=0.113, 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 s66azDDBLjiz for ; Mon, 25 Feb 2013 08:10:35 -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 1637621F9445 for ; Mon, 25 Feb 2013 08:10:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1143; q=dns/txt; s=iport; t=1361808635; x=1363018235; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=F8bey/j2qQXB6ZIC8yNeHcUW6a6+ClyKWLrdOwNT7FM=; b=I/xgl+HTkBvlOGyRD9VmGXltug0XVN6AX4du+v8vmv6oJnxEIMrxO7zX 3CPLsDTYg2wp87FE52L9wcRqwlcEFZHyV+fuWE8QP/hU11X8KtiO90zUt Fcii8KilFk4z5UQ1TSdnItAwox8Kfngf4OwepHEWnf3truqDG35+VTAYj 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFADiMK1GtJXHB/2dsb2JhbABFwVWBBRZzgh8BAQEDAXcCBQcEAgEIDgMEAQELHQcyFAkIAQEEDgUIiAUGvxmOXSYLBwaCWWEDiDOeb4FSgTWCJw X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; d="scan'208";a="180870373" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-5.cisco.com with ESMTP; 25 Feb 2013 16:10:31 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1PGAV1E031355 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Feb 2013 16:10:31 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.89]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 10:10:31 -0600 From: "Pascal Thubert (pthubert)" To: Carsten Bormann Thread-Topic: [Roll] New Version Notification for draft-thubert-roll-forwarding-frags-01.txt Thread-Index: Ac4TRt1lRn7yWP4fSC6poc/BQIBG4gAVTjiAAAqSwNA= Date: Mon, 25 Feb 2013 16:10:31 +0000 Deferred-Delivery: Mon, 25 Feb 2013 16:10:00 +0000 Message-ID: References: <5674DD97-6DE8-425F-B40B-5AB52941E094@tzi.org> In-Reply-To: <5674DD97-6DE8-425F-B40B-5AB52941E094@tzi.org> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.88.253] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] New Version Notification for draft-thubert-roll-forwarding-frags-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, 25 Feb 2013 16:10:36 -0000 Hi Carsten: That's a bit of an oversight. Yes, we actually discussed the idea at 6LoWPA= N. There was even a vote at 2 or 3 meetings.=20 The first time, a majority wanted to continue the work. Then the vote was r= etried got few hands in equal numbers either way.=20 What I got from individual people is that they wanted that job done but tho= ught that 6LoWPAN as it stood was not the right place.=20 And then I was asked to publish it at ROLL, because the issue that is addre= ssed comes with fragmentation in route over mode. That's where we are... Pascal -----Original Message----- From: Carsten Bormann [mailto:cabo@tzi.org]=20 Sent: lundi 25 f=E9vrier 2013 16:07 To: Pascal Thubert (pthubert) Cc: roll@ietf.org Subject: Re: [Roll] New Version Notification for draft-thubert-roll-forward= ing-frags-01.txt Hi Pascal, On Feb 25, 2013, at 11:58, "Pascal Thubert (pthubert)" = wrote: > a large packet must be reassembled at each hop I thought we had debunked that idea in 2008. (For people who weren't there= then: Read more about it in the 6lowpan book.) Gr=FC=DFe, Carsten From pthubert@cisco.com Mon Feb 25 08:15: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 2D0BC21F94EC for ; Mon, 25 Feb 2013 08:15:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.192 X-Spam-Level: X-Spam-Status: No, score=-10.192 tagged_above=-999 required=5 tests=[AWL=0.406, 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 OZ9X1gSKW95Q for ; Mon, 25 Feb 2013 08:15:21 -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 18A9521F94ED for ; Mon, 25 Feb 2013 08:15:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14216; q=dns/txt; s=iport; t=1361808913; x=1363018513; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=eySyP4BS6AsQ0Vh9xsRWzIEnpVx1fy8YiU/dx9DpsPY=; b=W1VwZJ/4IvSDdOuqR/YZd4/oRu05t56UKecdfyBDxMG8zxGEUSDsyTn7 afJzUf88p2p3IZuAiJ0F5W1CDEQDGt6UMkCGnnJYkQnabFyxELTMGysDw wVK3pc5hIoHT6pAw816LfljTz7WMGTvdTmHafo+7vdsZHtw2FIMrHYQOb A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AucFAOWMK1GtJXHB/2dsb2JhbABFgkOBNawUiSUBhliBS4EFFnOCHwEBAQQBAQEqQQkCDAQCAQgRBAEBCx0HIQYLFAkIAQEEDgUIAYd4Aw8HBbYXDYhxjDeBEAaBEA8XBwQGAQaCWWEDiDOKSYFkgnqKMYUXgTAigTWBaQIHFwYY X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; d="scan'208,217";a="180874663" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 25 Feb 2013 16:15:07 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r1PGF6YW005967 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Feb 2013 16:15:06 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.89]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 10:15:06 -0600 From: "Pascal Thubert (pthubert)" To: Abdussalam Baryun Thread-Topic: [Roll] New Version Notification for draft-thubert-roll-forwarding-frags-01.txt Thread-Index: Ac4TRt1lRn7yWP4fSC6poc/BQIBG4gAVKzQAAAouHuA= Date: Mon, 25 Feb 2013 16:15:05 +0000 Deferred-Delivery: Mon, 25 Feb 2013 16:15:00 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.88.253] Content-Type: multipart/alternative; boundary="_000_E045AECD98228444A58C61C200AE1BD835CCEAD8xmbrcdx01ciscoc_" MIME-Version: 1.0 Cc: "roll@ietf.org" Subject: Re: [Roll] New Version Notification for draft-thubert-roll-forwarding-frags-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, 25 Feb 2013 16:15:29 -0000 --_000_E045AECD98228444A58C61C200AE1BD835CCEAD8xmbrcdx01ciscoc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello Abdussalam, This used to be 6LoWPAN but the work never took off there (see the mail exc= hange with Carsten). The goal of the draft is to streamline fragments and retry individual frag = loss. It is useful if: - you have route over - but lack the 802.15.4g PHY. Cheers, Pascal From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] Sent: lundi 25 f=E9vrier 2013 16:03 To: Pascal Thubert (pthubert) Cc: roll@ietf.org Subject: Re: [Roll] New Version Notification for draft-thubert-roll-forward= ing-frags-01.txt Hi Pascal, I may need to discuss to know my interest, or to understand. Does this prot= ocol have interact with RPL or its information? The title is LLN forwarding= but the content is about 6LowPan, is this work better fitted in 6LoWPAN WG= than ROLL? AB On Mon, Feb 25, 2013 at 10:58 AM, Pascal Thubert (pthubert) > wrote: Dear WG: As you know well, 6LoWPAN will fragment packets that are too wide for the M= TU, which is likely to happen in a number of cases, unless the 802.15.4g MA= C is used. As a consequence, in a route-over RPL subnet, a large packet must be reasse= mbled at each hop to be routed and fragmented again. Streamlining the fragments will improve latency, and will save memory and C= PU in the intermediate nodes. This draft enables the forwarding of fragments, which selective acknowledge= ment and flow control capabilities, end to end over the LLN. Upon a private request, I resubmitted the draft with a simplification, that= is the removal of en encoding that would compress the acknowledgement bitm= ap. I also restored some text about Congestion notification, in order to valida= te the need with the group. Please let the authors know if you have interest in pursuing this work, Pascal -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: lundi 25 f=E9vrier 2013 11:42 To: Pascal Thubert (pthubert) Cc: Jonathan Hui (johui) Subject: New Version Notification for draft-thubert-roll-forwarding-frags-0= 1.txt A new version of I-D, draft-thubert-roll-forwarding-frags-01.txt has been successfully submitted by Pascal Thubert and posted to the IETF re= pository. Filename: draft-thubert-roll-forwarding-frags Revision: 01 Title: LLN Fragment Forwarding and Recovery Creation date: 2013-02-25 Group: Individual Submission Number of pages: 16 URL: http://www.ietf.org/internet-drafts/draft-thubert-roll-for= warding-frags-01.txt Status: http://datatracker.ietf.org/doc/draft-thubert-roll-forward= ing-frags Htmlized: http://tools.ietf.org/html/draft-thubert-roll-forwarding-f= rags-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-thubert-roll-forw= arding-frags-01 Abstract: In order to be routed, a fragmented packet must be reassembled at every hop of a multihop link where lower layer fragmentation occurs. Considering that the IPv6 minimum MTU is 1280 bytes and that an an 802.15.4 frame can have a payload limited to 74 bytes in the worst case, a packet might end up fragmented into as many as 18 fragments at the 6LoWPAN shim layer. If a single one of those fragments is lost in transmission, all fragments must be resent, further contributing to the congestion that might have caused the initial packet loss. This draft introduces a simple protocol to forward and recover individual fragments that might be lost over multiple hops between 6LoWPAN endpoints. The IETF Secretariat _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --_000_E045AECD98228444A58C61C200AE1BD835CCEAD8xmbrcdx01ciscoc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hello Abdussalam,

 <= /p>

This used to be 6LoWPAN b= ut the work never took off there (see the mail exchange with Carsten).=

The goal of the draft is = to streamline fragments and retry individual frag loss.

 <= /p>

It is useful if:

- you have route over

- but lack the 802.15.4g = PHY.

 <= /p>

Cheers,=

 <= /p>

Pascal<= /p>

 <= /p>

From: Abdussal= am Baryun [mailto:abdussalambaryun@gmail.com]
Sent: lundi 25 f=E9vrier 2013 16:03
To: Pascal Thubert (pthubert)
Cc: roll@ietf.org
Subject: Re: [Roll] New Version Notification for draft-thubert-roll-= forwarding-frags-01.txt

 

Hi Pascal,

 

I may need to discuss to know my interest, or t= o understand. Does this protocol have interact with RPL or its information?= The title is LLN forwarding but the content is about 6LowPan, is this= work better fitted in 6LoWPAN WG than ROLL?

 

AB

On Mon, Feb 25, 2013 at 10:58 AM, Pascal Thubert (pt= hubert) <pthuber= t@cisco.com> wrote:

Dear WG:

As you know well, 6LoWPAN will fragment packets that are too wide for the M= TU, which is likely to happen in a number of cases, unless the 802.15.4g MA= C is used.

As a consequence, in a route-over RPL subnet, a large packet must be reasse= mbled at each hop to be routed and fragmented again.

Streamlining the fragments will improve latency, and will save memory and C= PU in the intermediate nodes.

This draft enables the forwarding of fragments, which selective acknowledge= ment and flow control capabilities, end to end over the LLN.

Upon a private request, I resubmitted the draft with a simplification, that= is the removal of en encoding that would compress the acknowledgement bitm= ap.

I also restored some text about Congestion notification, in order to valida= te the need with the group.

Please let the authors know if you have interest in pursuing this work,

Pascal


-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: lundi 25 f=E9vrier 2013 11:42
To: Pascal Thubert (pthubert)
Cc: Jonathan Hui (johui)
Subject: New Version Notification for draft-thubert-roll-forwarding-frags-0= 1.txt


A new version of I-D, draft-thubert-roll-forwarding-frags-01.txt
has been successfully submitted by Pascal Thubert and posted to the IETF re= pository.

Filename:        draft-thubert-roll-forwarding-frags Revision:        01
Title:           LLN Fragment Forwarding and Recov= ery
Creation date:   2013-02-25
Group:           Individual Submission
Number of pages: 16
URL:             http://www.ietf.org/internet-drafts/draft-thubert-roll-forwarding-frags-01.= txt
Status:          http://dat= atracker.ietf.org/doc/draft-thubert-roll-forwarding-frags
Htmlized:        http://tools.ietf= .org/html/draft-thubert-roll-forwarding-frags-01
Diff:            http://www.ietf.org/rfcdiff?url2=3Ddraft-thubert-roll-forwarding-frags-01<= /a>

Abstract:
   In order to be routed, a fragmented packet must be reassembled= at
   every hop of a multihop link where lower layer fragmentation o= ccurs.
   Considering that the IPv6 minimum MTU is 1280 bytes and that a= n an
   802.15.4 frame can have a payload limited to 74 bytes in the w= orst
   case, a packet might end up fragmented into as many as 18 frag= ments
   at the 6LoWPAN shim layer.  If a single one of those frag= ments is
   lost in transmission, all fragments must be resent, further    contributing to the congestion that might have caused the init= ial
   packet loss.  This draft introduces a simple protocol to = forward and
   recover individual fragments that might be lost over multiple = hops
   between 6LoWPAN endpoints.




The IETF Secretariat

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

 

--_000_E045AECD98228444A58C61C200AE1BD835CCEAD8xmbrcdx01ciscoc_-- From internet-drafts@ietf.org Mon Feb 25 08:23: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 4E51A21F9514; Mon, 25 Feb 2013 08:23:16 -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 hA7R3cVJfR0F; Mon, 25 Feb 2013 08:23:15 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4931D21F950A; Mon, 25 Feb 2013 08:23:15 -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.40 Message-ID: <20130225162315.29854.22997.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 08:23:15 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-04.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, 25 Feb 2013 16:23: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-04.txt Pages : 31 Date : 2013-02-25 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-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-04 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From johui@cisco.com Mon Feb 25 08:28: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 B1D5521F92A2 for ; Mon, 25 Feb 2013 08:28:07 -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 06AU6u+z+7dN for ; Mon, 25 Feb 2013 08:28:07 -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 35ABF21F925F for ; Mon, 25 Feb 2013 08:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2423; q=dns/txt; s=iport; t=1361809683; x=1363019283; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=wow2VtnItiUkDznMd+jPsJAs5IW/QSFbDtY+dRpDv5w=; b=PnF/xW5vunxJWyMg/0wSysQTBklB3v+020kS4uzBGlZeJxkEPwT5gEJY YGvRbyzLqzZ2fghsdkrYaFj2zfCrv4O33HuBhghjhLdL6Wu/lc13pLOLA RE3D9GO6o1wLOGjgMaCyf56gJXoVj2vGuybhx4WCDQNlvV4vkd5EmlIKG U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFANCPK1GtJXG+/2dsb2JhbABFg3i9XYEFFnOCHwEBAQMBAQEBNzQbAgEIIhQQJwslAgQTCAGIBAYHBb8YjU6BDQI4gl9hA5daj0iDB4In X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; d="scan'208";a="180912594" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-3.cisco.com with ESMTP; 25 Feb 2013 16:27:55 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id r1PGRtWp019160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 25 Feb 2013 16:27:55 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.112]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 10:27:54 -0600 From: "Jonathan Hui (johui)" To: "roll@ietf.org WG" Thread-Topic: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-04.txt Thread-Index: AQHOE3UQqrS+pTpLUEu6qdW1GSbrsQ== Date: Mon, 25 Feb 2013 16:27:54 +0000 Message-ID: References: <20130225162315.29854.22997.idtracker@ietfa.amsl.com> In-Reply-To: <20130225162315.29854.22997.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.19] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Roll] I-D Action: draft-ietf-roll-trickle-mcast-04.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, 25 Feb 2013 16:28:07 -0000 Thanks again for the comments on draft-ietf-roll-trickle-mcast-03. draft-ietf-roll-trickle-mcast-04 addresses the following items: - Request ALL_MPL_FORWARDERS to have a multicast group ID in the range 0x01= -0xff to support 6LoWPAN compression. - Specify use of PROACTIVE_FORWARDING and SEED_SET_ENTRY_LIFETIME parameter= s. - Specify that an MPL Forwarder maintains a Seed Set and Buffered Message S= et for each MPL Domain. - Allow MPL Control Message to carry zero MPL Seed Info entries. - Allow IPv6 Source Address of MPL Control Messages to be global, allowing = the use of S=3D0. - Editorial changes. -- Jonathan Hui On Feb 25, 2013, at 8:23 AM, internet-drafts@ietf.org 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-04.txt > Pages : 31 > Date : 2013-02-25 >=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-04 >=20 > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-trickle-mcast-04 >=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 abdussalambaryun@gmail.com Mon Feb 25 08:28: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 E1E6221F94B9 for ; Mon, 25 Feb 2013 08:28:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=0.037, 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 aU9TGXZVKwRR for ; Mon, 25 Feb 2013 08:28:09 -0800 (PST) Received: from mail-pa0-f49.google.com (mail-pa0-f49.google.com [209.85.220.49]) by ietfa.amsl.com (Postfix) with ESMTP id 2C20421F927D for ; Mon, 25 Feb 2013 08:28:07 -0800 (PST) Received: by mail-pa0-f49.google.com with SMTP id kp6so1839100pab.36 for ; Mon, 25 Feb 2013 08:28:07 -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=tACcpQgeYFnzBFK5FZZjHX9nP7W5QS3DIjznH0BU1fE=; b=wWd1nBxaMYZa/z4OUAm1GJ2ZW3GfUEqIO8kpI2r11m9TqUZ89jP1MZCLi29Su7i2Pc HvsaNyRCaYcjiaDcRSqbRelLria2GCVQ9CRYANWwY+0xb+OnFz7GwzYbfsgf2L0GsqeM LBL43lKKq131LIw7+XgRb/oLeUng2iP/EaynKdhllDRCiVUoTG0ELetfZ/UDSKMDhjVp 72KYkrn3uSvMNpHOUn+L69Vznuhrn4sr+xmdQ8FHXxVYPPpKc84YE/ggHNzm1Y7ezxk0 8WiRTfO3Jgir2dWydqky9oxCX1V//RBn+6EB1PquDWHzQ5Sq3TQVT6w6xyVV5E/uNrCu pxMg== MIME-Version: 1.0 X-Received: by 10.68.217.2 with SMTP id ou2mr18983132pbc.6.1361809686961; Mon, 25 Feb 2013 08:28:06 -0800 (PST) Received: by 10.68.33.132 with HTTP; Mon, 25 Feb 2013 08:28:06 -0800 (PST) In-Reply-To: References: Date: Mon, 25 Feb 2013 16:28:06 +0000 Message-ID: From: Abdussalam Baryun To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=e89a8ff2430ba49f9604d68f0618 Cc: "roll@ietf.org" Subject: Re: [Roll] New Version Notification for draft-thubert-roll-forwarding-frags-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, 25 Feb 2013 16:28:10 -0000 --e89a8ff2430ba49f9604d68f0618 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Pascal, Yes, to make it for over-LLNs not only 6lowpan. I being interested now to read, I hope you don't mind if I ask another question while my read, that is my bad habit, thanks, AB On Mon, Feb 25, 2013 at 4:15 PM, Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hello Abdussalam,**** > > ** ** > > This used to be 6LoWPAN but the work never took off there (see the mail > exchange with Carsten).**** > > The goal of the draft is to streamline fragments and retry individual fra= g > loss. **** > > ** ** > > It is useful if:**** > > - you have route over**** > > - but lack the 802.15.4g PHY.**** > > ** ** > > Cheers,**** > > ** ** > > Pascal**** > > ** ** > > *From:* Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > *Sent:* lundi 25 f=E9vrier 2013 16:03 > *To:* Pascal Thubert (pthubert) > *Cc:* roll@ietf.org > *Subject:* Re: [Roll] New Version Notification for > draft-thubert-roll-forwarding-frags-01.txt**** > > ** ** > > Hi Pascal,**** > > **** > > I may need to discuss to know my interest, or to understand. Does this > protocol have interact with RPL or its information? The title is LLN > forwarding but the content is about 6LowPan, is this work better fitted i= n > 6LoWPAN WG than ROLL?**** > > **** > > AB**** > > On Mon, Feb 25, 2013 at 10:58 AM, Pascal Thubert (pthubert) < > pthubert@cisco.com> wrote:**** > > Dear WG: > > As you know well, 6LoWPAN will fragment packets that are too wide for the > MTU, which is likely to happen in a number of cases, unless the 802.15.4g > MAC is used. > > As a consequence, in a route-over RPL subnet, a large packet must be > reassembled at each hop to be routed and fragmented again. > > Streamlining the fragments will improve latency, and will save memory and > CPU in the intermediate nodes. > > This draft enables the forwarding of fragments, which selective > acknowledgement and flow control capabilities, end to end over the LLN. > > Upon a private request, I resubmitted the draft with a simplification, > that is the removal of en encoding that would compress the acknowledgemen= t > bitmap. > > I also restored some text about Congestion notification, in order to > validate the need with the group. > > Please let the authors know if you have interest in pursuing this work, > > Pascal > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: lundi 25 f=E9vrier 2013 11:42 > To: Pascal Thubert (pthubert) > Cc: Jonathan Hui (johui) > Subject: New Version Notification for > draft-thubert-roll-forwarding-frags-01.txt > > > A new version of I-D, draft-thubert-roll-forwarding-frags-01.txt > has been successfully submitted by Pascal Thubert and posted to the IETF > repository. > > Filename: draft-thubert-roll-forwarding-frags > Revision: 01 > Title: LLN Fragment Forwarding and Recovery > Creation date: 2013-02-25 > Group: Individual Submission > Number of pages: 16 > URL: > http://www.ietf.org/internet-drafts/draft-thubert-roll-forwarding-frags-0= 1.txt > Status: > http://datatracker.ietf.org/doc/draft-thubert-roll-forwarding-frags > Htmlized: > http://tools.ietf.org/html/draft-thubert-roll-forwarding-frags-01 > Diff: > http://www.ietf.org/rfcdiff?url2=3Ddraft-thubert-roll-forwarding-frags-01 > > Abstract: > In order to be routed, a fragmented packet must be reassembled at > every hop of a multihop link where lower layer fragmentation occurs. > Considering that the IPv6 minimum MTU is 1280 bytes and that an an > 802.15.4 frame can have a payload limited to 74 bytes in the worst > case, a packet might end up fragmented into as many as 18 fragments > at the 6LoWPAN shim layer. If a single one of those fragments is > lost in transmission, all fragments must be resent, further > contributing to the congestion that might have caused the initial > packet loss. This draft introduces a simple protocol to forward and > recover individual fragments that might be lost over multiple hops > between 6LoWPAN endpoints. > > > > > The IETF Secretariat > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll**** > > ** ** > --e89a8ff2430ba49f9604d68f0618 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Pascal,
=A0
Yes, to make it for over-LLNs not o= nly 6lowpan. I being interested now to read, I hope you don't mind if I= ask another question while my read, that is my bad habit, thanks,
=A0
AB

On Mon, Feb 25, 20= 13 at 4:15 PM, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:

Hello Abdussalam,=

=A0

This used to be 6LoW= PAN but the work never took off there (see the mail exchange with Carsten).=

The goal of the draf= t is to streamline fragments and retry individual frag loss.

=A0

It is useful if:<= /u>

- you have route ove= r

- but lack the 802.1= 5.4g PHY.

=A0

Cheers,

=A0

Pascal=

=A0

From: Abdussalam B= aryun [mailto:abdussalambaryun@gmail.com]
Sent: lundi 25 f=E9vrier 2013 16:03
To: Pascal Thubert (pthubert)
Cc: roll@ietf.org=
Subject: Re: [Roll] New Version Notification for draft-thubert-roll-= forwarding-frags-01.txt

=A0

Hi Pascal,

=A0

I may need to discuss to know my interest, or=A0to u= nderstand. Does this protocol have interact with RPL or its information? Th= e title is=A0LLN forwarding but the content is about 6LowPan, is this work = better fitted in 6LoWPAN WG than ROLL?

=A0

AB

On Mon, Feb 25, 2013 at 10:58 AM, Pascal Thubert (pt= hubert) <pthuber= t@cisco.com> wrote:

Dear WG:

As you know well, 6LoWPAN will fragment packets that are too wide for the M= TU, which is likely to happen in a number of cases, unless the 802.15.4g MA= C is used.

As a consequence, in a route-over RPL subnet, a large packet must be reasse= mbled at each hop to be routed and fragmented again.

Streamlining the fragments will improve latency, and will save memory and C= PU in the intermediate nodes.

This draft enables the forwarding of fragments, which selective acknowledge= ment and flow control capabilities, end to end over the LLN.

Upon a private request, I resubmitted the draft with a simplification, that= is the removal of en encoding that would compress the acknowledgement bitm= ap.

I also restored some text about Congestion notification, in order to valida= te the need with the group.

Please let the authors know if you have interest in pursuing this work,

Pascal


-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: lundi 25 f=E9vrier 2013 11:42
To: Pascal Thubert (pthubert)
Cc: Jonathan Hui (johui)
Subject: New Version Notification for draft-thubert-roll-forwarding-frags-0= 1.txt


A new version of I-D, draft-thubert-roll-forwarding-frags-01.txt
has been successfully submitted by Pascal Thubert and posted to the IETF re= pository.

Filename: =A0 =A0 =A0 =A0draft-thubert-roll-forwarding-frags
Revision: =A0 =A0 =A0 =A001
Title: =A0 =A0 =A0 =A0 =A0 LLN Fragment Forwarding and Recovery
Creation date: =A0 2013-02-25
Group: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 16
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-thubert-roll-forwarding-frags-01.= txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.o= rg/doc/draft-thubert-roll-forwarding-frags
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/dr= aft-thubert-roll-forwarding-frags-01
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.o= rg/rfcdiff?url2=3Ddraft-thubert-roll-forwarding-frags-01

Abstract:
=A0 =A0In order to be routed, a fragmented packet must be reassembled at =A0 =A0every hop of a multihop link where lower layer fragmentation occurs.=
=A0 =A0Considering that the IPv6 minimum MTU is 1280 bytes and that an an =A0 =A0802.15.4 frame can have a payload limited to 74 bytes in the worst =A0 =A0case, a packet might end up fragmented into as many as 18 fragments<= br> =A0 =A0at the 6LoWPAN shim layer. =A0If a single one of those fragments is<= br> =A0 =A0lost in transmission, all fragments must be resent, further
=A0 =A0contributing to the congestion that might have caused the initial =A0 =A0packet loss. =A0This draft introduces a simple protocol to forward a= nd
=A0 =A0recover individual fragments that might be lost over multiple hops =A0 =A0between 6LoWPAN endpoints.




The IETF Secretariat

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

=A0


--e89a8ff2430ba49f9604d68f0618-- From internet-drafts@ietf.org Mon Feb 25 08:31:08 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 9DC0621F9580; Mon, 25 Feb 2013 08:31:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 EA8z7teno8MS; Mon, 25 Feb 2013 08:31:08 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52DE21F9584; Mon, 25 Feb 2013 08:31:06 -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.40 Message-ID: <20130225163106.8563.88871.idtracker@ietfa.amsl.com> Date: Mon, 25 Feb 2013 08:31:06 -0800 Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-security-threats-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, 25 Feb 2013 16:31:09 -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 Security Threat Analysis for Routing over Low-Power an= d Lossy Networks Author(s) : Tzeta Tsao Roger K. Alexander Mischa Dohler Vanesa Daza Angel Lozano Filename : draft-ietf-roll-security-threats-01.txt Pages : 47 Date : 2013-02-25 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 IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-security-threats There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-roll-security-threats-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-security-threats-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From prvs=7611827c3=Tzeta.Tsao@cooperindustries.com Mon Feb 25 08:40:06 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 3DA6C21F9552 for ; Mon, 25 Feb 2013 08:40:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqSweIcaYT6g for ; Mon, 25 Feb 2013 08:40:05 -0800 (PST) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by ietfa.amsl.com (Postfix) with ESMTP id B250C21F9550 for ; Mon, 25 Feb 2013 08:40:05 -0800 (PST) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.84,735,1355115600"; d="scan'208,217";a="89346550" Received: from cipt0174.nam.ci.root ([10.132.108.174]) by cooperlighting-sw.cooperlighting.com with ESMTP; 25 Feb 2013 11:40:05 -0500 Received: from EVS2.NAM.CI.ROOT ([10.132.108.170]) by cipt0174.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Feb 2013 11:40:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CE1376.C39633BD" Date: Mon, 25 Feb 2013 11:40:04 -0500 Message-ID: <85A23E0910B2FB4B8EF60D0888CB0836024C0B9A@EVS2.nam.ci.root> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revision of Security Threat Analysis Draft Thread-Index: Ac4Tdd0JAEvURhkjQ+qkF8iJnK8bdwAANmHw From: "Tsao, Tzeta" To: X-OriginalArrivalTime: 25 Feb 2013 16:40:05.0614 (UTC) FILETIME=[C40650E0:01CE1376] Subject: [Roll] Revision of Security Threat Analysis Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Feb 2013 16:40:06 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CE1376.C39633BD Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable WG, =20 We have uploaded a revision in response to comments from the Routing Area Directorate and Gen-ART. Comments from the Security Directorate and Operations Directorate, as a whole, may have implications of requiring changes in the draft's structure, and are yet to be addressed. One proposal is to remove Section 6. We will keep working on the unresolved issues and welcome any input. =20 Thanks, Tzeta ------_=_NextPart_001_01CE1376.C39633BD Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

WG,

 

We have uploaded a revision in response to = comments from the Routing Area Directorate and Gen-ART. Comments from = the Security Directorate and Operations Directorate, as a whole, may = have implications of requiring changes in the draft's structure, and are = yet to be addressed. One proposal is to remove Section 6. We will keep = working on the unresolved issues and welcome any input.

 

Thanks,

Tzeta

------_=_NextPart_001_01CE1376.C39633BD-- From abdussalambaryun@gmail.com Mon Feb 25 08:45: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 9F0DC21F9521 for ; Mon, 25 Feb 2013 08:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=0.036, 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 xH+lm6obZI0j for ; Mon, 25 Feb 2013 08:45:38 -0800 (PST) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) by ietfa.amsl.com (Postfix) with ESMTP id 28EBF21F94ED for ; Mon, 25 Feb 2013 08:45:38 -0800 (PST) Received: by mail-pb0-f49.google.com with SMTP id xa12so1745582pbc.8 for ; Mon, 25 Feb 2013 08:45: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=18vBwqg6HFeVtdS3cW3/iBEN6YmBg402QF2g9zMmMa4=; b=wfPIfR9JVoYefqlXu/cthmJt1S91/9tQTBdJSSLpPagzlWxYpaOSPdn2nntsngJ1no DVjaV22na7nnzQY+u8PZ0joJSHzXmJMDes8XBVmlm2lyq1JHBBNDXQwCfMqjt6vdDd6r X/hNT3/dXVnzfhayoKkdlasXZvcjR1EJK7g2kskodC9RTfjZSRn0AUvMnbeP0qI9yh0M YBaQOsYSQJUboNqH82s6ZxuIBrsQuBnKHPuojioquDQRDABnkg4GyZ0fqdQEdllLUScA Jz6jlr4H9c8ISm7malElSr9no+kaqJLF+P0T/5Sbj+XU2u4HlumhZvw2cRUklGXt5xKZ 1RIA== MIME-Version: 1.0 X-Received: by 10.68.245.229 with SMTP id xr5mr18843805pbc.163.1361810737980; Mon, 25 Feb 2013 08:45:37 -0800 (PST) Received: by 10.68.33.132 with HTTP; Mon, 25 Feb 2013 08:45:37 -0800 (PST) In-Reply-To: <85A23E0910B2FB4B8EF60D0888CB0836024C0B9A@EVS2.nam.ci.root> References: <85A23E0910B2FB4B8EF60D0888CB0836024C0B9A@EVS2.nam.ci.root> Date: Mon, 25 Feb 2013 16:45:37 +0000 Message-ID: From: Abdussalam Baryun To: "Tsao, Tzeta" Content-Type: multipart/alternative; boundary=047d7b2e155d49e52d04d68f4567 Cc: roll@ietf.org Subject: Re: [Roll] Revision of Security Threat Analysis Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Feb 2013 16:45:38 -0000 --047d7b2e155d49e52d04d68f4567 Content-Type: text/plain; charset=ISO-8859-1 do you mean draft-ietf-roll-security-threats-01.txt, please point to the name of the draft, sorry I am getting carzy, AB On Mon, Feb 25, 2013 at 4:40 PM, Tsao, Tzeta < Tzeta.Tsao@cooperindustries.com> wrote: > WG,**** > > ** ** > > We have uploaded a revision in response to comments from the Routing Area > Directorate and Gen-ART. Comments from the Security Directorate and > Operations Directorate, as a whole, may have implications of requiring > changes in the draft's structure, and are yet to be addressed. One proposal > is to remove Section 6. We will keep working on the unresolved issues and > welcome any input.**** > > ** ** > > Thanks,**** > > Tzeta**** > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > > --047d7b2e155d49e52d04d68f4567 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
do you mean draft-ietf-roll-security-threats-01.txt, please point to t= he name of the draft, sorry I am getting carzy,
=A0
AB<= br>
On Mon, Feb 25, 2013 at 4:40 PM, Ts= ao, Tzeta <Tzeta.Tsao@cooperindustries.com> wr= ote:
WG,

=A0

We have uploaded a revision in response to comments from the= Routing Area Directorate and Gen-ART. Comments from the Security Directora= te and Operations Directorate, as a whole, may have implications of requiri= ng changes in the draft's structure, and are yet to be addressed. One p= roposal is to remove Section 6. We will keep working on the unresolved issu= es and welcome any input.

=A0

Thanks,<= u>

Tzeta

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


--047d7b2e155d49e52d04d68f4567-- From prvs=7611827c3=Tzeta.Tsao@cooperindustries.com Mon Feb 25 08:50: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 7E9D321F94B2 for ; Mon, 25 Feb 2013 08:50:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LffWbrvEx8x9 for ; Mon, 25 Feb 2013 08:50:13 -0800 (PST) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by ietfa.amsl.com (Postfix) with ESMTP id 59BD221F903C for ; Mon, 25 Feb 2013 08:50:13 -0800 (PST) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.84,735,1355115600"; d="scan'208,217";a="89349008" Received: from cipt0175.nam.ci.root ([10.132.108.175]) by cooperlighting-sw.cooperlighting.com with ESMTP; 25 Feb 2013 11:50:08 -0500 Received: from EVS2.NAM.CI.ROOT ([10.132.108.170]) by cipt0175.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Feb 2013 11:50:07 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CE1378.2ABCC41D" Date: Mon, 25 Feb 2013 11:50:07 -0500 Message-ID: <85A23E0910B2FB4B8EF60D0888CB0836024C0BBD@EVS2.nam.ci.root> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Revision of Security Threat Analysis Draft Thread-Index: Ac4Td4zTH7Jm2NTDSmawW0kjtOGrrgAAFo5A References: <85A23E0910B2FB4B8EF60D0888CB0836024C0B9A@EVS2.nam.ci.root> From: "Tsao, Tzeta" To: "Abdussalam Baryun" X-OriginalArrivalTime: 25 Feb 2013 16:50:07.0827 (UTC) FILETIME=[2AF8BA30:01CE1378] Cc: roll@ietf.org Subject: Re: [Roll] Revision of Security Threat Analysis Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Feb 2013 16:50:14 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CE1378.2ABCC41D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yes. http://www.ietf.org/internet-drafts/draft-ietf-roll-security-threats-01. txt =20 Thanks, Tzeta =20 From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]=20 Sent: Monday, February 25, 2013 11:46 AM To: Tsao, Tzeta Cc: roll@ietf.org Subject: Re: [Roll] Revision of Security Threat Analysis Draft =20 do you mean draft-ietf-roll-security-threats-01.txt, please point to the name of the draft, sorry I am getting carzy, =20 =20 =20 AB On Mon, Feb 25, 2013 at 4:40 PM, Tsao, Tzeta wrote: WG, =20 We have uploaded a revision in response to comments from the Routing Area Directorate and Gen-ART. Comments from the Security Directorate and Operations Directorate, as a whole, may have implications of requiring changes in the draft's structure, and are yet to be addressed. One proposal is to remove Section 6. We will keep working on the unresolved issues and welcome any input. =20 Thanks, Tzeta _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 ------_=_NextPart_001_01CE1378.2ABCC41D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Yes. http://www.ietf.org/internet-drafts/draft-ietf-roll-security-= threats-01.txt

 

Thanks,

Tzeta

 

From:= = Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: = Monday, February 25, 2013 11:46 AM
To: Tsao, = Tzeta
Cc: roll@ietf.org
Subject: Re: [Roll] Revision = of Security Threat Analysis Draft

 

do you = mean draft-ietf-roll-security-threats-01.txt, please point to the name = of the draft, sorry I am getting carzy,

 

 

 

AB

On Mon, Feb 25, 2013 at 4:40 PM, Tsao, Tzeta <Tzeta.Tsao@cooperindustries.com> = wrote:

WG,

 <= /o:p>

We have = uploaded a revision in response to comments from the Routing Area = Directorate and Gen-ART. Comments from the Security Directorate and = Operations Directorate, as a whole, may have implications of requiring = changes in the draft's structure, and are yet to be addressed. One = proposal is to remove Section 6. We will keep working on the unresolved = issues and welcome any input.

 <= /o:p>

Thanks,=

Tzeta


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

 

------_=_NextPart_001_01CE1378.2ABCC41D-- From svshah@cisco.com Mon Feb 25 08:55:59 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 9454F21F953B; Mon, 25 Feb 2013 08:55:59 -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 hlYW-b47-IMU; Mon, 25 Feb 2013 08:55:58 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 9552321F9525; Mon, 25 Feb 2013 08:55:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2389; q=dns/txt; s=iport; t=1361811358; x=1363020958; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=ei6PXThpTNhDEpztQ47tLTW31+HvckfjvaaxdonEM+U=; b=Ky9J3VyH4M1jeBID8WtJvIsFLhvwnXan6s0Km7U5Z2sE7LstCYw7a/// LOUTImcauE30Tk1DY9+0CcN/GpqOcPVzSMS0FOoPDIZtNzNQy4b7ZMzIp ssRrb9CsMuzUEcNIHz4f1V3TAK4jEeRUt6HLQ+EnlF0CB4zD0rnjM5+Sk 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgAFAHaWK1GtJXHA/2dsb2JhbABFwVWBBRZzgh8BAQEEOj0UAQgSEBRCFwQBBgMCBAESCAGICgy/L41OgQ84gl9hA5JChRiPSIFSgTWCJw X-IronPort-AV: E=Sophos;i="4.84,735,1355097600"; d="scan'208";a="180895511" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-6.cisco.com with ESMTP; 25 Feb 2013 16:55:58 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r1PGtw00003717 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 25 Feb 2013 16:55:58 GMT Received: from xmb-aln-x10.cisco.com ([169.254.5.82]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Mon, 25 Feb 2013 10:55:57 -0600 From: "Shitanshu Shah (svshah)" To: "tsvwg@ietf.org" , "roll@ietf.org" , "6tsch@ietf.org" <6tsch@ietf.org> Thread-Topic: New Version Notification for draft-svshah-tsvwg-lln-diffserv-recommendations-00.txt Thread-Index: AQHOE3j7e3DE7qiuzkW77qu/KD41hw== Date: Mon, 25 Feb 2013 16:55:57 +0000 Message-ID: In-Reply-To: <20130218052624.23876.72337.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.1.130117 x-originating-ip: [10.21.70.77] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [Roll] FW: New Version Notification for draft-svshah-tsvwg-lln-diffserv-recommendations-00.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2013 16:55:59 -0000 Hi, Below is a revised version under re-named I-D, as was suggested by tsvwg chairs to have tsvwg in the draft name. Previous revision:=20 http://www.ietf.org/id/draft-svshah-lln-diffserv-recommendations-01.txt One of the discussion points in the last meeting, at Atlanta, was if to retain one of the existing code-point for Deterministic service class or define explicit one. Current revision, retains use of EF code-point for this service, anticipating mutually exclusive presence of Voice vs Deterministic class of traffic. However, PHB definition for this LLN class of traffic is more than just low latency (a definition used in classic networks). This has been highlighted in the draft. Any comments much appreciated.. Regards, Shitanshu On 2/17/13 9:26 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, >draft-svshah-tsvwg-lln-diffserv-recommendations-00.txt >has been successfully submitted by Shitanshu Shah and posted to the >IETF repository. > >Filename: draft-svshah-tsvwg-lln-diffserv-recommendations >Revision: 00 >Title: Differentiated Service Class Recommendations for LLN Traffic >Creation date: 2013-02-18 >Group: Individual Submission >Number of pages: 15 >URL: =20 >http://www.ietf.org/internet-drafts/draft-svshah-tsvwg-lln-diffserv-recomm >endations-00.txt >Status: =20 >http://datatracker.ietf.org/doc/draft-svshah-tsvwg-lln-diffserv-recommenda >tions >Htmlized: =20 >http://tools.ietf.org/html/draft-svshah-tsvwg-lln-diffserv-recommendations >-00 > > >Abstract: > Differentiated services architecture is widely deployed in > traditional networks. There exist well defined recommendations for > the use of appropriate differentiated service classes for different > types of traffic (eg. audio, video) in these networks. Per-Hop > Behaviors are typically defined based on this recommendations. With > emerging Low-power and Lossy Networks (LLNs), it is important to have > similar defined differentiated services recommendations for LLN > traffic. Defined recommendations are for LLN class of traffic > exiting out of LLNs towards high-speed backbones, converged campus > network and for the traffic in the reverse direction. > > =20 > =20 > > >The IETF Secretariat > From abdussalambaryun@gmail.com Mon Feb 25 08:59: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 9514A21F9546 for ; Mon, 25 Feb 2013 08:59:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=0.035, 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 uG1mPr876Ml6 for ; Mon, 25 Feb 2013 08:59:02 -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 3C86121F94D1 for ; Mon, 25 Feb 2013 08:59:01 -0800 (PST) Received: by mail-pa0-f50.google.com with SMTP id fa11so1854104pad.37 for ; Mon, 25 Feb 2013 08:59: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=+0PWQW5kAMD+gaByvCDp5v+R1U3F7vOGKnnguK5Vd3Y=; b=DsU4CQRhiGxdW4N90fY+EYDVmvzxubygoWPumNvY0LcUTdCFFR+Pd2bXRtXs12a5tn dAvT6ccvucEg/CqvEMRfc8Du5DW08VNEmSJkrAFH2Au9SP0sQwAZ50Xn/dGZt1KqZ1Rp twmCVUx/AS7Yo9Aem49ygbc8j0Bf7f3TvXf6VmnPky4o0xiieYevUk3zc/34gq/1WtGH 5qIBr3axVqR3zoMr4gG02V6kPi9Q6z1v2PhSU2TaMGVuF3CsNmTgWd6DSLvGCj1RrNk6 vUuJdw/3RDaRizqHDx0C7fAg/Nq0GtQzKP6JQDpTDGqUwBG+yTf9BOtd7/MsS5lUHuHE QqLg== MIME-Version: 1.0 X-Received: by 10.68.245.229 with SMTP id xr5mr18909105pbc.163.1361811541003; Mon, 25 Feb 2013 08:59:01 -0800 (PST) Received: by 10.68.33.132 with HTTP; Mon, 25 Feb 2013 08:59:00 -0800 (PST) In-Reply-To: <85A23E0910B2FB4B8EF60D0888CB0836024C0BBD@EVS2.nam.ci.root> References: <85A23E0910B2FB4B8EF60D0888CB0836024C0B9A@EVS2.nam.ci.root> <85A23E0910B2FB4B8EF60D0888CB0836024C0BBD@EVS2.nam.ci.root> Date: Mon, 25 Feb 2013 16:59:00 +0000 Message-ID: From: Abdussalam Baryun To: "Tsao, Tzeta" Content-Type: multipart/alternative; boundary=047d7b2e155d270ba104d68f7545 Cc: roll@ietf.org Subject: Re: [Roll] Revision of Security Threat Analysis Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Feb 2013 16:59:02 -0000 --047d7b2e155d270ba104d68f7545 Content-Type: text/plain; charset=ISO-8859-1 Hi Tzeta, I don't know what were the comments of such reviews, so I cannot know where the work is going, it is not reasonable to change the structure as long as the WG has agreed on it, however, I agree to delete section 6 AB On Mon, Feb 25, 2013 at 4:50 PM, Tsao, Tzeta < Tzeta.Tsao@cooperindustries.com> wrote: > Yes. > http://www.ietf.org/internet-drafts/draft-ietf-roll-security-threats-01.txt > **** > > ** ** > > Thanks,**** > > Tzeta**** > > ** ** > > *From:* Abdussalam Baryun [mailto:abdussalambaryun@gmail.com] > *Sent:* Monday, February 25, 2013 11:46 AM > *To:* Tsao, Tzeta > *Cc:* roll@ietf.org > *Subject:* Re: [Roll] Revision of Security Threat Analysis Draft**** > > ** ** > > do you mean draft-ietf-roll-security-threats-01.txt, please point to the > name of the draft, sorry I am getting carzy,**** > > ** ** > > ** ** > > **** > > AB**** > > On Mon, Feb 25, 2013 at 4:40 PM, Tsao, Tzeta < > Tzeta.Tsao@cooperindustries.com> wrote:**** > > WG,**** > > **** > > We have uploaded a revision in response to comments from the Routing Area > Directorate and Gen-ART. Comments from the Security Directorate and > Operations Directorate, as a whole, may have implications of requiring > changes in the draft's structure, and are yet to be addressed. One proposal > is to remove Section 6. We will keep working on the unresolved issues and > welcome any input.**** > > **** > > Thanks,**** > > Tzeta**** > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll**** > > ** ** > --047d7b2e155d270ba104d68f7545 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Tzeta,
=A0
I don't know what were the comme= nts of such reviews, so I cannot know where the work is going, it is not re= asonable=A0to change the structure as long as the WG has agreed on it, howe= ver, I agree to delete section 6
=A0
AB

On Mon, Feb 2= 5, 2013 at 4:50 PM, Tsao, Tzeta <Tzeta.Tsao@cooperindustries= .com> wrote:
Yes. = http://www.ietf.org/internet-drafts/draft-ietf-roll-security-threats-01.txt=

=A0

Thanks,<= u>

Tzeta

=A0

From: Abduss= alam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: Monday, February 25, 2013 11:46 AM
To: Tsao, TzetaCc: roll@ietf.o= rg
Subject: Re: [Roll] Revision of Security Threat Analysis D= raft

=A0=

do you mean draft-ietf-roll-security-threat= s-01.txt, please point to the name of the draft, sorry I am getting carzy,<= u>

=A0

=A0

=A0

AB

=

On Mon, Feb 25, 2013 at 4:40 PM, Tsao, Tzeta <Tzeta.Tsa= o@cooperindustries.com> wrote:

WG,

=A0

We have uploaded a revision i= n response to comments from the Routing Area Directorate and Gen-ART. Comme= nts from the Security Directorate and Operations Directorate, as a whole, m= ay have implications of requiring changes in the draft's structure, and= are yet to be addressed. One proposal is to remove Section 6. We will keep= working on the unresolved issues and welcome any input.

=A0

Thanks,<= u>

Tzeta

=


___________________= ____________________________
Roll mailing list
Rol= l@ietf.org
https://www.ietf.org/mailman/listinfo/roll

=A0

<= /div>

--047d7b2e155d270ba104d68f7545-- From prvs=7611827c3=Tzeta.Tsao@cooperindustries.com Mon Feb 25 09:03: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 1BC6521F94EE for ; Mon, 25 Feb 2013 09:03:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jRrcD7hw9aET for ; Mon, 25 Feb 2013 09:03:02 -0800 (PST) Received: from cooperlighting-sw.cooperlighting.com (cooperlighting-sw.cooperlighting.com [216.130.131.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFEC21F94B9 for ; Mon, 25 Feb 2013 09:03:02 -0800 (PST) Authentication-Results: cooperlighting-sw.cooperlighting.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.84,735,1355115600"; d="scan'208,217";a="89351961" Received: from cipt0175.nam.ci.root ([10.132.108.175]) by cooperlighting-sw.cooperlighting.com with ESMTP; 25 Feb 2013 12:03:01 -0500 Received: from EVS2.NAM.CI.ROOT ([10.132.108.170]) by cipt0175.NAM.CI.ROOT with Microsoft SMTPSVC(6.0.3790.4675); Mon, 25 Feb 2013 12:03:00 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CE1379.F7833B7D" Date: Mon, 25 Feb 2013 12:03:00 -0500 Message-ID: <85A23E0910B2FB4B8EF60D0888CB0836024C0BED@EVS2.nam.ci.root> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Roll] Revision of Security Threat Analysis Draft Thread-Index: Ac4TeWlu6/cm1sZwRrWc7Fu8DnfYAgAAEjtw References: <85A23E0910B2FB4B8EF60D0888CB0836024C0B9A@EVS2.nam.ci.root><85A23E0910B2FB4B8EF60D0888CB0836024C0BBD@EVS2.nam.ci.root> From: "Tsao, Tzeta" To: "Abdussalam Baryun" X-OriginalArrivalTime: 25 Feb 2013 17:03:00.0999 (UTC) FILETIME=[F7D16970:01CE1379] Cc: roll@ietf.org Subject: Re: [Roll] Revision of Security Threat Analysis Draft X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Feb 2013 17:03:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CE1379.F7833B7D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Abdussalam, =20 We will keep that in mind. =20 Thanks, Tzeta =20 From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]=20 Sent: Monday, February 25, 2013 11:59 AM To: Tsao, Tzeta Cc: roll@ietf.org Subject: Re: [Roll] Revision of Security Threat Analysis Draft =20 Hi Tzeta, =20 I don't know what were the comments of such reviews, so I cannot know where the work is going, it is not reasonable to change the structure as long as the WG has agreed on it, however, I agree to delete section 6 =20 AB On Mon, Feb 25, 2013 at 4:50 PM, Tsao, Tzeta wrote: Yes. http://www.ietf.org/internet-drafts/draft-ietf-roll-security-threats-01. txt =20 Thanks, Tzeta =20 From: Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]=20 Sent: Monday, February 25, 2013 11:46 AM To: Tsao, Tzeta Cc: roll@ietf.org Subject: Re: [Roll] Revision of Security Threat Analysis Draft =20 do you mean draft-ietf-roll-security-threats-01.txt, please point to the name of the draft, sorry I am getting carzy, =20 =20 =20 AB On Mon, Feb 25, 2013 at 4:40 PM, Tsao, Tzeta wrote: WG, =20 We have uploaded a revision in response to comments from the Routing Area Directorate and Gen-ART. Comments from the Security Directorate and Operations Directorate, as a whole, may have implications of requiring changes in the draft's structure, and are yet to be addressed. One proposal is to remove Section 6. We will keep working on the unresolved issues and welcome any input. =20 Thanks, Tzeta _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll =20 =20 ------_=_NextPart_001_01CE1379.F7833B7D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Abdussalam,

 

We will keep that in mind.

 

Thanks,

Tzeta

 

From:= = Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: = Monday, February 25, 2013 11:59 AM
To: Tsao, = Tzeta
Cc: roll@ietf.org
Subject: Re: [Roll] Revision = of Security Threat Analysis Draft

 

Hi = Tzeta,

 

I = don't know what were the comments of such reviews, so I cannot know = where the work is going, it is not reasonable to change the = structure as long as the WG has agreed on it, however, I agree to delete = section 6

 

AB

On Mon, Feb 25, 2013 at 4:50 PM, Tsao, Tzeta <Tzeta.Tsao@cooperindustries.com> = wrote:

Yes. http://www.ietf.org/internet-drafts/draft-ietf-roll-sec= urity-threats-01.txt

 <= /o:p>

Thanks,=

Tzeta

 <= /o:p>

From:= = Abdussalam Baryun [mailto:abdussalambaryun@gmail.com]
Sent: = Monday, February 25, 2013 11:46 AM
To: Tsao, = Tzeta
Cc: roll@ietf.org
Subject: Re: [Roll] = Revision of Security Threat Analysis = Draft

 <= /o:p>

do you mean = draft-ietf-roll-security-threats-01.txt, please point to the name of the = draft, sorry I am getting carzy,

 

 

 <= /o:p>

AB

<= /div>

On Mon, Feb = 25, 2013 at 4:40 PM, Tsao, Tzeta <Tzeta.Tsao@cooperindustries.com> = wrote:

WG,

 <= /o:p>

We have = uploaded a revision in response to comments from the Routing Area = Directorate and Gen-ART. Comments from the Security Directorate and = Operations Directorate, as a whole, may have implications of requiring = changes in the draft's structure, and are yet to be addressed. One = proposal is to remove Section 6. We will keep working on the unresolved = issues and welcome any input.

 <= /o:p>

Thanks,=

Tzeta


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

 <= /o:p>

 

------_=_NextPart_001_01CE1379.F7833B7D-- From mcr@sandelman.ca Mon Feb 25 14:11: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 84AB821E80E0 for ; Mon, 25 Feb 2013 14:11:53 -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 m-5PR93PAhPD for ; Mon, 25 Feb 2013 14:11:53 -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 E060A21E80EE for ; Mon, 25 Feb 2013 14:11:52 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id F35F62016F for ; Mon, 25 Feb 2013 17:18:52 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id B4EE06388D; Mon, 25 Feb 2013 17:10:37 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id A4FA463769 for ; Mon, 25 Feb 2013 17:10:37 -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] slides for IETF86 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 25 Feb 2013 22:11:53 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable If you intend to say something, I'd like to have any slides you might need to use ASAP. AUTHORS OF DOCUMENTS: a list of issues to discuss would be useful. While there is a growing IETF custom that the meetings are for discussion and not for presentations, the slides help remote participants follow the *discussion* better and be better prepared. If I don't have slides from you, then it means you did not really want to talk. I will be preparing a master slide deck. =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) iQCVAwUAUSvhXYqHRg3pndX9AQK1rgP/bVGnRW3lIUY+s4zrvqdusMbQm4daHqqU bxUKC6Wzc4wsgR9Cvt4OIqR/5SanaYnzR6cqM17W/w4aWF+MvoAYCfHX8z+Z/zld 5dAQ+uWumRdnIavYckYXX9zd1DIFFlHyU7myXDCvwTx/OjH88vJ9IU2KEQCZLjtq EqXL+ecBFXs= =y5Y1 -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Feb 28 10:43: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 3AA9321F8967 for ; Thu, 28 Feb 2013 10:43:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.587 X-Spam-Level: X-Spam-Status: No, score=-2.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 h++cb806k3kH for ; Thu, 28 Feb 2013 10:43:39 -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 9BED121F8922 for ; Thu, 28 Feb 2013 10:43:39 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 9547820168 for ; Thu, 28 Feb 2013 13:50:53 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 5B68510473; Thu, 28 Feb 2013 13:42:27 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 4CBA320049 for ; Thu, 28 Feb 2013 13:42:27 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <16172.1361386696@sandelman.ca> References: <16172.1361386696@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] WG call to adopt draft-brandt-roll-rpl-applicability-home-building-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: Thu, 28 Feb 2013 18:43:40 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable This thread is at http://www.ietf.org/mail-archive/web/roll/current/msg0775= 4.html had 20 messages from 7 participants. All seemed interested in this work and a number of substantive questions were asked about how ROLL it is to used in the home, for instance, about how address assignment will be done in the home/building context. No participant express a view that the document was an inappropriate start, or that it was out of scope for the working group. The view is the chairs is to adopt the document. If the authors could repost it as draft-ietf-roll-applicability-home-building-00 on March 11, when the ID=20 site reopens. =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) iQCVAwUAUS+lE4qHRg3pndX9AQI2GwP/UVpM6OaXvisbKHs1CNfrgwbHY5/Gpx1f xoC5343zgqP/C2Y6fTxOa+b9SFrkt9NjDoUaKhvh6u76sRthno6TUkk14PItfLPQ nCfl63tt3K4UNTdXWF43cxMGzc1LLkOUmNWD+RrCWD2iueKWNNdPUhTbfbMN5YSk fP+I41St80g= =8BZk -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Feb 28 10:44: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 6326421F8804 for ; Thu, 28 Feb 2013 10:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[AWL=0.011, 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 TOM2axv6aJV1 for ; Thu, 28 Feb 2013 10:44:19 -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 CA0F221F87B9 for ; Thu, 28 Feb 2013 10:44:18 -0800 (PST) Received: from sandelman.ca (desk.marajade.sandelman.ca [209.87.252.247]) by tuna.sandelman.ca (Postfix) with ESMTP id 101CE20168 for ; Thu, 28 Feb 2013 13:51:30 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id CCCCA10473; Thu, 28 Feb 2013 13:43:03 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id BD2B820049 for ; Thu, 28 Feb 2013 13:43:03 -0500 (EST) From: Michael Richardson To: roll@ietf.org In-Reply-To: <17078.1361386986@sandelman.ca> References: <17078.1361386986@sandelman.ca> X-Mailer: MH-E 8.3; nmh 1.3-dev; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Date: Thu, 28 Feb 2013 13:43:03 -0500 Message-ID: <20285.1362076983@sandelman.ca> Sender: mcr@sandelman.ca Subject: Re: [Roll] WG call to adopt draft-phinney-roll-rpl-industrial-applicability-01 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Feb 2013 18:44:19 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable This thread is at http://www.ietf.org/mail-archive/web/roll/current/msg0775= 5.html had only 1 message which was a +1. There were no objections. In addition to being announced in this WG, this document was also brought up in the 6tsch mailing list, which is looking at deterministic mechanisms that may be required by industrial applications. As no participant express a view that the document was an inappropriate start, or that it was out of scope for the working group. The view of the chairs is to adopt the document. If the authors could repost it as draft-ietf-roll-applicability-industrial-00 on March 11, when the ID=20 site reopens. =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) iQCVAwUAUS+lN4qHRg3pndX9AQJfsQP+Kp6qIxjtG3An/H+k8G61ic3IytVGpE35 iCKo09nh7oR1fJlSNrtLiJvtMgWYJ+9Pif6pZ9GBx0LRCQIFL/42eUzN0qZoeohu 0CKt4zQcGRRcnelyFLKnDJIkrOqjMGJJsCCY0yyNGMSZ6gtXNqg2RFragO2NsNM/ Jw5RgM5XIUE= =tPhU -----END PGP SIGNATURE----- --=-=-=-- From mcr@sandelman.ca Thu Feb 28 10:44: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 E54D821F8793 for ; Thu, 28 Feb 2013 10:44: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 NrjdOXwzUsHT for ; Thu, 28 Feb 2013 10:44:47 -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 E1EBE21F87CC for ; Thu, 28 Feb 2013 10:44:46 -0800 (PST) Received: from sandelman.ca (unknown [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 5FD4B20168; Thu, 28 Feb 2013 13:52:01 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 27EEE10473; Thu, 28 Feb 2013 13:43:35 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 1811620049; Thu, 28 Feb 2013 13:43:35 -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 Cc: draft-phinney-roll-rpl-industrial-applicability@tools.ietf.org Subject: [Roll] comments on draft-phinney-roll-rpl-industrial-applicability X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.12 Precedence: 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, 28 Feb 2013 18:44:48 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable {this email was written in several sittings over 10 days. Probably I missed some stuff} Section 1.3 says: 1.3. Out of scope requirements This applicability statement does not address requirements related to wireless LLNs employed in factory automation and related applications. So, as I understand things, this document applies to *plants*, but not automated factories. Forgive me for my ignorance, but I guess this means it applies to a oil refinery or chemical plant, but not to a car manufacturer. (Even though, we call them "auto plants") I'm just trying to understand where the line is and why. =3D=3D=3D=3D >The domain of applicability for the RPL protocol may include all > phases but the Normal Operation phase, where the bandwidth allocation > and the routes are usually optimized by an external Path Computing > Engine (PCE), e.g. an ISA100.11a System Manager. So, RPL could be used during phases P1, P2, P4, P5 and P6, but not during P3, (Normal Operation), unless a new OF was defined that interacted with the PCE? (Last time I read the document, I was sure it said that LLNs could be used only during P3) Given that, I guess the "X" in figure 1 means that RPL *can* be used? section 2.1.2 then says: For factory automation networks, the basic communications cycle for control is typically much faster, on the order of 100 Hz or more. but, I thought factory automation was out of scope? section 2.1.3: I think that I'm confused about Source-Sink(SS) vs Peer-to-multipeer(P2MP) given that 2.1.3 says that the sink is usually a multicast address. Is the distinction that in P2MP multiple packets are unicast? Or is the distinction that P2MP is primary from outside the LLN, downward into the LLN, while SS is within the LLN? Or is it that the source is always on the LLN, and the sink is always elsewhere, and the fact that it's a multicast/anycast destination is=20 just a question of how to implement redundancy in the data collection systems?=20 page 13, section 2.1.4: says:=20 With rare exception, the control algorithms used with PS messaging in the process automation industries - those managing continuous material flows - rely on fixed-period sampling, computation and transfer of outputs, while those in the factory automation industries - those managing discrete manufacturing operations - rely on bounded delay between sampling of inputs, control computation and transfer of outputs to physical actuators that affect the controlled process. it seems that there are possibly two completely different industrial requirements here which can not, and should not, be satisfied with a single DAG. Are two documents appropriate here? > Note: Although there are known patent applications for duocast and > N-cast, at the time of this writing the patent assignee, Honeywell > International, has offered to permit cost-free RAND use in those > industrial wireless standards that have chosen to employee the > technology, under a reciprocal licensing requirement relative to that > use.=20=20 Can we get an official IPR statement via: http://www.ietf.org/ipr/file-disclosure on this? I don't think it is particularly relevant to the document, but perhaps I could be wrong. you need to update [I-D.ietf-roll-rpl] to RFC6550. 4.3.1 says: > Because the actual link capacity depends on the particular link > technology used within an industrial automation network deployment, > the Trickle parameters are specified in terms of the link's maximum > capacity for conveying link-local multicast messages. If the link > can convey m link-local multicast packets per second on average, the > expected time it takes to transmit a link-local multicast packet is > 1/m seconds. I am pleased that a formula is being provided, but I am uncomfortable that this document is not more specific to actual link technology used. Can this document pick 1-2 actual link technologies and deal with them? 5.: > The possibility of dynamically updating the metrics in use in the > network as well as the frequency of network updates allows deployment > characteristics (e.g., network density) to be discovered during > network bring-up and to be used to tailor network parameters once the > network is operational rather than having to rely on precise pre- > configuration. This also allows the network parameters and the > overall routing protocol behavior to evolve during the lifetime of > the network. I don't know how this discovery is going to occur. Someone trying to build a sensor that is going to satisfy an RFP for devices to work in a network envisioned by this document needs to know what to include in their code base. As the code space is very finite, they need to know exactly what is important here. =2D-=20 Michael Richardson , Sandelman Software Works=20 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQCVAwUAUS+lV4qHRg3pndX9AQKoDgQA1a3tCyb8kubYZGiXsxmicIwQ8Mzo5kmb uQXK81FCvOeS7JeBk981Q7Tb/elRMnVf+3vG451lcjChqiclGO7xp5PDO7LKRg/y Ok6/YFIwnQkUY9b5Z5F1AXkZm6/uTEfuLZPfUdz9m9cagvpcKtE0sRqxso1p8LJv 9ennKQbQvmE= =yZa0 -----END PGP SIGNATURE----- --=-=-=--